From exim@www1.ietf.org Wed Oct 1 00:04:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29724 for ; Wed, 1 Oct 2003 00:04:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4YDd-0002Pg-Uu for ipv6-archive@odin.ietf.org; Wed, 01 Oct 2003 00:04:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h914455Y009275 for ipv6-archive@odin.ietf.org; Wed, 1 Oct 2003 00:04:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4YDd-0002PW-Hk for ipv6-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 00:04:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29690 for ; Wed, 1 Oct 2003 00:03:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4YDb-0001Tx-00 for ipv6-web-archive@ietf.org; Wed, 01 Oct 2003 00:04:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4YDa-0001Tu-00 for ipv6-web-archive@ietf.org; Wed, 01 Oct 2003 00:04:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4YDZ-0002GK-Ba; Wed, 01 Oct 2003 00:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4YDA-0002Fr-GM for ipv6@optimus.ietf.org; Wed, 01 Oct 2003 00:03:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29677 for ; Wed, 1 Oct 2003 00:03:27 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4YD8-0001TV-00 for ipv6@ietf.org; Wed, 01 Oct 2003 00:03:34 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A4YD7-0001TS-00 for ipv6@ietf.org; Wed, 01 Oct 2003 00:03:33 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h9143Y600339 for ; Wed, 1 Oct 2003 07:03:34 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 1 Oct 2003 07:03:33 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 1 Oct 2003 07:03:33 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 1 Oct 2003 07:03:33 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 1 Oct 2003 07:03:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Node Req: Issue26: 9.1.1 IPv6 Router Alert Option - RFC2711 Date: Wed, 1 Oct 2003 07:03:32 +0300 Message-ID: Thread-Topic: Node Req: Issue26: 9.1.1 IPv6 Router Alert Option - RFC2711 Thread-Index: AcOGtlLPQOlUt8IlTISwQbFGpetXGQBGp/pQ To: Cc: X-OriginalArrivalTime: 01 Oct 2003 04:03:32.0969 (UTC) FILETIME=[FAF31D90:01C387D0] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Thomas, The text looks good, I'll add it. thanks, John > -----Original Message----- > From: ext Thomas Narten [mailto:narten@us.ibm.com] > Sent: 29 September, 2003 21:16 > To: Loughney John (NRC/Helsinki) > Cc: ipv6@ietf.org > Subject: Re: Node Req: Issue26: 9.1.1 IPv6 Router Alert=20 > Option - RFC2711 >=20 >=20 >=20 > john.loughney@nokia.com writes: >=20 > > Reading 2711, there are some host / server specific issues=20 > about 2711.=20 > > Suggested text: >=20 > > IPv6 Router Alert Option specific [RFC-2711] defines a=20 > new option in the >=20 > s/specific/specifically/? > > IPv6 Hop-by-Hop Header. Hosts MAY support the router alert option=20 > > defined. Nodes that generate RSVP message MUST implement=20 > the router > > alert option. The Router Alert Option [RFC-2711] MUST be=20 > supported by=20 > > nodes that perform packet forwarding at the IP layer=20 > (i.e. - the node is > > a router). >=20 > Router alerts are also required with MLD messages. So wording that > reflects this would be good. Indeed, I don't think the RSVP usage is > so important to mention, given that RSVP isn't mentioned elsewhere in > the document. How about something like the following instead: >=20 > The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 > Hop-by-Hop Header that is used in conjunction with some protocols > (e.g., RSVP [RFC XXX], or MLD [RFC XXX]). The Router Alert option > will need to be implemented whenever protocols that mandate its > usage are implemented. See Section XXX-MLD. >=20 >=20 > Thomas =20 >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 1 01:25:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01953 for ; Wed, 1 Oct 2003 01:25:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ZTX-0006Rr-1H for ipv6-archive@odin.ietf.org; Wed, 01 Oct 2003 01:24:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h915OYjE024781 for ipv6-archive@odin.ietf.org; Wed, 1 Oct 2003 01:24:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ZTW-0006Rc-RY for ipv6-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 01:24:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01921 for ; Wed, 1 Oct 2003 01:24:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ZTT-00028Z-00 for ipv6-web-archive@ietf.org; Wed, 01 Oct 2003 01:24:31 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4ZTT-00028W-00 for ipv6-web-archive@ietf.org; Wed, 01 Oct 2003 01:24:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ZSz-0006Lj-Ow; Wed, 01 Oct 2003 01:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ZSV-0006LF-P9 for ipv6@optimus.ietf.org; Wed, 01 Oct 2003 01:23:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01909 for ; Wed, 1 Oct 2003 01:23:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ZSS-00028C-00 for ipv6@ietf.org; Wed, 01 Oct 2003 01:23:28 -0400 Received: from out1.smtp.messagingengine.com ([66.111.4.25] helo=mail.messagingengine.com) by ietf-mx with esmtp (Exim 4.12) id 1A4ZSS-000288-00 for ipv6@ietf.org; Wed, 01 Oct 2003 01:23:28 -0400 Received: from smtp.us2.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id DA74224BF64; Wed, 1 Oct 2003 01:23:28 -0400 (EDT) Received: from 10.202.2.133 ([10.202.2.133] helo=smtp.us2.messagingengine.com) by messagingengine.com with SMTP; Wed, 01 Oct 2003 01:23:28 -0400 Received: by smtp.us2.messagingengine.com (Postfix, from userid 99) id BF20578950; Wed, 1 Oct 2003 01:23:28 -0400 (EDT) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: ipv6@ietf.org Date: Wed, 01 Oct 2003 10:53:28 +0530 X-Epoch: 1064985808 X-Sasl-enc: pFh+OY2BF+SkAYD4qeTFCQ Cc: dthaler@microsoft.com, mohitt@microsoft.com Subject: ndproxy-00 (General comments) Message-Id: <20031001052328.BF20578950@smtp.us2.messagingengine.com> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Few comments on draft-thaler-ipv6-ndproxy-00.txt. CP 1. Section 1. First bullet following the first paragraph. The first bullet talks about an "access point". Give a reference to the 802.11 spec. Should 802.11 be mentioned in the first place? What advantage does ndproxy provide over classical bridges in an 802.11 network? 2. Section 1. 2nd Paragraph. Rephrase to: It is expected that whenever possible links will be bridged at the link layer using classic bridge technology. Bridging at the network layer SHOULD be used only when the classic bridges cannot be used. For bridging at the network layer, a single "bridge" interface will be exposed to the IP layer. In the remainder.... 3. Remove the reference to MLSR, the document is no longer present in the I-D directory. 4. Section 1. The explanation about the simple RA proxy is unclear. The terms "downstream link" and "upstream link" are unclear. I started of with the assumption that the upstream link refers to the bridge segment to which the router is connected, and the downstream link is another segment to which the RA's are to be forwarded. But then I could not understand the problems caused. This approach needs some elaboration. Appendix section seem to be the correct place holder for alternate approaches. In other parts of the document, they distract the reader. 5. Section 1.1. Remove the line -> "It should appear as if one host uses multiple addresses." It does not seem to add anything more that what is specified in the previous sentence. In addition, it is semantically incorrect. The router will never see the bridged hosts, as one single host with multiple addresses. 6. Section 1.1 Remove the sentence starting with "If, on the other hand, neighbor ...". This sentence refers to implementation, and it is too early in the document to do so. 7. Section 1.1 Add the following requirements. a) Allow dynamic addition/removal of proxies, and nodes to the network without disrupting traffic. b) The proxy should be able to interwork with a 802.1d compliant bridge. 8. Section 1.2 Rephrase the first requirement to "Should not require assignment of an IP address. It implies that the bridge will not be visible in traceroute scans." 9. Section 1.2 4th bullet. Rephrase to: Transparently support different MTU's in use on different segments. The rest of the text should be moved in another section. 10. Section 2. 4th Paragraph The IPv4, and IPv6 implementation in the proxy is not going to complete. I also can't think of the usage of the various neighbor cache states in the proxy, and moreover, it cannot be implemented as is. 11. Section 2. 5th Paragraph What about processing of DHCPv6 packets? Don't they carry hardware (link-layer) addresses? Thinking a bit more about "packets that will need address substitution" issue - providing a set of guidelines will help implementors in deciding whether the link-layer address in the payload of a protocol should be substituted by the link-layer address of the proxy will help. Such guidelines will also take care of future protocols, and this document will not have to be updated. My view of the guidelines is: 1. If the link-layer address in the payload of the protocol can be used in the link-layer header of future messages, then the proxy should substitute it with its own address. For example the link-layer address in NA messages is used in the link-layer header for future messages, and, hence, the proxy substitutes it with its own address. For broadcast/multicast packet the link-layer substituted within the payload will be different for each outgoing port. 2. If the link-layer address in the payload of the protocol is never used in the link-layer header, then the proxy should not substitute it with its own address. In this case, the link-layer address maybe included in the protocol payload to uniquely identify the node. For example, link-layer address in DHCPv4 messages is not substituted by the proxy, as that address is never used in the link-layer header of any future messages. 3. All messages with unspecified IPv6/IPv4 destination address should be broadcast on all ports. 15. Section 2. 13th paragraph. Following the above guidelines will not require modification of the BROADCAST flag in the proxied DHCPv4 packet. (I might be mistaken, I have yet to confirm this with the DHCP specs) 16. Section 2. 8th paragraph. Maintaining the same states in the neighbor cache as those in a node is not correct. The proxy will not implement the node procedures, and will not do state transitions in the same manner. IMHO, more light needs to be shed on the subject. I also propose adding the following text : If a unicast message is received for a destination for which there is no entry in the neighbor cache then the message has to be forwarded on all segments. 17. Section 2. 10th paragraph Issues that may be encountered during address substitution should be mentioned. They might seem obvious, but a mention will help the developers. One issue that I can think of is : 1. The link layer address will be new, and might have different length. The new link layer address will result in re-computation of certain parts of the IPv4/IPv6 header. 18. The proxy peeks inside certain messages, and replaces the link-layer address with the link-layer address of the proxy. It is not clear however the link-layer address of which port is chosen. It seems that it will be the link-layer of the outgoing port. This one needs some clarification. 18. Section 2. 6th paragraph This paragraph defines the working of the proxy when "any other" broadcast or multicast packet is received. It is mentioned that the packet "is forwarded unchanged out all other proxy interface on the same link". Text needs to be added about how the message the packet is forwarded on interfaces on other links. 19. Section 2. 12th Paragraph What is the advantage of clearing the Override bit? Some of the comments might not be relevant if the document is reorganized. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 1 01:31:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02145 for ; Wed, 1 Oct 2003 01:31:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ZZw-0006qv-1J for ipv6-archive@odin.ietf.org; Wed, 01 Oct 2003 01:31:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h915VCuf026335 for ipv6-archive@odin.ietf.org; Wed, 1 Oct 2003 01:31:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ZZv-0006qg-TA for ipv6-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 01:31:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02115 for ; Wed, 1 Oct 2003 01:31:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ZZs-0002D4-00 for ipv6-web-archive@ietf.org; Wed, 01 Oct 2003 01:31:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4ZZs-0002D1-00 for ipv6-web-archive@ietf.org; Wed, 01 Oct 2003 01:31:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ZZn-0006kh-Ka; Wed, 01 Oct 2003 01:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ZYw-0006jM-B6 for ipv6@optimus.ietf.org; Wed, 01 Oct 2003 01:30:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02071 for ; Wed, 1 Oct 2003 01:30:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ZYt-0002CL-00 for ipv6@ietf.org; Wed, 01 Oct 2003 01:30:07 -0400 Received: from out1.smtp.messagingengine.com ([66.111.4.25] helo=mail.messagingengine.com) by ietf-mx with esmtp (Exim 4.12) id 1A4ZYs-0002CI-00 for ipv6@ietf.org; Wed, 01 Oct 2003 01:30:06 -0400 Received: from mail.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id E201F24AE17; Wed, 1 Oct 2003 01:27:52 -0400 (EDT) Received: from 10.202.2.150 ([10.202.2.150] helo=mail.messagingengine.com) by messagingengine.com with SMTP; Wed, 01 Oct 2003 01:27:53 -0400 X-Epoch: 1064986072 X-Sasl-enc: DIPtIFp2cXD8bTsgNfOoYQ Received: from moon (unknown [202.142.102.54]) by mail.messagingengine.com (Postfix) with ESMTP id 559CA249DCE; Wed, 1 Oct 2003 01:27:17 -0400 (EDT) From: "Chirayu Patel" To: Cc: , Subject: ndproxy-00 (new text + reorganization) Date: Wed, 1 Oct 2003 11:01:18 +0530 Message-ID: <001401c387dd$45ef51e0$010aa8c0@chirayu.org> 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.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, After reading the complete document, I feel that there are a few pieces that are still missing in the document. Suggested reorganization --------------------------- he document can do with some reorganization. Section 2 is a bit too long. It needs to be broken up, and a few more sections should also be added. 1) Introduction 2) Requirements for ND proxy 2.1) Non-requirements for the ND proxy 3) Behavior of the ND proxy 3.1) Parsing IPv4 packets 3.1.1) ARP packets 3.1.2) ICMPv4 packets 3.1.3) DHCPv4 packets 3.1.4) Other protocol packets 3.1.4.1) Unicast packets 3.1.4.2) Multicast/Broadcast packets 3.2) Parsing IPv6 packets 3.2.1) ICMPv6 packets 3.2.1.1) NS/NA packets 3.2.1.2) RS/RA packets 3.2.1.3) Redirect packet 3.2.2) DHCPv6 packets 3.2.3) Other protocol packets 3.2.3.1) Unicast packets 3.2.3.2) Multicast/Broadcast packets 3.3> Assigning a local IP address 4) Examples 4.1) Example 1 4.2) Example 2 5) Cache table 6) Effect of changes in spanning tree 7) Deployment considerations 7.1) MTU configuration 10) Security considerations 10) .... 11) Appendix A : RA only proxy New text --------- I have suggested text for the above sections here. Please refer to my previous email on justification for the new text. Section 3) ---------- Please refer to my previous email for text concerning guidelines. Section 3.3) ------------ A proxy device does not require a local IP address. However it will be convenient to configure the proxies remotely if they are assigned an an IP address. Assignment of an IP address does not change the working of the proxy. It would require that the proxy to implement the more protocols (give reference to IPv4, IPv6 node requirements). The interface that has been assigned an IP address can be viewed as an internal interface. The following high level diagram depicts the various functional blocks within a proxy that has been assigned an IP address. +-------------+ | | | ICMPv6, ARP | | UDP, SNMP | | etc | +-------------+ | IPv4/IPv6 | +-----+-------+ | +---+ +---------------------+ | |int| | IP implementation | +----------------+i/f+--------+ for a proxy | | | | | +---+ +--+---+---+---+---+--+ | | | | | +++ +++ +++ +++ +++ | | | | | | | | | | +++ +++ +++ +++ +++ (external interfaces) Section 5) ---------- The proxy is not a node in the network. Its main tasks are forwarding IPv4 packets from one port to another, and manipulating protocol headers. The main conceptual data structure that will be maintained in the proxy is the neighbor cache. Each entry of the neighbor cache contains o IP (IPv4, or IPv6) address o port number o link-layer address The entry is created by recording the IP address of the sender, the port number on which it was received, and the link-layer address of the sender. A new entry is created in the link-table whenever a new (not present in the neighbor cache) sender IP address encountered in any packet. A keep alive timer is also started. This timer is restarted whenever any packet with the same source IP address is encountered. On expiry of the timer, the entry is deleted. The entry is updated in two circumstances - A packet with the IP address, as the one in the entry, is received on another port. In this case the port number is modified. - A packet with the IP address, as the one in the entry, is received on with a different source link-layer address. In this case the link-layer address is modified. An entry is deleted when - Expiry of the keep alive timer. - Change in the spanning tree. Any change in the spanning tree may result in change of port numbers for few entries. Since it is not possible to determine the affected entries, and to minimize traffic loss, the complete table is flushed, and created afresh. The neighbor cache structure is generic enough to be used along with both IPv4, and IPv6 addresses. Section 6 (Effect of changes in spanning tree) ---------------------------------------------- Some of the changes in the topology of the network may result in modifications of the spanning tree. Some of these changes are addition/removal of a proxy, or addition/deletion of a link on a proxy. These changes have some subtle change on the network load. As soon as a spanning tree change is determined by the proxies in the network, they will flush the neighbor cache, and create it afresh. The network traffic will increase momentarily, as each proxy will broadcast all the packets that it receives. This problem can be particularly severe in networks where there is a frequent change in the spanning tree. There might be some traffic loss, when a new spanning tree is constructed. Section 7.1) (MTU configuration) ---------------------------------------- If the proxies within the subnet support different link MTU's, then the nodes within the subnet should be configured with the smallest link MTU amongst all the link MTU's. Thus, deployment of the proxies might not be a simple "plug and play" operation. Misconfiguration of the MTU in the nodes will result in blackholes that may prove difficult to track. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 1 01:38:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02326 for ; Wed, 1 Oct 2003 01:38:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Zgh-0007ei-1d for ipv6-archive@odin.ietf.org; Wed, 01 Oct 2003 01:38:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h915cBRJ029422 for ipv6-archive@odin.ietf.org; Wed, 1 Oct 2003 01:38:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Zgg-0007eT-JN for ipv6-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 01:38:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02303 for ; Wed, 1 Oct 2003 01:38:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Zgd-0002HZ-00 for ipv6-web-archive@ietf.org; Wed, 01 Oct 2003 01:38:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4Zgd-0002HW-00 for ipv6-web-archive@ietf.org; Wed, 01 Oct 2003 01:38:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Zga-0007XQ-Lg; Wed, 01 Oct 2003 01:38:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ZgN-0007TY-Nv for ipv6@optimus.ietf.org; Wed, 01 Oct 2003 01:37:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02288 for ; Wed, 1 Oct 2003 01:37:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ZgK-0002HC-00 for ipv6@ietf.org; Wed, 01 Oct 2003 01:37:48 -0400 Received: from out1.smtp.messagingengine.com ([66.111.4.25] helo=mail.messagingengine.com) by ietf-mx with esmtp (Exim 4.12) id 1A4ZgJ-0002H9-00 for ipv6@ietf.org; Wed, 01 Oct 2003 01:37:47 -0400 Received: from smtp.us2.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 4D44D24BA76; Wed, 1 Oct 2003 01:37:48 -0400 (EDT) Received: from 10.202.2.133 ([10.202.2.133] helo=smtp.us2.messagingengine.com) by messagingengine.com with SMTP; Wed, 01 Oct 2003 01:37:48 -0400 Received: by smtp.us2.messagingengine.com (Postfix, from userid 99) id 36D7975C84; Wed, 1 Oct 2003 01:37:48 -0400 (EDT) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: ipv6@ietf.org Date: Wed, 01 Oct 2003 11:07:47 +0530 X-Epoch: 1064986668 X-Sasl-enc: Ox6c2DRLlluHnlDgoEf+gw Cc: dthaler@microsoft.com, mohitt@microsoft.com Subject: ndproxy-00 (new text + reorganization) Message-Id: <20031001053748.36D7975C84@smtp.us2.messagingengine.com> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, After reading the complete document, I feel that there are a few pieces that are still missing in the document. Suggested reorganization --------------------------- The document can do with some reorganization. Section 2 is a bit too long. It needs to be broken up, and a few more sections should also be added. 1) Introduction 2) Requirements for ND proxy 2.1) Non-requirements for the ND proxy 3) Behavior of the ND proxy 3.1) Parsing IPv4 packets 3.1.1) ARP packets 3.1.2) ICMPv4 packets 3.1.3) DHCPv4 packets 3.1.4) Other protocol packets 3.1.4.1) Unicast packets 3.1.4.2) Multicast/Broadcast packets 3.2) Parsing IPv6 packets 3.2.1) ICMPv6 packets 3.2.1.1) NS/NA packets 3.2.1.2) RS/RA packets 3.2.1.3) Redirect packet 3.2.2) DHCPv6 packets 3.2.3) Other protocol packets 3.2.3.1) Unicast packets 3.2.3.2) Multicast/Broadcast packets 3.3> Assigning a local IP address 4) Examples 4.1) Example 1 4.2) Example 2 5) Cache table 6) Effect of changes in spanning tree 7) Deployment considerations 7.1) MTU configuration 10) Security considerations 10) .... 11) Appendix A : RA only proxy New text --------- I have suggested text for the above sections here. Please refer to my previous email on justification for the new text. Section 3) ---------- Please refer to my previous email for text concerning guidelines. Section 3.3) ------------ A proxy device does not require a local IP address. However it will be convenient to configure the proxies remotely if they are assigned an an IP address. Assignment of an IP address does not change the working of the proxy. It would require that the proxy to implement the more protocols (give reference to IPv4, IPv6 node requirements). The interface that has been assigned an IP address can be viewed as an internal interface. The following high level diagram depicts the various functional blocks within a proxy that has been assigned an IP address. +-------------+ | | | ICMPv6, ARP | | UDP, SNMP | | etc | +-------------+ | IPv4/IPv6 | +-----+-------+ | +---+ +---------------------+ | |int| | IP implementation | +----------------+i/f+--------+ for a proxy | | | | | +---+ +--+---+---+---+---+--+ | | | | | +++ +++ +++ +++ +++ | | | | | | | | | | +++ +++ +++ +++ +++ (external interfaces) Section 5) ---------- The proxy is not a node in the network. Its main tasks are forwarding IPv4 packets from one port to another, and manipulating protocol headers. The main conceptual data structure that will be maintained in the proxy is the neighbor cache. Each entry of the neighbor cache contains o IP (IPv4, or IPv6) address o port number o link-layer address The entry is created by recording the IP address of the sender, the port number on which it was received, and the link-layer address of the sender. A new entry is created in the link-table whenever a new (not present in the neighbor cache) sender IP address encountered in any packet. A keep alive timer is also started. This timer is restarted whenever any packet with the same source IP address is encountered. On expiry of the timer, the entry is deleted. The entry is updated in two circumstances - A packet with the IP address, as the one in the entry, is received on another port. In this case the port number is modified. - A packet with the IP address, as the one in the entry, is received on with a different source link-layer address. In this case the link-layer address is modified. An entry is deleted when - Expiry of the keep alive timer. - Change in the spanning tree. Any change in the spanning tree may result in change of port numbers for few entries. Since it is not possible to determine the affected entries, and to minimize traffic loss, the complete table is flushed, and created afresh. The neighbor cache structure is generic enough to be used along with both IPv4, and IPv6 addresses. Section 6 (Effect of changes in spanning tree) ---------------------------------------------- Some of the changes in the topology of the network may result in modifications of the spanning tree. Some of these changes are addition/removal of a proxy, or addition/deletion of a link on a proxy. These changes have some subtle change on the network load. As soon as a spanning tree change is determined by the proxies in the network, they will flush the neighbor cache, and create it afresh. The network traffic will increase momentarily, as each proxy will broadcast all the packets that it receives. This problem can be particularly severe in networks where there is a frequent change in the spanning tree. There might be some traffic loss, when a new spanning tree is constructed. Section 7.1) (MTU configuration) ---------------------------------------- If the proxies within the subnet support different link MTU's, then the nodes within the subnet should be configured with the smallest link MTU amongst all the link MTU's. Thus, deployment of the proxies might not be a simple "plug and play" operation. Misconfiguration of the MTU in the nodes will result in blackholes that may prove difficult to track. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 1 08:36:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09995 for ; Wed, 1 Oct 2003 08:36:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4gD9-0004iC-3h for ipv6-archive@odin.ietf.org; Wed, 01 Oct 2003 08:36:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91Ca7Cu018112 for ipv6-archive@odin.ietf.org; Wed, 1 Oct 2003 08:36:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4gD8-0004i3-Th for ipv6-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 08:36:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09973 for ; Wed, 1 Oct 2003 08:35:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4gD7-0006Nu-00 for ipv6-web-archive@ietf.org; Wed, 01 Oct 2003 08:36:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4gD7-0006Nr-00 for ipv6-web-archive@ietf.org; Wed, 01 Oct 2003 08:36:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4gC8-0004c1-5y; Wed, 01 Oct 2003 08:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4gBN-0004at-QY for ipv6@optimus.ietf.org; Wed, 01 Oct 2003 08:34:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09930 for ; Wed, 1 Oct 2003 08:34:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4gBM-0006Mx-00 for ipv6@ietf.org; Wed, 01 Oct 2003 08:34:16 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1A4gBL-0006MQ-00 for ipv6@ietf.org; Wed, 01 Oct 2003 08:34:15 -0400 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h91CXiV27287; Wed, 1 Oct 2003 05:33:44 -0700 Received: from innovationslab.net (md-wmnsmd-cuda2-c6d-51.chvlva.adelphia.net [67.21.61.51]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h91CYMtX020767 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 1 Oct 2003 05:34:25 -0700 Message-ID: <3F7AC9A2.9070705@innovationslab.net> Date: Wed, 01 Oct 2003 08:33:38 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Templin CC: ipv6@ietf.org Subject: Re: Comments on draft-hain-templin-ipv6-limitedrange-02.txt References: <3F730183.6090504@caspiannetworks.com> <3F799994.8070400@innovationslab.net> <3F79DC5E.3080307@iprg.nokia.com> In-Reply-To: <3F79DC5E.3080307@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Fred Templin wrote: > Brian, > > Thanks for sending the detailed comments. Will give a first-pass > at them below, but may require a couple of iterations. > > Fred > ftemplin@iprg.nokia.com > > Brian Haberman wrote: > >> >> [WG chair hat off] >> >> Below are my comments on the Hain/Templin draft. Globally, >> I think that these goals are worthwhile for the entire IPv6 >> protocol suite. This type of functionality is needed in order >> for people to feel comfortable migrating from v4 to v6. >> >> >>> Goals for an Addressing Scheme to Support Local Communications within >>> Sites >> >> >> >> The title still implies that these goals will be satisfied >> by an addressing scheme rather than some other mechanism. As >> it has been noted in the past, some of these goals are not >> specific or require a local addressing scheme. In fact, some >> of the "goals" are really operational rather than addressing >> issues. > > > > Actually, Ralph Droms had a similar comment (see his post > on this thread) and suggested the following title: > > "Goals for Local Communications Within Sites" That sounds better to me. It focuses the discussion on the aspects of local communication without hinting at a solution. > >> If we can separate out the operational issues from the local >> addressing goals, the title may fit better. > > > > I like Ralph's title suggestion; any others? > >> >>> 1. Introduction >>> >>> The IPv6 addressing architecture [RFC3513] specifies global and >>> local-use unicast addresses. Global addresses are understood to have >>> unlimited range and may be used as the source and destination >>> addresses in packets that originate from any point on the connected >>> global IPv6 Internet. Local-use addresses are intended for use only >>> within the range of a single link/site, but their specification does >>> not address operational considerations and does not account for the >>> esoteric nature of terms such as "site". >> >> >> >> I cannot determine what the last sentence is trying to say. > > > > How about: > > "...but their specification does not address operational > considerations for real-world deployments." So with the title change, I would suggest re-writing the Intro to focus on the aspects of local communications. Describe the characteristics/features of local communication that need to be preserved. You could keep some text on local addresses as an example. > >> Further along in the document, it expressly talks about operation >> considerations. In fact, the whole document assumes that these >> considerations should all be fixed by a local addressing scheme. > > > > Not the intention, and will work to fix this. We want > to support local communications within sites, but this > need not be through a *local addressing* scheme. > >> Perhaps what needs to be discussed here is why only having global >> addresses would not suffice. Describe the operational problems >> that will be caused without local addressing. > > > > Any specific text suggestions would be welcome. > >>> >>> There is a perceived need for an addressing scheme that supports >>> local communications within sites. Of special interest are "active >>> sites", e.g., sites that are intermittently-connected or disconnected >>> from the global Internet, sites that frequently change provider >>> points of attachment, sites that temporarily or permanently merge >>> with other sites, multi-homed sites, etc. This memo will discuss >>> goals for an addressing scheme to support local communications within >>> sites in the context of real world deployment scenarios. >> >> >> >> I find the use of the word "perceived" in the first sentence of this >> paragraph and in other places in this document. If it is just a >> perceived need, can't these goals be solved with other tools? Or >> put in other terms, will operators use different tools if they are >> provided/defined/developed? > > > > Well, there is an actual need for local communications within sites > and any form of communications requires addressing. Would your > concerns be satisfied if we struck the word "perceived" wherever > it occurs? Yes. > >> Also, multi-homing is a different issue altogether. I can't see >> where it needs to be discussed other than as a subset of a possible >> renumbering scenario. >> >> Like my comments on the introduction, I would firm up the issues >> caused without local addressing. > > > > Again, specific text suggestions would be welcome. I would suggest just dropping the reference to multi-homing in this case. > >> I also suggest that multi-homing be taken out of this document. > > > > Agree; we already have RFC 3582 and don't want to re-create it here. > >> >>> 3.1 Easy to Acquire >>> >>> Some portion of the address space should be made available that >>> requires no public registration, payment, customer/provider >>> relationship, or approval. These addresses should be architecturally >>> supported and end-user-controlled. >> >> >> >> A few issues with this section. >> >> First, why is no payment a goal as far as ease of acquisition is >> concerned? > > > > Not intending the non-payment aspect for the entire address space, > as indicated by: "*Some portion* of the address space..". What we > are intending to say is that some scenarios may require autonomous > address configuration with no interactions with a registry, and > those scenarios should be supported. OK. Then I would recommend stating it in that fashion. That is, some portion of the address space should be obtainable with no payment and no registry interaction. An example would be useful as well. > >> Second, how can conflict resolution occur without some form of >> public registration? No registry is fine if we are talking >> about a strictly disconnected network, but for connected networks >> a conflict resolution capability is a good thing to have. > > > > Not what we're intending to say; clearly, some scenarios will > require conflict resolution such as can only be enforced through > public registration. We touch on this in section 3.5. How about some discussion on whether conflict resolution capability is more/less important than no registry/payment? > >> Third, I would suggest some text be added to discuss the tradeoffs >> of the global routability of these addresses. > > > > Suggestions? > >>> >>> 3.2 Stable >>> >>> Applications that enable local communications should use addresses >>> that support session stability (i.e., connection survivability) >>> during intermittent connectivity, site mergers, change to a new >>> provider, etc. In particular, session stability should not be >>> affected by renumbering events [BAKER]. >> >> >> >> How often do you expect renumbering events to occur? > > > > In fixed environments, perhaps quite rarely; in mobile environments, > perhaps quite often. This seems like a question for [BAKER]. My point is more in terms of how this document wants to define stable. In my view, stability has different meanings when discussing the renumbering of a network versus having that network be subject to intermittent connectivity to the Internet. In the former, you expect a drastic change to occur to the prefix(es) in use. While in the latter, it is quite possible that the same prefix will remain in use as long as your point-of-attachments are to the same provider. > >> How does renumbering differ from a planned outage? When those >> occur, applications either restart or are restarted once the >> change is made. > > > > We don't want applications to have to restart; we want them > to continue through to completion. > >> In addition, just because a subnetwork disconnects, it doesn't >> terminate the use of prefixes within the subnetwork. So, the >> apps can keep using those addresses until the nodes are told >> of new ones. >> >> The requirement seems to be for a stable address for a long period >> of time (months, years, decades, etc). If that is the requirement, >> then state it as such. > > > > Long period of time, perhaps, but how long is difficult to > quantify. Again, perhaps this is a question for the [BAKER] > renumbering draft. I think it is quite pertinent to this draft. How long must an address remain stable in order to satisfy this document's stability goal? > >> >>> >>> 3.3 Multiple Link Support >>> >>> Addresses for local communications within sites should support >>> operation over multiple links, e.g., via L3 routing, L2 bridging or >>> some combination thereof. As such, subnetting consistent with the >>> recommendations in ([RFC3177], section 3) should be supported. >>> >>> Link-local addresses in IPv6: "are designed to be used for addressing >>> on a single link for purposes such as automatic address >>> configuration, neighbor discovery, or when no routers are present" >>> ([RFC3513], section 2.5.6). By definition, link-local addresses have >>> a single link range of operation and will not meet this goal. >> >> >> >> I don't think this section even belongs here. We have link-locals >> defined already, so someone will not re-define them. I suggest taking >> it out altogether. > > > > Remove all of section 3.3, or just the second paragraph? > (The first paragraph is the only text in the document that > speaks to the possibility of subnetting within the site.) Taking out just the second paragraph should be fine. > >>> >>> 3.4 Well-known Prefix >> >> >> >> I think this section is an excellent example of trying to solve >> an operational issue with an addressing scheme. Several people >> have suggested this before, but a "well-known" prefix can just as >> easily be carved out of one's global prefix. >> >> In addition, how exactly does an app figure out "the hint"? It >> has no way of knowing which side of the site boundary it currently >> resides. The well-known prefix works for filtering at boundaries, >> not for special handling by an app. > > > > I have no opinion on this question; do you have anything > to add on this subject, Tony? > > >>> 3.5 Globally Unique >>> >>> Addresses used by sites should be globally unique such that site >>> mergers will not result in collisions. Global uniqueness is based on >>> the statistical properties of address allocations, therefore >>> proposals should specify a suitable means for random prefix >>> generation. Addressing scheme proposals should also provide a >>> suitable means for conflict resolution, e.g., certification through a >>> central registry, distributed database, etc. >> >> >> >> Doesn't this directly conflict with the requirement in 3.1 for >> no public registry? > > > > As I mentioned in response to the section 3.1 comments, we want > to support both those scenarions that require autonomous address > configuration with no registration in which statistical uniqueness > is sufficient, and those that require conflict resolution and true > global uniqueness as provided through a registration authority. > Can you suggest a way for us to clarify? Perhaps the initial list of requirements should spell out the relative importance between requirements. Is it more important to have a registry that assists with conflict resolution or having no central registry? Or are they equal and a solution should try and provide both? > >>> >>> Sufficient global uniqueness is needed to support, e.g.: >>> >>> o VPNs between enterprises >>> >>> o dynamically created VPNs in support of temporary virtual >>> organizations >>> >>> o service provider co-location of hosts that reside in the address >>> space of multiple customers >>> >>> o formation of virtual organizations (Grids) among enterprises >>> >>> o mergers and acquisitions of enterprises such that address spaces >>> do not collide >> >> >> >> I am confused by this list. One could argue that all of the above >> put together requires globally routed addresses. > > > > The objective of this document is to present the goals for > local communications within sites; not to argue for one > solution alternative over another. If others use this document > as a talking point for arguing the solution alternatives, then > the document will have served its purpose. > >> Perhaps the better way to approach this is to discuss the tradeoffs >> of centrally-allocated addresses and locally-allocated addresses in >> supporting tools such as VPNs. > > > > OK, if f we can do so without departing from the goals focus > and getting too close to the realm of solutions. Any suggetions > would be welcome. > >>> 3.6 Usable in the Absence of a Provider >>> >>> Active sites need addresses that can be used when there is no active >>> link to a provider. In the case of intermittently-connected sites, >>> provider access may be unavailable for long periods but this should >>> not disrupt local communications within the site. In the case of >>> sites moving to new provider points of attachment, frequent >>> renumbering events may occur but, again, local communications should >>> not be disrupted. >>> >> >> The current scheme for renumbering allows for overlapping of the >> old and new prefixes for a period of time. This would apply to >> the intermittently-connected sites as well. Apps can continue to >> use the old prefixes for internal sessions until the pre-planned, >> hard cutover. Once that cutover occurs, the apps will disconnect >> from the old prefix and re-establish through the new prefix. > > > > OK. > >> >>> PI addresses provide one solution alternative genre that also >>> appliies to cases where network managers want global access. The >>> issue is that PI addresses with no designed aggregation properties >>> may lead to global routing table explosion (if advertised outside the >>> site) given current routing technologies. For this reason, PI >>> addressing scheme proposals should either provide reasonable >>> aggregation properties or a detailed analysis of their interactions >>> with global routing technologies. PA and other non-PI proposals >>> should explain how the proposed addressing schemes will support local >>> communications in the presence of intermittent and/or disconnected >>> provider access. >> >> >> >> What is the purpose of having this short discussion of PI addresses >> in this document? > > > > Well, your point could be made that this is getting away from goals > and touching too closely on solution space. I could live with dropping > this text, if that is what you are suggesting. Tony? I don't see the benefit of having a short discussion of PI space in this doc, so I would suggest removing it. > >> >>> 3.8 Compatible with Site Naming System >>> >> >> Since the document assumes that addressing will be the solution, >> why have this section on naming? > > > > Didn't quite understand this comment; can you clarify? Is this section specifying a requirement that any solution be compatible with DNS? Should an addressing-based solution refrain from adding new DNS records? Should it refrain from using two-faced DNS? > >>> 3.9 Compatible with VPN >>> >> >> See my comments on section 3.5. This is a prime example for >> the use of global addresses. > > > > If you think this is getting away from goals and coming too > close to solutions, please explain; the section seems to be > describing a goal to me. > >>> 4.1 Border Filtering >>> >>> Network managers limit specific applications to internal use, so they >>> configure them to only work with a filtered address range. This >>> simplifies the border filter to an address prefix, rather than >>> needing to employ deep packet inspection to track a potentially >>> dynamic range of ports. >>> >> >> Again, if they are connected to the Internet, they can carve out a >> portion of the global prefix IF you want to rely on this type of >> filtering for "application protection". I have the same concern >> about this section as raised with section 3.4 In discussing the >> issue of filtering, I would like to see the tradeoffs, e.g. real >> cost, of using a portion of your global space vs. local addresses. > > > > Again, I'll have to ask that Tony comment on this one. > >>> 4.2 Maintaining Confidentiality of the Address Space >>> >>> Private space may be used to avoid exposing to competitors what >>> internal networks they are deploying and which office is coordinating >>> that effort. Network managers also don't have to expose business >>> plans to a registrar for evaluation for networks that are not >>> attached to the global Internet. Some have stated that if they are >>> required to register for public space for every internal use network, >>> they are more likely to pick random numbers than tip off the >>> competition. >> >> >> >> Can you give an example of how this works? Knowing what someone's >> prefix is doesn't reveal what internal networks are being deployed. > > > > This one also for Tony. > >>> >>> 4.3 Test Networks >>> >>> Another significant use of private address space is test networks. >>> Frequently these are large, elaborate networks with a mix of public >>> and private address space. Use of random unallocated space runs the >>> risk of collision with legitimate addresses on remote networks. >> >> >> >> But you can mitigate that risk if you sub-divide your public space >> and filter the chunk you want private. >> >> >>> 4.5 Mobile Router with Personal Area Network >> >> >> >>> 4.6.2 Groups of Nodes that Travel Together >> >> >> >> I made this comment earlier, but it applies to these two sections >> as well. Just because a network is dis-connected, does not mean >> it can't keep using the prefix it was assigned when it was connected. > > > > Well, again we are talking about goals here - not solutions. > The goal is to support local communications within groups > of nodes that travel together with possible long periods of > intermittent/disconnected access. The solution is out of scope > for this document. My concern is more with the distinction between a renumbering event and re-connection to the same provider. The latter can allow you to continue using the prefix you were originally given. > >> I suggest that this section spell out the issues of long-term use >> of an ISP-assigned prefix after the dis-connection. And that this >> take into account whether the customer has negotiated the rights >> to "keep" the prefix during the intermittently connected time. > > > > But, would this take us back into solution space again? > >>> Research ships at sea intermittently connect via INMARSAT, or when in >>> port, the shipboard network is connected to shore via Ethernet. Of >>> utmost importance is that the systems on board the ship all function, >>> providing data collection and analysis without interruption. Static >>> addressing is used on most intra-ship network components and servers. >>> It's quite expensive to operate a research ship, so eliminating >>> points of failure is important. Scientists on board collaborate with >>> colleagues back home by sharing of data and email. Currently private >>> address space is employed for several reasons: 1) it provides the >>> ability to allocate significant address space to each ship without >>> needing to worry about how many computers will be on a given cruise. >>> 2) it provides separate address space for each ship. 3) it simplifies >>> filtering to ensure shipboard traffic is not permitted to transmit >>> out or bring up expensive satellite links. >> >> >> >> Point 1 is a no-op, it can be accomplished with almost any addressing >> mechanism. Point 2 screams for the use of global addresses. And 3 >> can, once again, be accomplished through many other means besides a >> special address range. > > > > Are you suggesting any changes for the document in this comment? Well, the last portion talks about some important issues. The current use of IPv4 private addresses is done to accomplish those three points. Those are important to know. So I think they need to be closer to the beginning of the document as target goals. > >>> 5. Perceived Advantages of Limited Range Addressing Solutions >>> >>> Limited range addressing solutions allow filtering, and filtering >>> creates addressing boundaries no matter where the bits come from. The >>> point is that some addresses are only valid within the range defined >>> by the local network manager. >> >> >> >> I agree with this sentence. Some addresses are only valid in an area >> defined by the manager. And that can be accomplished in several ways. > > > > OK. > >>> In the simple case, hosts that are allowed external access have a >>> policy that allows them to configure both global and limited range >>> prefixes, while those that are not allowed global access have a >>> policy that only allows limited range. Address selection policy >>> tables might need modifications to enable the selection of limited >>> range address space over global addresses. Given such modifications, >>> address selection rules will prefer the smallest range so internal >>> communications are forced to stay internal by the hard filter at the >>> border. >>> >>> If an application chooses to assert a policy that is different from >>> the network manager's filtering rules, it will fail. Having a well >>> defined limited range address space that is known to have filtering >>> applied allows applications to have a hint about potential range >>> restrictions. We can choose to leave the network managers to figure >>> out their own adhoc mechanisms, or we can put them in a structured >>> limited range address space so that applications will have a chance >>> to react appropriately. >> >> >> >> This paragraph raises the point that the proposals by Zill and >> Bellovin or other similar approaches to advertise "special" prefixes >> via an RA may be useful tools for us to provide. And I am sure others >> will see the same. Perhaps there needs to be some wrap-up on the >> operational issues between using such an approach and using a local >> addressing scheme. > > > > OK; we can investigate this further. > Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 1 09:20:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11541 for ; Wed, 1 Oct 2003 09:20:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4gtw-0007lc-Vo for ipv6-archive@odin.ietf.org; Wed, 01 Oct 2003 09:20:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91DKKhR029856 for ipv6-archive@odin.ietf.org; Wed, 1 Oct 2003 09:20:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4gtw-0007lT-RV for ipv6-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 09:20:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11518 for ; Wed, 1 Oct 2003 09:20:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4gtv-0006uL-00 for ipv6-web-archive@ietf.org; Wed, 01 Oct 2003 09:20:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4gtu-0006uI-00 for ipv6-web-archive@ietf.org; Wed, 01 Oct 2003 09:20:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4gte-0007fZ-O5; Wed, 01 Oct 2003 09:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4gtK-0007et-HL for ipv6@optimus.ietf.org; Wed, 01 Oct 2003 09:19:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11502 for ; Wed, 1 Oct 2003 09:19:35 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4gtI-0006u5-00 for ipv6@ietf.org; Wed, 01 Oct 2003 09:19:40 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A4gtI-0006u2-00 for ipv6@ietf.org; Wed, 01 Oct 2003 09:19:40 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h91DJdt16190 for ; Wed, 1 Oct 2003 16:19:39 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 1 Oct 2003 16:19:38 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 1 Oct 2003 16:19:38 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 1 Oct 2003 16:19:38 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Node Req: Issue22: 4.5.4 Default Address Selection for IPv6 - RFC3484 text Date: Wed, 1 Oct 2003 16:19:38 +0300 Message-ID: Thread-Topic: Node Req: Issue22: 4.5.4 Default Address Selection for IPv6 - RFC3484 text Thread-Index: AcOGswUYDXe7aXBNQBSyHxBWndgJkQBa59Og To: Cc: X-OriginalArrivalTime: 01 Oct 2003 13:19:38.0627 (UTC) FILETIME=[AA6E7D30:01C3881E] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Thomas, I will make the changes. John > -----Original Message----- > From: ext Thomas Narten [mailto:narten@us.ibm.com] > Sent: 29 September, 2003 20:52 > To: Loughney John (NRC/Helsinki) > Cc: ipv6@ietf.org > Subject: Re: Node Req: Issue22: 4.5.4 Default Address=20 > Selection for IPv6 > - RFC3484 text=20 >=20 >=20 > > > > 4.5.4 Default Address Selection for IPv6 - RFC3484 > > > >=20 > > > > Default Address Selection for IPv6 [RFC-3484] SHOULD=20 > be supported, if > > > > a node has more than one IPv6 address per interface or=20 > a node has > > > > more that one IPv6 interface (physical or logical) configured. > > > >=20 > > > > If supported, the rules specified in the document MUST be > > > > implemented. A node needs to belong to one site,=20 > however there is no > > > > requirement that a node be able to belong to more than=20 > one site. > > >=20 > > > This is really weasle worded. Is 3484 mandatory to=20 > _implement_ or not? > > > You can't make its implementation dependent on whether there are > > > multiple addresses, since the number of addresses a node=20 > will have is > > > not something an implementor will know, as it's an=20 > operational issue. >=20 > > Why do you say its weasley-worded? I take this as a strong=20 > SHOULD. I > > imagine that a single purpose IPv6, like a sensor may, in=20 > fact, have a > > single IP address. >=20 > The current wording suggests that there are classes of devices that > don't need to handle multiple addresses (i.e., they will only have a > single address assigned to them). This (IMO) violates a core > assumption of IPv6, that all nodes need to deal with multiple > addresses. I'd like to see a better justification to allow this. So, > I'm not objecting to the SHOULD, I'm objecting to the suggestion that > some nodes won't need to support multiple addresses. >=20 > Note: whether a site uses one or some small number of addressesd is an > operational issue, and can't really be a device implementation > decision. >=20 > > Some text clarification may be OK, though, how about > > adding to the first paragraph the following text: >=20 > > It is expected that most implementations will indeed=20 > support this, as=20 > > since the number of addresses a node will have is more of an=20 > > operational issue. >=20 > IMO, I'd like to see removal of all wording suggesting that it might > be OK for devices to support only a single address. >=20 > Thomas >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 1 10:25:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15031 for ; Wed, 1 Oct 2003 10:25:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4huI-00034x-L3 for ipv6-archive@odin.ietf.org; Wed, 01 Oct 2003 10:24:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91EOkhg011834 for ipv6-archive@odin.ietf.org; Wed, 1 Oct 2003 10:24:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4huH-00034n-Qg for ipv6-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 10:24:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14979 for ; Wed, 1 Oct 2003 10:24:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4huF-0007Yx-00 for ipv6-web-archive@ietf.org; Wed, 01 Oct 2003 10:24:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4huF-0007Yt-00 for ipv6-web-archive@ietf.org; Wed, 01 Oct 2003 10:24:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4hta-0002pI-Hk; Wed, 01 Oct 2003 10:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4htJ-0002om-M8 for ipv6@optimus.ietf.org; Wed, 01 Oct 2003 10:23:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14926 for ; Wed, 1 Oct 2003 10:23:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4htH-0007Y4-00 for ipv6@ietf.org; Wed, 01 Oct 2003 10:23:43 -0400 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1A4htG-0007XV-00 for ipv6@ietf.org; Wed, 01 Oct 2003 10:23:42 -0400 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h91EN7XZ070888; Wed, 1 Oct 2003 16:23:07 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h91EN6X1259410; Wed, 1 Oct 2003 16:23:07 +0200 Received: from zurich.ibm.com ([9.145.228.220]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA27512; Wed, 1 Oct 2003 16:23:04 +0200 Message-ID: <3F7AE334.D70A42E2@zurich.ibm.com> Date: Wed, 01 Oct 2003 16:22:44 +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: awhite@arc.corp.mot.com CC: ipv6@ietf.org Subject: Re: Comments on draft-hain-templin-ipv6-limitedrange-02.txt References: <3F730183.6090504@caspiannetworks.com> <3F730183.6090504@caspiannetworks.com> <4.3.2.7.2.20030930124555.01fd8b00@flask.cisco.com> <3F79E125.8040504@iprg.nokia.com> <3F7A2736.75566C22@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit below... Andrew White wrote: > > As the originator of section 4.8, I'll speak to this one... > > Fred Templin wrote: > > > > > 4.8 I'm afraid I couldn't understand this scenario at all. When the > > > two sites connect, do they essentially merge into a single, > > > multi-homed site? > > > > I believe the answer to this is yes, and I believe Brian Haberman > > also expressed concerns about such scenarios since they touch on > > site multi-homing. (My answer to Brian is that we are not trying > > to re-create RFC 3582 in this document.) What you would suggest > > in terms of this block of text? > > I don't think it's possible to completely divorce local addressing from > multi-homing, unless we want to go down the NAT path (any takers? No, I > thought not). Agreed. It would be rather tragic to define a new form of address to meet the requirements in this draft, and another very similar new form of address to meet multihoming requirements. It should be a goal to avoid this, and it needs to be a shared goal of the ipv6 and multi6 WGs. So I don't think it's possible to eliminate mention of multihoming from this draft, but it should be mentioned mainly for this reason. Brian C > > One local addressing model that both Tony and I have been envisioning (and > IMO the most compelling) is that of disjoint, overlapping addressing > spaces. The local network uses an internal addressing scheme for all > internal operations. When and if 'external' connectivity is applied (which > may be another 'local' network) the external space is also made available to > all nodes within the network that want external operation. Local nodes are > configured to prefer the internal addresses for internal use and the global > addresses for destinations that don't have a matching internal address. > > Note that the 'internal' addresses could be global unicast addresses or > 'local' addresses. Likewise the 'external' addresses, although these will > probably be global. The key issue is that the 'internal' addresses are > provider independent. The core address space of the network is independent > of the presence or absence of an ISP. > > For the 'zeroconf home' scenario, registration-free local addresses become > very attractive for the internal address space. They don't need to care > about ISPs or any external stuff, and unique address spaces can be easily > configured. And a RFC3484 implementation will favour them over global > addresses. > > Connecting two of these networks together is interesting. The assumption is > that the connection is via a 'local' channel - one that is (virtually) > 'inside' whatever mechanisms define the borders between the local address > spaces and the global space. However, what sort of 'merging' occurs is > harder to determine. > > Some scenarios: > > (1) Minimal merging: The two 'local' networks talk via a pair of gateways, > and all traffic for the other network's address space/s is directed to that > network's gateway. DNS and like services are similarly redirected. > > (2) Routing table merging: Full routing information is passed across the two > networks. Addresses are allocated independently by each network. > > (3) Full merging: The two networks become one network, sharing prefixes > originally owned by one or the other network across all nodes. > > Option 1 is probably easiest. Local addresses provide an advantage here > again, in that if both networks are using local addresses RFC3484 will cause > inter-network communications to favour the local addresses. > > The most interesting case in network merging occurs when the local addresses > are allocated by the routers, using the strategy described in > 'draft-white-auto-subnet-00' > (). > >From an address allocation perspective, only 'external' prefixes are > propagated - the internal addressing scheme is built into the routers. > Under this model, there is no need to propagate the internal prefixes - the > address spaces are already compatible. All that is required is to connect > the routes and propagate service information (such as DNS). External > prefixes still need to be propagated. > > -- > Andrew White > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 3 15:01:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20753 for ; Fri, 3 Oct 2003 15:01:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5VAS-0005nC-PA for ipv6-archive@odin.ietf.org; Fri, 03 Oct 2003 15:00:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93J0iY0022260 for ipv6-archive@odin.ietf.org; Fri, 3 Oct 2003 15:00:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5VAR-0005mx-Lr for ipv6-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 15:00:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20685 for ; Fri, 3 Oct 2003 15:00:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5VAO-0004wr-00 for ipv6-web-archive@ietf.org; Fri, 03 Oct 2003 15:00:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5VAO-0004wn-00 for ipv6-web-archive@ietf.org; Fri, 03 Oct 2003 15:00:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5V8n-0005br-P9; Fri, 03 Oct 2003 14:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5V8d-0005Zl-Ef for ipv6@optimus.ietf.org; Fri, 03 Oct 2003 14:58:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20575 for ; Fri, 3 Oct 2003 14:58:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5V8a-0004v6-00 for ipv6@ietf.org; Fri, 03 Oct 2003 14:58:48 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A5V8Z-0004ub-00 for ipv6@ietf.org; Fri, 03 Oct 2003 14:58:47 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h93Iw7i31623; Fri, 3 Oct 2003 11:58:07 -0700 X-mProtect: <200310031858> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8Gq8yr; Fri, 03 Oct 2003 11:58:06 PDT Message-ID: <3F7DC775.1060905@iprg.nokia.com> Date: Fri, 03 Oct 2003 12:01:09 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haberman CC: ipv6@ietf.org Subject: Re: Comments on draft-hain-templin-ipv6-limitedrange-02.txt References: <3F730183.6090504@caspiannetworks.com> <3F799994.8070400@innovationslab.net> <3F79DC5E.3080307@iprg.nokia.com> <3F7AC9A2.9070705@innovationslab.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian, For the most part, agree with all of your points of clarification; thanks. One item for further discussion: Brian Haberman wrote: >> >> Long period of time, perhaps, but how long is difficult to >> quantify. Again, perhaps this is a question for the [BAKER] >> renumbering draft. > > > I think it is quite pertinent to this draft. How long must an > address remain stable in order to satisfy this document's stability > goal? I think this question is going to be very much dependent on the use case scenarios. For example, in the future we may see deeply-networked homes in which we will have long-lived sessions, such as playing a 3hr video between the DVD player and home theater system. Indeed, there may be "always-on" sessions such as the home-security system monitoring intrusion-detection sensors around the house. On the other end of the spectrum, we will have highly-mobile environments, e.g., a vehicle that visits different Internet access points (and receives different prefix advertisements) every five miles or so it travels down the road. So, where do we draw the line? Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 3 16:35:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26278 for ; Fri, 3 Oct 2003 16:35:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5WdT-0002TH-1T for ipv6-archive@odin.ietf.org; Fri, 03 Oct 2003 16:34:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93KYltq009495 for ipv6-archive@odin.ietf.org; Fri, 3 Oct 2003 16:34:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5WdS-0002Rp-Qo for ipv6-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 16:34:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26183 for ; Fri, 3 Oct 2003 16:34:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5WdQ-00065x-00 for ipv6-web-archive@ietf.org; Fri, 03 Oct 2003 16:34:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5WdQ-00065t-00 for ipv6-web-archive@ietf.org; Fri, 03 Oct 2003 16:34:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Wck-0002I5-GI; Fri, 03 Oct 2003 16:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Wcb-0002H5-1m for ipv6@optimus.ietf.org; Fri, 03 Oct 2003 16:33:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26074 for ; Fri, 3 Oct 2003 16:33:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5WcY-00063z-00 for ipv6@ietf.org; Fri, 03 Oct 2003 16:33:50 -0400 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1A5WcW-00063h-00 for ipv6@ietf.org; Fri, 03 Oct 2003 16:33:49 -0400 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id QAA20469; Fri, 3 Oct 2003 16:33:45 -0400 (EDT) Date: Fri, 3 Oct 2003 16:33:45 -0400 (EDT) From: Dan Lanciani Message-Id: <200310032033.QAA20469@ss10.danlan.com> To: ipv6@ietf.org Subject: Re: Comments on draft-hain-templin-ipv6-limitedrange-02.txt Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Fred Templin wrote: |Brian, | |For the most part, agree with all of your points of clarification; |thanks. One item for further discussion: | |Brian Haberman wrote: | |>> |>> Long period of time, perhaps, but how long is difficult to |>> quantify. Again, perhaps this is a question for the [BAKER] |>> renumbering draft. |> |> |> I think it is quite pertinent to this draft. How long must an |> address remain stable in order to satisfy this document's stability |> goal? | | |I think this question is going to be very much dependent on |the use case scenarios. For example, in the future we may see |deeply-networked homes in which we will have long-lived |sessions, such as playing a 3hr video between the DVD player |and home theater system. Indeed, there may be "always-on" |sessions such as the home-security system monitoring |intrusion-detection sensors around the house. I continue to believe that there is more to the notion of stability than can be expressed by a simple time scalar. Any measure of stability must also take into account the ability of anyone other than the user/owner of the address to force a change either directly or indirectly. As soon as you start to consider specific time frames as the primary characteristic of stability you almost implicitly admit to a model where the control of the address space (probably even in the short term) rests with a third party. This in turn subjects the user of the address space to the technical problems of the controlling entity and (perhaps worse) to the ability of that entity to charge arbitrarily for continued stability. There may be a second-order effect here, i.e., how long is a particular stability time frame valid? Today, my ISP might be willing to guarantee me a minimum of 3 hours stability for $x. But if next month it can change the price for 3 hours of stability to 100*$x, was the address space ever really stable even by the measure of a 3 hour time frame? Ultimately I think stability is much closer to a binary property than to something that can be measured in hours. It may not (or may) be possible to guarantee local address stability in the face of global change (e.g., to a new version of IP), but to tie stability to almost anything of a smaller scope is in effect to remove stability. In particular, anything that depends on the promise and competence of the user's service provider (which in turn depends on the promises and competence of all the service providers up the line) cannot realistically provide stable addresses. There doesn't seem to be any obvious reason other than third-party control to consider specific stability time frames. Therefore, I suggest that the only reasonable life for a stable address is, to a first approximation, infinite. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 3 16:46:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27747 for ; Fri, 3 Oct 2003 16:46:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Wol-0003Rx-9Z for ipv6-archive@odin.ietf.org; Fri, 03 Oct 2003 16:46:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93KkRw4013255 for ipv6-archive@odin.ietf.org; Fri, 3 Oct 2003 16:46:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Wol-0003Ri-1o for ipv6-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 16:46:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27670 for ; Fri, 3 Oct 2003 16:46:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Woj-0006Xa-00 for ipv6-web-archive@ietf.org; Fri, 03 Oct 2003 16:46:25 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5Woi-0006XX-00 for ipv6-web-archive@ietf.org; Fri, 03 Oct 2003 16:46:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5WoN-0003IN-Co; Fri, 03 Oct 2003 16:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Wne-0003H4-3B for ipv6@optimus.ietf.org; Fri, 03 Oct 2003 16:45:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27481 for ; Fri, 3 Oct 2003 16:45:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Wnb-0006To-00 for ipv6@ietf.org; Fri, 03 Oct 2003 16:45:15 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A5Wna-0006S2-00 for ipv6@ietf.org; Fri, 03 Oct 2003 16:45:15 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h93KifL27886; Fri, 3 Oct 2003 13:44:41 -0700 X-mProtect: <200310032044> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdoKynmh; Fri, 03 Oct 2003 13:44:39 PDT Message-ID: <3F7DE06F.8080100@iprg.nokia.com> Date: Fri, 03 Oct 2003 13:47:43 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Lanciani CC: ipv6@ietf.org Subject: Re: Comments on draft-hain-templin-ipv6-limitedrange-02.txt References: <200310032033.QAA20469@ss10.danlan.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dan Lanciani wrote: >There doesn't seem to be any obvious reason other than third-party control >to consider specific stability time frames. Therefore, I suggest that the >only reasonable life for a stable address is, to a first approximation, >infinite. > I must admit that this seems to follow from my use-case example of the 24x7 home security monitoring. Other opinions? Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Oct 5 00:03:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23868 for ; Sun, 5 Oct 2003 00:03:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6072-0007R0-5h for ipv6-archive@odin.ietf.org; Sun, 05 Oct 2003 00:03:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9543GnY028577 for ipv6-archive@odin.ietf.org; Sun, 5 Oct 2003 00:03:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6072-0007Qq-1D for ipv6-web-archive@optimus.ietf.org; Sun, 05 Oct 2003 00:03:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23850 for ; Sun, 5 Oct 2003 00:03:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A606z-0006DE-00 for ipv6-web-archive@ietf.org; Sun, 05 Oct 2003 00:03:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A606z-0006DA-00 for ipv6-web-archive@ietf.org; Sun, 05 Oct 2003 00:03:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A605q-0007Iv-Bt; Sun, 05 Oct 2003 00:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A604u-0007Hh-DS for ipv6@optimus.ietf.org; Sun, 05 Oct 2003 00:01:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23786 for ; Sun, 5 Oct 2003 00:00:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A604s-0006BG-00 for ipv6@ietf.org; Sun, 05 Oct 2003 00:01:02 -0400 Received: from dsl092-066-068.bos1.dsl.speakeasy.net ([66.92.66.68] helo=cyteen.hactrn.net) by ietf-mx with esmtp (Exim 4.12) id 1A604r-00069H-00 for ipv6@ietf.org; Sun, 05 Oct 2003 00:01:01 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 1A2F31DB for ; Sun, 5 Oct 2003 00:00:27 -0400 (EDT) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 05 Oct 2003 00:00:27 -0400 Message-Id: <20031005040027.1A2F31DB@cyteen.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Messages | Bytes | Who --------+------+--------+----------+------------------------ 13.16% | 5 | 23.13% | 58507 | brian@innovationslab.net 15.79% | 6 | 12.57% | 31797 | john.loughney@nokia.com 10.53% | 4 | 14.52% | 36733 | ftemplin@iprg.nokia.com 13.16% | 5 | 9.27% | 23441 | narten@us.ibm.com 7.89% | 3 | 10.95% | 27689 | chirayu@chirayu.org 5.26% | 2 | 5.82% | 14727 | brc@zurich.ibm.com 2.63% | 1 | 2.81% | 7102 | andrew.e.white@motorola.com 2.63% | 1 | 2.76% | 6988 | slblake@torrentnet.com 2.63% | 1 | 2.08% | 5256 | ipng-incoming@danlan.com 2.63% | 1 | 2.06% | 5209 | rdroms@cisco.com 2.63% | 1 | 2.00% | 5055 | mansaxel@sunet.se 2.63% | 1 | 1.95% | 4939 | sra+ipng@hactrn.net 2.63% | 1 | 1.78% | 4510 | tony@lava.net 2.63% | 1 | 1.60% | 4045 | lutz.pressler@sernet.de 2.63% | 1 | 1.55% | 3919 | iesg@ietf.org 2.63% | 1 | 1.38% | 3490 | ahjzabistian@yahoo.com 2.63% | 1 | 1.35% | 3409 | michel@arneill-py.sacramento.ca.us 2.63% | 1 | 1.27% | 3209 | mark.andrews@isc.org 2.63% | 1 | 1.15% | 2913 | robert@digi-data.com --------+------+--------+----------+------------------------ 100.00% | 38 |100.00% | 252938 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 7 16:15:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20670 for ; Tue, 7 Oct 2003 16:15:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6yET-0004qN-Be for ipv6-archive@odin.ietf.org; Tue, 07 Oct 2003 16:14:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97KEvoY018615 for ipv6-archive@odin.ietf.org; Tue, 7 Oct 2003 16:14:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6yET-0004qA-6V for ipv6-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 16:14:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20644 for ; Tue, 7 Oct 2003 16:14:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6yER-00039V-00 for ipv6-web-archive@ietf.org; Tue, 07 Oct 2003 16:14:55 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6yER-00039O-00 for ipv6-web-archive@ietf.org; Tue, 07 Oct 2003 16:14:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6yDZ-0004kE-KP; Tue, 07 Oct 2003 16:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xwm-0003Zw-FT for ipv6@optimus.ietf.org; Tue, 07 Oct 2003 15:56:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19717 for ; Tue, 7 Oct 2003 15:56:31 -0400 (EDT) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6xwk-0002mi-00 for ipv6@ietf.org; Tue, 07 Oct 2003 15:56:38 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A6xwk-0002mf-00 for ipv6@ietf.org; Tue, 07 Oct 2003 15:56:38 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h97Jub624759 for ; Tue, 7 Oct 2003 22:56:37 +0300 (EET DST) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 7 Oct 2003 22:56:37 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 7 Oct 2003 12:56:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: Appel due to management of the "site-local issue" Date: Tue, 7 Oct 2003 15:56:31 -0400 Message-ID: Thread-Topic: Re: Appel due to management of the "site-local issue" Thread-Index: AcONDRptD6hXVmEAQ0CCP/ahUWQACQ== To: Cc: X-OriginalArrivalTime: 07 Oct 2003 19:56:33.0950 (UTC) FILETIME=[1BF2E3E0:01C38D0D] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Leif, =20 This message is a reply to the appeal that you filed on August 5, 2003 regarding our management of the "site-local issue" (the full text of your message is included below). =20 If we understand your appeal properly, you object to the e-mail poll that we sent to the IPv6 mailing list on August 4, 2003 with the subject of "Moving forward on Site-Local and Local Addressing" (the text of that message is also included below). You believe that this e-mail re-opened the question of whether or not to deprecate site-local addressing, and you consider it unacceptable for the chairs = to re-open that question on the IPv6 WG mailing list because some of the parties who may wish to provide input on that issue are not currently subscribed to the IPv6 mailing list. We agree with you that the WG has consensus to deprecate the usage of site-local unicast addressing, as discussed at the WG meeting at IETF 56 in San Francisco and confirmed on the list in April 2003. At that time, we found that the WG had consensus to deprecate the usage of IPv6 site local unicast addressing AND to investigate alternatives for local addressing, and we outlined a course of action to do both things in parallel. It is sometimes appropriate for WG chairs to re-open questions with the WG -- either because there is new information available, or because there is some other reason to believe that the consensus of the WG has changed. However, we do not believe that those conditions currently apply to the deprecation of site-local unicast addressing, and it was not our intention, by sending our message on August 4th, to re-open the question of site-local deprecation. We were attempting to further refine how the WG should move forward on the course of action that we had defined in April. In retrospect, however, we do understand your concern about the third option we offered: "C) Deprecate Site-Local addresses after an alternative is defined, standardized, and in operational practice." This option could be interpreted as indefinitely delaying (and effectively overturning) the decision of the IPv6 WG to deprecate site-local addressing. Fortunately, support for this option in the WG was very low, and it is clear that we continue to have IPv6 WG consensus to deprecate site-locals in parallel with developing an alternate local addressing mechanism. Less fortunately, the WG continues to be split on the question of whether we should deprecate site-local addressing immediately, or only after an alternative has been defined. However, we do not agree with one major point of your appeal. We believe that the IPv6 mailing list is the appropriate forum for the IPv6 working group to discuss issues and make decisions, including (potentially) changing previous decisions. People who wish to be involved in the decisions of the IPv6 WG should subscribe to the IPv6 mailing list. That said, though, we do understand that the IPv6 WG is making decisions that have wide implications for all other areas of the IETF, and it will continue to be the responsibility of the IPv6 chairs to ensure that the IPv6 WG has wide-enough input and expertise to make wise decisions in these cases. In summary, we agree with one of the points in your appeal: - Offering option (C) in our opinion poll could reasonably be interpreted as re-opening the site-local deprecation decision. But, we do not agree with the other point in your appeal: - We believe that the IPv6 mailing list is the appropriate forum in which to raise IPv6-related issues, including (as appropriate) re-opening previous decisions. Although we agree with one portion of your appeal, the primary action that we could have taken in response to this appeal (withdrawing or clarifying option (C) in our opinion poll) is now moot, as the WG has rejected option (C). Please let us know if you feel that there are other actions that we should be taking in response to your appeal. While discussing this appeal with you, via e-mail and on the phone, you also raised concerns about how little progress the IPv6 WG has made towards the deprecation of site-local addresses since making=20 the decision in April. We share your concerns about this lack of progress, and the current IPv6 WG chairs (Bob Hinden and Brian=20 Haberman) are working to accelerate this activity.=20 Leif, we appreciate your involvement in the IPv6 WG and we believe that it is very important to continue to have applications experts involved in our discussions and decisions. We hope that you will continue to participate in the IPv6 WG, that you will continue to=20 speak out when you see problems, and that you will continue to help=20 us by getting additional applications experts involved in the IPv6=20 WG. Bob Hinden and Margaret Wasserman IPv6 WG chairs at the time of this appeal (5-Aug-03) =3D=3D=3D Original Appeal Text from Leif: > Date: Tue, 05 Aug 2003 11:41:24 +0200 > From: Leif Johansson > To: narten@us.ibm.com, mrw@windriver.com > CC: ipng@sunroof.eng.sun.com, iesg@ietf.org > Subject: Appel due to management of the "site-local issue" >=20 > During the IETF meeting in San Francisco, rough consensus found that > site-local was to be deprecated. The wg was to investigate other > approaches to the problems site-local claims to solve. It should be > noted that the wg chairs explicitly before the meeting in San > Francisco asked people not directly involved in ipv6 design (security, > routing and applications people) to get involved with this issue. In > my opinion from talking to a number of collegues and from the traffic > on the mailing list those involved from other areas are no longer > actively participating in the debate since they believe that > site-locals has indeed been deprecated and that the ipv6 wg is > continuing the important work on ipv6 in the IETF. >=20 > Currently the question about the future and status of site-locals is > again beeing discussed in the wg despite the fact that consensus was > achieved in SF and confirmed on the mailing-list. This is a sign that > the wg chairs have not been able to follow the plan laid out at the SF > meeting. >=20 > I respectfully ask that the ADs to confirm the decision made in San > Francisco, later confirmed on the mailing list, and ask the wg chairs > to please move on, working on real issues regarding ipv6 than beating > this dead horse once again. >=20 > Best Regards > Leif Johansson > Stockholm university >=20 =3D=3D=3D Opinion Poll from Chairs (Subject of Appeal): > To: ipng@sunroof.eng.sun.com > Subject: Moving forward on Site-Local and Local Addressing > Cc: hinden@iprg.nokia.com >=20 > [IPv6 working group chair hat on] >=20 > I think the working group has been making good progress on replacing > site-local addresses and wanted to get feed back from the working > group on how we should move forward. This is not intended to directly > relate to the ongoing appeal of the working groups decision to > deprecate the usage site-local addresses, but to get feedback on how > to proceed. I think it is very important that we move forward on this > issue and not rehash what has happened in the past. >=20 > We now have a combined local addressing requirements document > , a specific alternative > to site-local addresses draft > (accepted as a working > group item at the Vienna IETF), and will soon have a draft describing > why site-local addresses are being deprecated and doing the formal > deprecation (authors identified and outline discussed at the Vienna > IETF). Note that all of these documents will proceed through the > normal working group and IETF processes of last calls and review. >=20 > I think legitimate questions have been raised about how the working > group should go about deprecating site-local addresses given their > maturity in the current specifications and use in deployed products. > Specifically should they be deprecated independently from having an > alternative solution available, at the same time an alternative is > available, or sometime after an alternative is available. A forth > alternative is to not replace site-local addresses in any form, but I > think the working group has made it clear that this is not a > reasonable alternative. >=20 > I would like to hear from the working group on how we should proceed. > I think the choices are: >=20 > A) Deprecate Site-Local addresses independently from having an > alternative solution available. This would mean that the working > group should treat the deprecation, and requirements and solution > documents outlined above independently from each other. If there was > no consensus on an alternative a replacement would not happen. >=20 > B) Deprecate Site-Local addresses at the same time as a alternative > solution is agreed to. This would mean advancing both documents at > the same time and making them include normative references to each > other to insure that they were published at the same time. This would > result in the deprecation only happening if a consensus was reached on > an alternative. >=20 > C) Deprecate Site-Local addresses after an alternative is defined, > standardized, and in operational practice. This would mean not > advancing a deprecation document until there was operational evidence > that the alternative was working and shown to be an improvement over > Site-Local addresses. >=20 > Note: In the above choices "Deprecate Site-Local addresses" means > publishing an RFC that does the formal deprecation. >=20 > Please respond to the list with your preference, or if there is an > alternative approach that is an improvement from the ones I outlined. > I hope that many of you will respond. >=20 > Thanks, > Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 7 16:34:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21514 for ; Tue, 7 Oct 2003 16:34:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6yXD-00064c-5p for ipv6-archive@odin.ietf.org; Tue, 07 Oct 2003 16:34:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97KYJGd023340 for ipv6-archive@odin.ietf.org; Tue, 7 Oct 2003 16:34:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6yXC-00064N-U3 for ipv6-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 16:34:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21475 for ; Tue, 7 Oct 2003 16:34:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6yXB-0003V5-00 for ipv6-web-archive@ietf.org; Tue, 07 Oct 2003 16:34:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6yXA-0003V2-00 for ipv6-web-archive@ietf.org; Tue, 07 Oct 2003 16:34:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6yWw-0005vS-Ao; Tue, 07 Oct 2003 16:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6yWL-0005v0-FS for ipv6@optimus.ietf.org; Tue, 07 Oct 2003 16:33:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21456 for ; Tue, 7 Oct 2003 16:33:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6yWJ-0003UU-00 for ipv6@ietf.org; Tue, 07 Oct 2003 16:33:23 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A6yWI-0003UE-00 for ipv6@ietf.org; Tue, 07 Oct 2003 16:33:22 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h97KWh030757; Tue, 7 Oct 2003 13:32:43 -0700 X-mProtect: <200310072032> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdM9Lj37; Tue, 07 Oct 2003 13:32:40 PDT Message-Id: <4.3.2.7.2.20031007131731.03006fe8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 Oct 2003 13:29:53 -0700 To: ipv6@ietf.org From: Bob Hinden Subject: Reminder: Internet-Draft cutoff dates for Minneapolis IETF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Please note I-D cutoff dates: October 13, Monday Date by which Secretariat wants warning about impending WG -00 documents from WG chairs. That means you should warn the chairs about impending WG -00 docs before the 13th. October 20, Monday Internet Draft Cut-off for initial document (-00) submission at 09:00 ET October 27, Monday Internet Draft final submission cut-off at 09:00 ET -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 7 23:04:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02646 for ; Tue, 7 Oct 2003 23:04:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A74cr-00078a-JE for ipv6-archive@odin.ietf.org; Tue, 07 Oct 2003 23:04:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9834WVr027430 for ipv6-archive@odin.ietf.org; Tue, 7 Oct 2003 23:04:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A74ck-00074g-Ch for ipv6-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 23:04:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02616 for ; Tue, 7 Oct 2003 23:04:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A74cf-00072y-00 for ipv6-web-archive@ietf.org; Tue, 07 Oct 2003 23:04:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A74ce-00072v-00 for ipv6-web-archive@ietf.org; Tue, 07 Oct 2003 23:04:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A74bN-0006vK-D5; Tue, 07 Oct 2003 23:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A74b0-0006sv-3Q for ipv6@optimus.ietf.org; Tue, 07 Oct 2003 23:02:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02573 for ; Tue, 7 Oct 2003 23:02:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A74aw-000724-00 for ipv6@ietf.org; Tue, 07 Oct 2003 23:02:34 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1A74av-00071i-00 for ipv6@ietf.org; Tue, 07 Oct 2003 23:02:33 -0400 Received: from jurassic.eng.sun.com ([129.146.89.50]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h98324X0015314 for ; Tue, 7 Oct 2003 20:02:04 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.10+Sun/8.12.10) with SMTP id h98323KT760472; Tue, 7 Oct 2003 20:02:03 -0700 (PDT) Message-Id: <200310080302.h98323KT760472@jurassic.eng.sun.com> Date: Tue, 7 Oct 2003 20:03:17 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: comments on address selection API To: Sebastien.Roy@Sun.COM, ipv6@ietf.org Cc: Erik.Nordmark@Sun.COM, Julien.Laganier@Sun.COM, samita.chakrabarti@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: dUA0kgcV/C3uGjEDMfWYaw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_31 SunOS 5.10 sun4u sparc Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , The co-authors have discussed Sebasiten's issues off-line and here is what we decided on the modification in the next version of the draft. Let's close it on this alias. Please include the folks on the CC list on your reply, thanks. In summary, the issues were: 1) IPV6_PREFER_SRC_TUNNEL, IPV6_PREFER_SRC_NATIVE and their corresponding AI_* flags are unintuitive, because there is no source address selection rule that maps to destination address selection rule 7 (prefer native transport). 2) IPV6_PREFER_SRC_*SCOPE flags are not required to set, because it can be handled by rule 2 for source address selection (prefer appropriate scope) automatically by default SAS rules. 3) AI_PREFER_SRC_*SCOPE flags don't make sense as they don't map to destiantion address selection rules (rule2-prefer matching scope, rule8- prefer smaller scope) > I have an additional comment on the draft relating to the four new > AI_PREFER_* getaddrinfo() flags (new in version 1 of the draft). > > AI_PREFER_SRC_LARGESTSCOPE /* Prefer largest scope */ > AI_PREFER_SRC_LOWERSCOPE /* Prefer lower than largest scope */ > AI_PREFER_SRC_TUNNEL /* Prefer address of tunnel interface */ > AI_PREFER_SRC_NATIVE /* Prefer native IPv6 address */ > > I don't know if this is the right place to be defining these > preferences. By defining these flags, wouldn't we be suggesting that > the control of these two destination address selection rules (rules 7 > and 8) belongs to application developers? Preferring larger scope > destinations rather than smaller scope destinations seems like a > situational run-time preference, and same with preferring tunnel Proposals: Case 1) Erik pointed out that you can't tell whether the peer has associated a particular address with a tunnel interface or not. Although 6to4 addresses are distinguishable but that is not true for other types of tunnels. Also this one cannot control preference of tunnels if multiple types of tunnels exist ( which still needs to be done by preference table) Moreover, choice of interface for destination address could be a function of routing behavior in the system as well. Thus it is hard to predict the dst addr for a tunnel using this socket option. Since there is no rule specific to source address selection to this effect, we decided to drop this set of flags from the API. Decision : drop IPV6_PREFER_SRC_TUNNEL{NATIVE} and corresponding AI* flags. Case 2) The draft cannot depend on a particular implementation. Thus API draft needs to provide both socket-option flag and corresponding AI_PREFER* flag to support different implementations. It is possible that in some implementations, one of the operations may be a NO-OP. Case 3) We need to clarify and map both source address selection rule (rule#2) and destination addr selection rules(2, 8) separately for *SCOPE. For all other destination address selection rules, they are covered by the RFC3484. So the new proposal: * change the option name from IPV6_SRC_PREFERENCES to IPV6_ADDR_PREFERENCES * Socket option flags : IPV6_PREFER_SRC_LARGESCOPE IPV6_PREFER_SRC_SMALLSCOPE IPV6_PREFER_DST_LARGESCOPE IPV6_PREFER_DST_SMALLSCOPE * AI flags : AI_PREFER_SRC_*SCOPE AI_PREFER_DST_*SCOPE Requirements: a particular socket option flag and corresponding AI flag must be set for a correct operation. Thus it is advisable to set both: IPV6_PREFER_SRC_*SCOPE | IPV6_PREFER_DST*SCOPE and corresponding AI flags in order to see desired results from (SAS #2, DAS #2, #8). Thanks, -Samita -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 8 05:25:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07450 for ; Wed, 8 Oct 2003 05:25:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7AZZ-0001ou-GM for ipv6-archive@odin.ietf.org; Wed, 08 Oct 2003 05:25:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h989PXdI006992 for ipv6-archive@odin.ietf.org; Wed, 8 Oct 2003 05:25:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7AZY-0001oh-QM for ipv6-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 05:25:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07410 for ; Wed, 8 Oct 2003 05:25:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7AZV-0002bd-00 for ipv6-web-archive@ietf.org; Wed, 08 Oct 2003 05:25:29 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7AZU-0002ba-00 for ipv6-web-archive@ietf.org; Wed, 08 Oct 2003 05:25:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7AZ4-0001if-Pq; Wed, 08 Oct 2003 05:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A73Jk-0003lb-B9 for ipv6@optimus.ietf.org; Tue, 07 Oct 2003 21:40:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00932 for ; Tue, 7 Oct 2003 21:40:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A73Jh-0006Nm-00 for ipv6@ietf.org; Tue, 07 Oct 2003 21:40:41 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1A73Jg-0006Nj-00 for ipv6@ietf.org; Tue, 07 Oct 2003 21:40:40 -0400 Received: from jurassic.eng.sun.com ([129.146.87.31]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h981eeaV002955 for ; Tue, 7 Oct 2003 19:40:40 -0600 (MDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.10+Sun/8.12.10) with SMTP id h981eeKT733896; Tue, 7 Oct 2003 18:40:40 -0700 (PDT) Message-Id: <200310080140.h981eeKT733896@jurassic.eng.sun.com> Date: Tue, 7 Oct 2003 18:41:54 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: comments on address selection API To: Sebastien.Roy@Sun.COM, ipv6@ietf.org Cc: Erik.Nordmark@Sun.COM, Julien.Laganier@Sun.COM, samita.chakrabarti@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: xXDYd3jlAI1oFmeDeL0g5Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_31 SunOS 5.10 sun4u sparc Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , The co-authors have discussed Sebasiten's issues off-line and here is what we decided on the modification in the next version of the draft. Let's close it on this alias. Please include the folks on the CC list on your reply, thanks. In summary, the issues were: 1) IPV6_PREFER_SRC_TUNNEL, IPV6_PREFER_SRC_NATIVE and their corresponding AI_* flags are unintuitive, because there is no source address selection rule that maps to destination address selection rule 7 (prefer native transport). 2) IPV6_PREFER_SRC_*SCOPE flags are not required to set, because it can be handled by rule 2 for source address selection (prefer appropriate scope) automatically by default SAS rules. 3) AI_PREFER_SRC_*SCOPE flags don't make sense as they don't map to destiantion address selection rules (rule2-prefer matching scope, rule8- prefer smaller scope) > I have an additional comment on the draft relating to the four new > AI_PREFER_* getaddrinfo() flags (new in version 1 of the draft). > > AI_PREFER_SRC_LARGESTSCOPE /* Prefer largest scope */ > AI_PREFER_SRC_LOWERSCOPE /* Prefer lower than largest scope */ > AI_PREFER_SRC_TUNNEL /* Prefer address of tunnel interface */ > AI_PREFER_SRC_NATIVE /* Prefer native IPv6 address */ > > I don't know if this is the right place to be defining these > preferences. By defining these flags, wouldn't we be suggesting that > the control of these two destination address selection rules (rules 7 > and 8) belongs to application developers? Preferring larger scope > destinations rather than smaller scope destinations seems like a > situational run-time preference, and same with preferring tunnel Proposals: Case 1) Erik pointed out that you can't tell whether the peer has associated a particular address with a tunnel interface or not. Although 6to4 addresses are distinguishable but that is not true for other types of tunnels. Also this one cannot control preference of tunnels if multiple types of tunnels exist ( which still needs to be done by preference table) Moreover, choice of interface for destination address could be a function of routing behavior in the system as well. Thus it is hard to predict the dst addr for a tunnel using this socket option. Since there is no rule specific to source address selection to this effect, we decided to drop this set of flags from the API. Decision : drop IPV6_PREFER_SRC_TUNNEL{NATIVE} and corresponding AI* flags. Case 2) The draft cannot depend on a particular implementation. Thus API draft needs to provide both socket-option flag and corresponding AI_PREFER* flag to support different implementations. It is possible that in some implementations, one of the operations may be a NO-OP. Case 3) We need to clarify and map both source address selection rule (rule#2) and destination addr selection rules(2, 8) separately for *SCOPE. For all other destination address selection rules, they are covered by the RFC3484. So the new proposal: * change the option name from IPV6_SRC_PREFERENCES to IPV6_ADDR_PREFERENCES * Socket option flags : IPV6_PREFER_SRC_LARGESCOPE IPV6_PREFER_SRC_SMALLSCOPE IPV6_PREFER_DST_LARGESCOPE IPV6_PREFER_DST_SMALLSCOPE * AI flags : AI_PREFER_SRC_*SCOPE AI_PREFER_DST_*SCOPE Requirements: a particular socket option flag and corresponding AI flag must be set for a correct operation. Thus it is advisable to set both: IPV6_PREFER_SRC_*SCOPE | IPV6_PREFER_DST*SCOPE and corresponding AI flags in order to see desired results from (SAS #2, DAS #2, #8). Thanks, -Samita -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 8 08:38:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11891 for ; Wed, 8 Oct 2003 08:38:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7DaG-0002gr-64 for ipv6-archive@odin.ietf.org; Wed, 08 Oct 2003 08:38:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98CcSS7010335 for ipv6-archive@odin.ietf.org; Wed, 8 Oct 2003 08:38:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7DaG-0002gc-1b for ipv6-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 08:38:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11862 for ; Wed, 8 Oct 2003 08:38:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7DaE-0004Hu-00 for ipv6-web-archive@ietf.org; Wed, 08 Oct 2003 08:38:26 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7DaE-0004Hr-00 for ipv6-web-archive@ietf.org; Wed, 08 Oct 2003 08:38:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7DZq-0002Yj-Fj; Wed, 08 Oct 2003 08:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7DZG-0002QR-6m for ipv6@optimus.ietf.org; Wed, 08 Oct 2003 08:37:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11809 for ; Wed, 8 Oct 2003 08:37:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7DZE-0004Gx-00 for ipv6@ietf.org; Wed, 08 Oct 2003 08:37:24 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1A7DZE-0004GR-00 for ipv6@ietf.org; Wed, 08 Oct 2003 08:37:24 -0400 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h98CapV17963 for ; Wed, 8 Oct 2003 05:36:51 -0700 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-72.chvlva.adelphia.net [68.65.120.72]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h98Cc3tX023819 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 8 Oct 2003 05:38:07 -0700 Message-ID: <3F8404C6.30609@innovationslab.net> Date: Wed, 08 Oct 2003 08:36:22 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: 2nd Call for Agenda Items Content-Type: multipart/mixed; boundary="------------000301060708090002070401" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------000301060708090002070401 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Attached is the agenda for Minneapolis as it currently stands. Work Group participants are encouraged to contact the chairs with other topics they wish to have discussed at the meeting. Regards, Brian & Bob IPv6 WG co-chairs --------------000301060708090002070401 Content-Type: text/plain; name="Agenda.txt" Content-Disposition: inline; filename="Agenda.txt" Content-Transfer-Encoding: 7bit Tuesday (11/11/03) 0900-1130 ------------------------------ Intro & Agenda Bashing 5 minutes Milestone Review and Document Status 10 minutes MIB Documents 10 minutes ICMP Updates 10 minutes NDP/Stateless Autoconfig Updates 30 minutes Node Requirements 10 minutes Flow Label IESG Comments 10 minutes Identifier/Locator Separation 15 minutes Interoperability Reports??? 5 minutes Wednesday (11/12/03) 1300-1500 ------------------------------ Intro & Agenda Bashing 5 minutes Local Addressing Requirements 20 minutes SL Deprecation Document 20 minutes ULA Document 15 minutes Address Architecture Update 15 minutes Scoped Address Arch Document 15 minutes --------------000301060708090002070401-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 8 12:34:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26531 for ; Wed, 8 Oct 2003 12:34:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7HFy-0000lE-CR for ipv6-archive@odin.ietf.org; Wed, 08 Oct 2003 12:33:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98GXkxs002919 for ipv6-archive@odin.ietf.org; Wed, 8 Oct 2003 12:33:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7HFx-0000l0-VR for ipv6-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 12:33:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26457 for ; Wed, 8 Oct 2003 12:33:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7HFw-0000nJ-00 for ipv6-web-archive@ietf.org; Wed, 08 Oct 2003 12:33:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7HFv-0000nG-00 for ipv6-web-archive@ietf.org; Wed, 08 Oct 2003 12:33:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7HFG-0000eB-7L; Wed, 08 Oct 2003 12:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7HF4-0000cs-EB for ipv6@optimus.ietf.org; Wed, 08 Oct 2003 12:32:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26419 for ; Wed, 8 Oct 2003 12:32:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7HF2-0000mE-00 for ipv6@ietf.org; Wed, 08 Oct 2003 12:32:48 -0400 Received: from h008.c001.snv.cp.net ([209.228.32.122] helo=c001.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 1A7HF1-0000mB-00 for ipv6@ietf.org; Wed, 08 Oct 2003 12:32:48 -0400 Received: (cpmta 6044 invoked from network); 8 Oct 2003 09:32:44 -0700 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.122) with SMTP; 8 Oct 2003 09:32:44 -0700 X-Sent: 8 Oct 2003 16:32:44 GMT Message-ID: <001e01c38db9$e94d2880$a1051eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <010701c37b57$f02e1930$010aa8c0@chirayu.org> Subject: What is the current status of geographic location in the IPv6 address? Date: Wed, 8 Oct 2003 18:33:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have missed a little bit of the converstions about this, so forgive me for asking what once was a simple question: What is the current status of geographic location in the IPv6 address? Once it was part of the standard, is this still true, and if so how or if not what replaced it. thanks, Eric -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 8 15:09:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03865 for ; Wed, 8 Oct 2003 15:09:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Jgg-0003El-IM for ipv6-archive@odin.ietf.org; Wed, 08 Oct 2003 15:09:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98J9UCE012437 for ipv6-archive@odin.ietf.org; Wed, 8 Oct 2003 15:09:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Jgg-0003EW-Ct for ipv6-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 15:09:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03781 for ; Wed, 8 Oct 2003 15:09:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Jgd-0002yG-00 for ipv6-web-archive@ietf.org; Wed, 08 Oct 2003 15:09:27 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7Jgc-0002yD-00 for ipv6-web-archive@ietf.org; Wed, 08 Oct 2003 15:09:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JgD-00038r-8R; Wed, 08 Oct 2003 15:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Jfg-00038G-N7 for ipv6@optimus.ietf.org; Wed, 08 Oct 2003 15:08:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03620 for ; Wed, 8 Oct 2003 15:08:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Jfd-0002xo-00 for ipv6@ietf.org; Wed, 08 Oct 2003 15:08:25 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1A7Jfc-0002xK-00 for ipv6@ietf.org; Wed, 08 Oct 2003 15:08:25 -0400 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h98J7rV20174; Wed, 8 Oct 2003 12:07:53 -0700 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-72.chvlva.adelphia.net [68.65.120.72]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h98J96tX024910 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 8 Oct 2003 12:09:09 -0700 Message-ID: <3F846066.5010502@innovationslab.net> Date: Wed, 08 Oct 2003 15:07:18 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: EricLKlein CC: ipv6@ietf.org Subject: Re: What is the current status of geographic location in the IPv6 address? References: <010701c37b57$f02e1930$010aa8c0@chirayu.org> <001e01c38db9$e94d2880$a1051eac@ttitelecom.com> In-Reply-To: <001e01c38db9$e94d2880$a1051eac@ttitelecom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric, I do not recall geographic-based addresses ever being a part of the IPv6 standards. Tony Hain has an individual ID that discusses one possible approach (draft-hain-ipv6-pi-addr-05.txt). In addition, the geopriv working group is chartered with how geographic location can be securely/privately provided for needed services (e.g. emergency response). Regards, Brian EricLKlein wrote: > I have missed a little bit of the converstions about this, so forgive me for > asking what once was a simple question: > > What is the current status of geographic location in the IPv6 address? Once > it was part of the standard, is this still true, and if so how or if not > what replaced it. > > thanks, > Eric > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 8 19:34:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14915 for ; Wed, 8 Oct 2003 19:34:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NpG-0001Me-HT for ipv6-archive@odin.ietf.org; Wed, 08 Oct 2003 19:34:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98NYc2X005241 for ipv6-archive@odin.ietf.org; Wed, 8 Oct 2003 19:34:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NpG-0001MS-Cn for ipv6-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 19:34:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14893 for ; Wed, 8 Oct 2003 19:34:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7NpE-0005vR-00 for ipv6-web-archive@ietf.org; Wed, 08 Oct 2003 19:34:36 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7NpE-0005vM-00 for ipv6-web-archive@ietf.org; Wed, 08 Oct 2003 19:34:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Nog-0001Ap-EP; Wed, 08 Oct 2003 19:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Nni-0001AQ-Vf for ipv6@optimus.ietf.org; Wed, 08 Oct 2003 19:33:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14881 for ; Wed, 8 Oct 2003 19:32:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Nnh-0005uz-00 for ipv6@ietf.org; Wed, 08 Oct 2003 19:33:01 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1A7Nng-0005ud-00 for ipv6@ietf.org; Wed, 08 Oct 2003 19:33:00 -0400 Content-class: urn:content-classes:message Subject: RE: What is the current status of geographic location in the IPv6 address? Date: Wed, 8 Oct 2003 16:32:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: What is the current status of geographic location in the IPv6 address? Thread-Index: AcON0IOR27qip95jS9mEQWgRukR3KQAI2+KQ From: "Michel Py" To: "Brian Haberman" , "EricLKlein" Cc: Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Brian Haberman wrote: > I do not recall geographic-based addresses ever being a > part of the IPv6 standards. I don't either. > Tony Hain has an individual ID that discusses one > possible approach (draft-hain-ipv6-pi-addr-05.txt). Another approach based on a combination of population and geography is here: http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt One of the advantages of geographic allocation is that it is most of the time aggregatable. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 9 03:55:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10344 for ; Thu, 9 Oct 2003 03:55:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Vdq-0001TG-TC for ipv6-archive@odin.ietf.org; Thu, 09 Oct 2003 03:55:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h997tMsG005650 for ipv6-archive@odin.ietf.org; Thu, 9 Oct 2003 03:55:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Vdp-0001So-QZ for ipv6-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 03:55:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10306 for ; Thu, 9 Oct 2003 03:55:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Vdn-00031Y-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 03:55:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7Vdm-00031V-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 03:55:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7VcX-0001Cy-Un; Thu, 09 Oct 2003 03:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Vbv-0001CD-0t for ipv6@optimus.ietf.org; Thu, 09 Oct 2003 03:53:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10269 for ; Thu, 9 Oct 2003 03:53:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Vbs-00030c-00 for ipv6@ietf.org; Thu, 09 Oct 2003 03:53:20 -0400 Received: from as13-3-2.rny.s.bonet.se ([217.215.166.49] helo=klapautius.it.su.se) by ietf-mx with esmtp (Exim 4.12) id 1A7Vbr-00030Z-00 for ipv6@ietf.org; Thu, 09 Oct 2003 03:53:19 -0400 Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h999prJ07685; Thu, 9 Oct 2003 11:51:54 +0200 Message-ID: <3F852FB9.10901@it.su.se> Date: Thu, 09 Oct 2003 11:51:53 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Margaret.Wasserman@nokia.com CC: ipv6@ietf.org Subject: Re: Appel due to management of the "site-local issue" References: In-Reply-To: X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Margaret.Wasserman@nokia.com wrote: | | Hi Leif, | | This message is a reply to the appeal that you filed on August 5, 2003 | regarding our management of the "site-local issue" (the full text | of your message is included below). I am happy with your reply to my appeal. Cheers Leif. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/hS+48Jx8FtbMZncRAhyLAKCOoc+Xh6nTZd/ue8izvP7C6KJ3vACeK+LM y9wbHp1php022LQsmkzajHU= =eaKZ -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 9 04:16:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11237 for ; Thu, 9 Oct 2003 04:16:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Vxf-0003ej-Pq for ipv6-archive@odin.ietf.org; Thu, 09 Oct 2003 04:15:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h998FprB014054 for ipv6-archive@odin.ietf.org; Thu, 9 Oct 2003 04:15:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Vxe-0003eb-RP for ipv6-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 04:15:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11194 for ; Thu, 9 Oct 2003 04:15:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Vxc-0003LB-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 04:15:48 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7Vxb-0003L8-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 04:15:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Vws-0003Qw-TO; Thu, 09 Oct 2003 04:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Vw7-0003PR-1x for ipv6@optimus.ietf.org; Thu, 09 Oct 2003 04:14:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11152 for ; Thu, 9 Oct 2003 04:14:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Vw4-0003Jf-00 for ipv6@ietf.org; Thu, 09 Oct 2003 04:14:12 -0400 Received: from wiprom2mx2.wipro.com ([203.197.164.42]) by ietf-mx with esmtp (Exim 4.12) id 1A7Vw2-0003J8-00 for ipv6@ietf.org; Thu, 09 Oct 2003 04:14:11 -0400 Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx2.wipro.com (8.12.9/8.12.9) with SMTP id h998DX1T026740 for ; Thu, 9 Oct 2003 13:43:38 +0530 (IST) Received: from blr-m2-msg.wipro.com ([10.116.50.99]) by blr-m1-bh4.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 9 Oct 2003 13:42:39 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-834ed425-735a-4d76-89b2-8a1542a3791f" Subject: unsubscribe Date: Thu, 9 Oct 2003 13:42:39 +0530 Message-ID: Thread-Topic: unsubscribe Thread-Index: AcOOPRro6SMCl/mBSeu0DAV9oIHj8g== From: "Srinivasa Rao Nalluri" To: X-OriginalArrivalTime: 09 Oct 2003 08:12:39.0985 (UTC) FILETIME=[1B5EC210:01C38E3D] Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPartTM-000-834ed425-735a-4d76-89b2-8a1542a3791f Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38E3D.1AEF3760" ------_=_NextPart_001_01C38E3D.1AEF3760 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable unsubscribe=20 ------_=_NextPart_001_01C38E3D.1AEF3760 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable unsubscribe

unsubscribe

------_=_NextPart_001_01C38E3D.1AEF3760-- ------=_NextPartTM-000-834ed425-735a-4d76-89b2-8a1542a3791f-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 9 05:17:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13075 for ; Thu, 9 Oct 2003 05:17:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Wv9-0007wA-CD for ipv6-archive@odin.ietf.org; Thu, 09 Oct 2003 05:17:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h999HJj6030504 for ipv6-archive@odin.ietf.org; Thu, 9 Oct 2003 05:17:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Wv8-0007vv-01 for ipv6-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 05:17:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13049 for ; Thu, 9 Oct 2003 05:17:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Wv4-000440-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 05:17:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7Wv4-00043x-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 05:17:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Wtv-0007hu-4K; Thu, 09 Oct 2003 05:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7UXz-00067J-9Q for ipv6@optimus.ietf.org; Thu, 09 Oct 2003 02:45:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08875 for ; Thu, 9 Oct 2003 02:45:06 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7UXv-0002TZ-00 for ipv6@ietf.org; Thu, 09 Oct 2003 02:45:11 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A7UXk-0002TQ-00 for ipv6@ietf.org; Thu, 09 Oct 2003 02:45:10 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h996j0t25301 for ; Thu, 9 Oct 2003 09:45:00 +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, 9 Oct 2003 09:44:56 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 9 Oct 2003 09:44:56 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 9 Oct 2003 09:44:55 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 X-OriginalArrivalTime: 09 Oct 2003 06:42:58.0651 (UTC) FILETIME=[93D85AB0:01C38E30] Subject: RE: Review of draft-ietf-ipv6-node-requirements-05.txt Date: Thu, 9 Oct 2003 09:44:55 +0300 Message-ID: Thread-Topic: Review of draft-ietf-ipv6-node-requirements-05.txt Thread-Index: AcNwnGGOxqGPdrPMRoKnfXbgo8CBDgdfUOqA To: , Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Chirayu, Thanks for the comments. The document has already passed WG last call and I am finalizing some text based upon AD review. I am uncomfortable about making major changes to the document at this point, unless there is strong reason to do so & strong consensus in the WG. > General comments: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > I am slightly confused about the philosophy behind organization of the > content. I would expect a requirements draft of this sort to=20 > contain points of the following nature.=20 >=20 > a) All sections of the RFC's should mention statements of the form > "XXX [RFC-YYYY] MUST be implemented for nodes that blah blah blah". = (Note the > usage of the word implemented) Do you have a reason for thinking this? Other requirement drafts do not adhere to this type of layout. =20 > b) If there is a change in the requirement of a certain section in = the > RFC mentioned in point a) has been changed (eg from a SHOULD to a = MUST), > mention the corresponding section number, and state the change. There are no such changes. >=20 > c) If there is no change in any of the requirements specified by the > RFC in a) but certain sections have to be emphasized or clarified for = any > reason. Mention the reason, and *quote* the section (if possible). There shouldn't be such changes; I believe Thomas' review clarified text in a few sections. > "Unnecessary text" comments: > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > 1. Section 4.1 - "Internet Protocol Version 6 - RFC2460" >=20 > The following text should be removed. IMHO, it does not add any more = value > than what is already stated in RFC 2460. >=20 > "Unrecognized options in Hop-by-Hop Options or Destination Options > extensions MUST be processed as described in RFC 2460." >=20 > "The node MUST follow the packet transmission rules in RFC 2460. " >=20 > "It should be > noted that there is some discussion about the use of Routing = Headers > and possible security threats [IPv6-RH] caused by them." At this point, I don't see the reason to remove the text, it has wg = consensus and I don't think it hurts the document. > 2. What is the use of this statement in section 3.3? Does it imply = additional > behavior for a de facto IPv6/ATM driver? If not, can we remove it? If = yes, can > we add some more clarifications? >=20 > "Additionally, the specification states: >=20 > A minimally conforming IPv6/ATM driver SHALL support the PVC = mode > of operation. An IPv6/ATM driver that supports the full SVC mode > SHALL also support PVC mode of operation." This comes from the RFC, therefore I don't see the need for changes. =20 > 3. Section 4.2. >=20 > What is the need of presenting all the requirements in RFC 2461 in = concise in > this section? IMHO, it does not help clarify or understand RFC 2461 = better. > Organizing text in this manner is a recipe for developing = contradictions. For > example, the comment in Thomas's email about DAD. If you still think = that > presenting the requirements of RFC 2461 helps...please reorganize the = section. > You can probably have two subsections: >=20 > 1. Main requirements from RFC2461 > =20 > This section restates the main requirements of RFC2461. It in = no > way modifies the content of RFC2461.=20 >=20 > 2. Deviations from RFC2461 >=20 > 4. Irrespective of how you handle comment 3), some of the text in this = section > is redundant. >=20 > ---[First set of redundant statements]---- > "Duplicate Address Detection MUST be supported (RFC2462 section 5.4 > specifies DAD MUST take place on all unicast addresses)." >=20 > "Sending and Receiving Neighbor Solicitation (NS) and Neighbor > Advertisement (NA) MUST be supported. NS and NA messages are = required > for Duplicate Address Detection (DAD)." > --- >=20 > ---[Second set of redundant statements]--- > "Neighbor Unreachability Detection (NUD) MUST be supported for all = paths =20 > between hosts and neighboring nodes." >=20 > "However, when a node receives a unicast Neighbor Solicitation = (NS)=20 > message (that may be a NUD's NS), the node MUST respond to it = (i.e. send a >=20 > unicast Neighbor Advertisement)." > --- I believe we've gone through some of this text with Thomas, so I think the updated text is now sufficient. > "Need clarification" comments > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >=20 > 1. Section 4.1=20 > =20 > What is the intent of the following paragraph? Do you mean that all = nodes > should implement the host functionality? If so, does this mean that = all > routers should support the capability of being a final destination = (host)? >=20 > The capability of being a final destination MUST be supported, > whereas the capability of being an intermediate destination MAY = be > supported (i.e. - host functionality vs. router functionality). All nodes need to be able to terminate packets. All nodes may be able to route packets. > 2. Section 4.2 "Neighbor Discovery for IPv6 - RFC2461" >=20 > This section states that Neighbor Discovery SHOULD be supported. After = the > quote it states - "Some detailed analysis of Neighbor Discovery = follows". In > the following paragraphs, all the requirements are of type MUST. Do = you mean > that these following requirements MUST be implemented only if ND is > implemented? Whatever the reason, a clarification must be added. The 2461 has specific text about what must be supported. We've already clarified some of the text. We've adjusted some of the text already. = The analysis is meant to provide some clarification. > 3. Section 4.2 - Some general comments >=20 > "However, an implementation MAY support disabling this=20 > function." Clarify why? Text is already removed. =20 > "It is not required for paths between routers." Restate the sentence = using the > correct keywords? I didn't think we needed keywords here. > "However, the implementation MAY support the option of disabling this > function." Clarify why? Text is removed, as per Thomas' comments. > "A host implementation MUST support sending Router Solicitations, but > it MAY support a configuration option to disable this functionality." = Clarify > why? Discussions on the mailing list indicated that it is required to = implement the code to send RS, but not required to peform RS. =20 > "Redirect functionionality SHOULD be supported. If the node is a = router, > Redirect functionionality MUST be supported." Is there no need to have = a > configuration option to disable this functionality as specified for = the other > functionalities? During the discussions in the WG, no one suggested that such = functionality is requiered. > 5. Section 9. >=20 > What do you imply by routing-specific functionality? The statement = needs some > support to make it unambiguous. >=20 > Currently, this section does not discuss routin- > specific requirements. Do you have text, I am not sure what you are expecting. =20 > 6. Section 10.1.1 >=20 > I am a bit ignorant of SNMP. But, does the following sentence have a > well-known meaning? >=20 > Support for this MIB does not imply that IPv4 or IPv4 specific > portions of this MIB be supported. The MIBs have support for both IPv4 and IPv6 - however, we are not=20 concerned with the IPv4 funcion =20 > 7. Section 11 >=20 > Thomas's comments on this section are bang on target. >=20 > 8. Any particular reason for not including a section on "Application = API's"?=20 API's are purely optional. >=20 > 9. Section 5.3.2 >=20 > "For those IPv6 Nodes that implement DHCP, those nodes MUST use = DHCP > upon the receipt of a Router Advertisement with the 'O' flag set = (see > section 5.5.3 of RFC2462)" >=20 > a) Shouldn't the above sentence apply only to hosts, and not nodes? I can clarify text. =20 > b) I do not think the node should always wait for a RA with 'O' = flag set > before using DHCP. If the node knows that the parameters that it needs = are > going to be provided by DHCP, then it can start DHCP at the same time = it sends > the RS to speed up the boot process. Hence, the correct keyword should = be > SHOULD. You are talking about behavior. There is no requirement in the above = text that states that nodes must wait to get the 'O' flag. It just is saying what the node must do when it gets an 'O' flag. > "Stateless DHCPv6 [DHCPv6-SL], a subset of DHCPv6, can be..." >=20 > Rephrase to "Stateless DHCPv6 [DHCPv6-SL], a subset of=20 > DHCPv6, MAY be..." Text is removed, as per Thomas' comments. > 10. Section 6. >=20 > I might have missed the past discussion. Are we planning to eventually = fill > this section with references to the various transition mechanisms = defined by > IETF? Hmm..may be I can rephrase to a more basic questions - What is = the > purpose of this section?=20 We are not going to handle all of the transition mechanism, as = transition mechanisms are not requirements. > 11. Section 4.5.3 >=20 > A reference should be provided for the statement below. Otherwise, > implementers will not know how to interpret this sentence and = identify/fix > related problems. >=20 > It is noted that a number of applications do not work > with addresses generated with this method, while other applications > work quite well with them. =20 The wg could come to no consensus on what to put here. It is partially implementation specific; partly deployment specific. > 1. Remove the acronym of ULP >=20 > 2. Some of the sentences refer to the implementation as "the=20 > implementation", > and some as "an implementation". Some consistency is needed.=20 > I prefer "an > implementation" >=20 > 3. Some consistency nitpicks. >=20 > "...an implementation MAY support disabling this function." >=20 > "...the implementation MAY support the option of disabling=20 > this function." >=20 > "..but it MAY support a configuration option to disable this > functionality." >=20 > 5. s/functionionality/functionality >=20 > 6. s/routin-/routing >=20 > 7. As stated by Thomas, retire the word support in favor of=20 > implement in the > relevant sections. >=20 > 8. Section 5.3.2 >=20 > s/this type of node is/these types of nodes are/ >=20 > For IPv6 Nodes > that do not implement DHCP, the 'O' flag of a Router Advertisement > can be ignored. Furthermore, in the absence of a router, this type > of node is not required to initiate DHCP. >=20 > 9. Section 7.1 >=20 > Use the correct keyword (MAY) in the below sentence. >=20 > "Routers do not need to support route optimization or home agent > functionality." >=20 > 10. Section 10.=20 >=20 > Rephrase. >=20 > "At least the following two MIBs SHOULD be supported MIBs SHOULD be > supported by nodes that support an SNMP agent." Will look at updating according to your editiorial suggestions. thanks, John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 9 08:15:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17071 for ; Thu, 9 Oct 2003 08:15:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ZhG-00086l-5w for ipv6-archive@odin.ietf.org; Thu, 09 Oct 2003 08:15:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99CFAC6031161 for ipv6-archive@odin.ietf.org; Thu, 9 Oct 2003 08:15:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ZhG-00086W-04 for ipv6-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 08:15:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17037 for ; Thu, 9 Oct 2003 08:15:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ZhE-0005b7-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 08:15:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7ZhE-0005b4-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 08:15:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ZgA-0007nX-7g; Thu, 09 Oct 2003 08:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Zfb-0007ms-Fo for ipv6@optimus.ietf.org; Thu, 09 Oct 2003 08:13:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16993 for ; Thu, 9 Oct 2003 08:13:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Zfa-0005a9-00 for ipv6@ietf.org; Thu, 09 Oct 2003 08:13:26 -0400 Received: from out2.smtp.messagingengine.com ([66.111.4.26]) by ietf-mx with esmtp (Exim 4.12) id 1A7ZfZ-0005a6-00 for ipv6@ietf.org; Thu, 09 Oct 2003 08:13:25 -0400 Received: from smtp.us2.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 197A72AF345 for ; Thu, 9 Oct 2003 08:13:23 -0400 (EDT) Received: from 10.202.2.133 ([10.202.2.133] helo=smtp.us2.messagingengine.com) by messagingengine.com with SMTP; Thu, 09 Oct 2003 08:13:23 -0400 Received: by smtp.us2.messagingengine.com (Postfix, from userid 99) id BCF1275D00; Thu, 9 Oct 2003 08:13:22 -0400 (EDT) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: ipv6@ietf.org Date: Thu, 09 Oct 2003 17:43:22 +0530 X-Epoch: 1065701603 X-Sasl-enc: z0lrVqpGFpq2uyPHBVbQvA Subject: Fwd: RE: Review of draft-ietf-ipv6-node-requirements-05.txt Message-Id: <20031009121322.BCF1275D00@smtp.us2.messagingengine.com> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 9 Oct 2003 09:44:55 +0300, john.loughney@nokia.com said: > Hi Chirayu, > > Thanks for the comments. The document has already passed WG last call > and I am finalizing some text based upon AD review. I am uncomfortable > about making major changes to the document at this point, unless there > is strong reason to do so & strong consensus in the WG. Hi John, Thanks for your reply. I wasn't aware of the last call. That said, I agree that this is not the time for major changes. Please see below for my replies. CP > > General comments: > > ================= > > > > I am slightly confused about the philosophy behind organization of the > > content. I would expect a requirements draft of this sort to > > contain points of the following nature. > > > > a) All sections of the RFC's should mention statements of the form > > "XXX [RFC-YYYY] MUST be implemented for nodes that blah blah blah". (Note the > > usage of the word implemented) > > Do you have a reason for thinking this? Other requirement drafts do not > adhere to this type of layout. IMHO, it (formatting all sections in as per the points that I had listed) makes the document more organized. It is a matter of personal taste, and is not important at this juncture. I am not complaining about the current format, but if there was going to be a next version I would have liked to see the text moved around in some of the sections. > > "Need clarification" comments > > ============================= > > > > 1. Section 4.1 > > > > What is the intent of the following paragraph? Do you mean that all nodes > > should implement the host functionality? If so, does this mean that all > > routers should support the capability of being a final destination (host)? > > > > The capability of being a final destination MUST be supported, > > whereas the capability of being an intermediate destination MAY be > > supported (i.e. - host functionality vs. router functionality). > > All nodes need to be able to terminate packets. All nodes may be able > to route packets. The capability of being a final destination includes support for sending NS, RS messages etc (basically being a host). If all nodes MUST support the capability of being a final destination, then they (all nodes) must be able to behave as hosts. Thus the requirement is that all routers should be able to behave as hosts. Is my interpretation correct? > > "Redirect functionionality SHOULD be supported. If the node is a router, > > Redirect functionionality MUST be supported." Is there no need to have a > > configuration option to disable this functionality as specified for the other > > functionalities? > > During the discussions in the WG, no one suggested that such > functionality is > requiered. Ok. Seems a bit odd though. > > 5. Section 9. > > > > What do you imply by routing-specific functionality? The statement needs some > > support to make it unambiguous. > > > > Currently, this section does not discuss routin- > > specific requirements. > > Do you have text, I am not sure what you are expecting. I wanted to know the meaning of "routing specific" requirements. Does it mean - the types of routing protocols that the routers must support? > > 11. Section 4.5.3 > > > > A reference should be provided for the statement below. Otherwise, > > implementers will not know how to interpret this sentence and identify/fix > > related problems. > > > > It is noted that a number of applications do not work > > with addresses generated with this method, while other applications > > work quite well with them. > > The wg could come to no consensus on what to put here. It is partially > implementation specific; partly deployment specific. Hmm.. Is there an example of atleast one application that does not work with RFC 3041 addresses? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 9 13:16:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29990 for ; Thu, 9 Oct 2003 13:16:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7eOK-0001Bd-OI for ipv6-archive@odin.ietf.org; Thu, 09 Oct 2003 13:15:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99HFuZs004555 for ipv6-archive@odin.ietf.org; Thu, 9 Oct 2003 13:15:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7eOK-0001BO-Gl for ipv6-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 13:15:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29943 for ; Thu, 9 Oct 2003 13:15:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7eOI-0001Zv-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 13:15:54 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7eOH-0001Zs-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 13:15:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7eNS-00015U-Gu; Thu, 09 Oct 2003 13:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7eMm-00014X-4c for ipv6@optimus.ietf.org; Thu, 09 Oct 2003 13:14:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29904 for ; Thu, 9 Oct 2003 13:14:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7eMk-0001Z8-00 for ipv6@ietf.org; Thu, 09 Oct 2003 13:14:18 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1A7eMj-0001Z5-00 for ipv6@ietf.org; Thu, 09 Oct 2003 13:14:17 -0400 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id h99H6bm01921; Thu, 9 Oct 2003 10:06:38 -0700 (PDT) From: Bill Manning Message-Id: <200310091706.h99H6bm01921@boreas.isi.edu> Subject: Re: What is the current status of geographic location in the IPv6 address? In-Reply-To: from Michel Py at "Oct 8, 3 04:32:30 pm" To: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 9 Oct 2003 10:06:37 -0700 (PDT) Cc: brian@innovationslab.net, eric@mehr.ws, ipv6@ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit % > Brian Haberman wrote: % > I do not recall geographic-based addresses ever being a % > part of the IPv6 standards. % % I don't either. I remember them being considered. Steve Deering had this wonderful idea for metro-addressing. % > Tony Hain has an individual ID that discusses one % > possible approach (draft-hain-ipv6-pi-addr-05.txt). --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 9 13:40:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00907 for ; Thu, 9 Oct 2003 13:40:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7elx-0002u4-Jy for ipv6-archive@odin.ietf.org; Thu, 09 Oct 2003 13:40:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99HeLiS011154 for ipv6-archive@odin.ietf.org; Thu, 9 Oct 2003 13:40:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7elx-0002tp-BM for ipv6-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 13:40:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00865 for ; Thu, 9 Oct 2003 13:40:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7elv-0001qm-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 13:40:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7elu-0001qj-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 13:40:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7elg-0002n7-Qi; Thu, 09 Oct 2003 13:40:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7elH-0002m0-Sg for ipv6@optimus.ietf.org; Thu, 09 Oct 2003 13:39:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00834 for ; Thu, 9 Oct 2003 13:39:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7elF-0001q8-00 for ipv6@ietf.org; Thu, 09 Oct 2003 13:39:37 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1A7elE-0001pg-00 for ipv6@ietf.org; Thu, 09 Oct 2003 13:39:37 -0400 Content-class: urn:content-classes:message Subject: RE: What is the current status of geographic location in the IPv6 address? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Oct 2003 10:39:03 -0700 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: What is the current status of geographic location in the IPv6 address? Thread-Index: AcOOic8A2ELjf5A6TX2CKibEzwAQHgAAjSGQ From: "Michel Py" To: "Bill Manning" Cc: , , Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Bill Manning wrote: > I remember them being considered. Steve Deering had > this wonderful idea for metro-addressing. Indeed, in 1995 when he was at parc. Here's a link: http://arneill-py.sacramento.ca.us/ipv6mh/metro-addr-slides-jul95.pdf However this was never part of the spec AFAIR. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 9 14:11:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02055 for ; Thu, 9 Oct 2003 14:11:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7fFq-0004bv-Ua for ipv6-archive@odin.ietf.org; Thu, 09 Oct 2003 14:11:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99IBElv017724 for ipv6-archive@odin.ietf.org; Thu, 9 Oct 2003 14:11:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7fFq-0004bn-Og for ipv6-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 14:11:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02022 for ; Thu, 9 Oct 2003 14:11:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7fFo-0002AB-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 14:11:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7fFn-0002A8-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 14:11:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7fFd-0004Y1-Px; Thu, 09 Oct 2003 14:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7fFJ-0004X8-Sw for ipv6@optimus.ietf.org; Thu, 09 Oct 2003 14:10:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02007 for ; Thu, 9 Oct 2003 14:10:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7fFH-00029s-00 for ipv6@ietf.org; Thu, 09 Oct 2003 14:10:39 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A7fFG-00029a-00 for ipv6@ietf.org; Thu, 09 Oct 2003 14:10:38 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h99I2QM01397; Thu, 9 Oct 2003 11:02:26 -0700 X-mProtect: <200310091802> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLD9eom; Thu, 09 Oct 2003 11:02:24 PDT Message-Id: <4.3.2.7.2.20031009104417.03196f00@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Oct 2003 10:58:46 -0700 To: "Michel Py" From: Bob Hinden Subject: RE: What is the current status of geographic location in the IPv6 address? Cc: "Bill Manning" , , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , At 10:39 AM 10/9/2003, Michel Py wrote: > > Bill Manning wrote: > > I remember them being considered. Steve Deering had > > this wonderful idea for metro-addressing. > >Indeed, in 1995 when he was at parc. Here's a link: >http://arneill-py.sacramento.ca.us/ipv6mh/metro-addr-slides-jul95.pdf >However this was never part of the spec AFAIR. That is correct, it was never part of the IPv6 standards. I too thought it was a nice approach. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 9 15:44:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06978 for ; Thu, 9 Oct 2003 15:44:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ghW-00036w-8k for ipv6-archive@odin.ietf.org; Thu, 09 Oct 2003 15:43:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99Jhsmm011954 for ipv6-archive@odin.ietf.org; Thu, 9 Oct 2003 15:43:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ghW-00036j-1S for ipv6-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 15:43:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06941 for ; Thu, 9 Oct 2003 15:43:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ghU-0003O3-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 15:43:52 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7ghT-0003O0-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 15:43:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ggh-0002wo-4Q; Thu, 09 Oct 2003 15:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7gfq-0002vS-O2 for ipv6@optimus.ietf.org; Thu, 09 Oct 2003 15:42:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06870 for ; Thu, 9 Oct 2003 15:42:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7gfp-0003Lm-00 for ipv6@ietf.org; Thu, 09 Oct 2003 15:42:09 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1A7gfo-0003LQ-00 for ipv6@ietf.org; Thu, 09 Oct 2003 15:42:08 -0400 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h99Jg3ed092983; Thu, 9 Oct 2003 21:42:03 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 9 Oct 2003 21:41:58 +0200 Subject: Re: What is the current status of geographic location in the IPv6 address? Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: Bob Hinden From: Iljitsch van Beijnum In-Reply-To: <4.3.2.7.2.20031009104417.03196f00@mailhost.iprg.nokia.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On donderdag, okt 9, 2003, at 19:58 Europe/Amsterdam, Bob Hinden wrote: >> http://arneill-py.sacramento.ca.us/ipv6mh/metro-addr-slides-jul95.pdf >> However this was never part of the spec AFAIR. > That is correct, it was never part of the IPv6 standards. I too > thought it was a nice approach. In that case you may like this one as well: http://www.ietf.org/internet-drafts/draft-van-beijnum-multi6-isp-int- aggr-01.txt Some of the text here is closely related to the information posted by Michel Py. Iljitsch van Beijnum -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 9 20:01:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17932 for ; Thu, 9 Oct 2003 20:01:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7kiq-0001qc-MK for ipv6-archive@odin.ietf.org; Thu, 09 Oct 2003 20:01:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9A01Wtj007102 for ipv6-archive@odin.ietf.org; Thu, 9 Oct 2003 20:01:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7kiq-0001qS-Fq for ipv6-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 20:01:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17897 for ; Thu, 9 Oct 2003 20:01:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7kio-0006X9-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 20:01:30 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7kio-0006X5-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 20:01:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7khR-0001eU-As; Thu, 09 Oct 2003 20:00:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7kh9-0001dA-Sc for ipv6@optimus.ietf.org; Thu, 09 Oct 2003 19:59:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17832 for ; Thu, 9 Oct 2003 19:59:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7kh7-0006Vg-00 for ipv6@ietf.org; Thu, 09 Oct 2003 19:59:45 -0400 Received: from evrtwa1-ar8-4-65-016-099.evrtwa1.dsl-verizon.net ([4.65.16.99] helo=tndh.net) by ietf-mx with esmtp (Exim 4.12) id 1A7kh5-0006VW-00 for ipv6@ietf.org; Thu, 09 Oct 2003 19:59:44 -0400 Received: from eaglet (127.0.0.1:4693) by tndh.net with [XMail 1.16 (Win32/Ix86) ESMTP Server] id for from ; Thu, 09 Oct 2003 16:59:48 -0700 From: "Tony Hain" To: "IAB" Cc: "The IESG" , , "IETF" Subject: Appeal to the IAB on the site-local issue Date: Thu, 9 Oct 2003 16:59:38 -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.6604 (9.0.2911.0) In-reply-to: <200309301844.OAA06854@ietf.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I am saddened that it has come to this, but the IESG action has simply prolonged the process. The only clarity in their '...somewhere to the left...' justification is their willingness to let personal technical biases blind them to the process failure. As such, please consider this note to be an appeal to the IAB against the IESG decision to reject my appeal. Contrary to their claim, the full spectrum of choices was not presented at the SF meeting. Then, if it weren't for the seriousness of the issue, their inability to do a quick check of the Atlanta minutes (which shows that 125 attendees were against complete removal, not the limited model) would be humorous. In response to the overwhelming rejection of her preferred path, in Atlanta the chair declared 'The wg has agreed we don't want to remove them completely ...' so there was no documentation developed discussing the impacts of complete removal. Therefore there could be no substantive presentation of that position. As noted in my original 4/10/2003 appeal to the chairs, the mail list claims that the RFC 3513 Site-Local addresses 'have issues that outweigh the benefits', or 'does not meet the requirements' are invalid because there was no document listing the requirements, therefore no way to conduct an evaluation which would justify those positions. This lack of documentation became acute when the participants from the applications area were invited to join in the discussion. While I acknowledge that cross area participation helps refine the specifications (and had personally been lobbying the Apps Area to participate), that refinement only happens through extended discussion and informed debate. An hour and twenty minutes of inciting the mob does not constitute informed discussion. In fact 10 minutes before the question, Dave Thaler pointed out there was no draft about elimination, but that detail was ignored by the chair. Shortly after that, Brian Carpenter pointed out that he couldn't vote for keeping SL unless he knew the details of that outcome, to which the chair eventually countered we don't have any details about what it means to remove them either and 'we may have to wave our hands around a little bit'. The chair chose to conduct the vote with no clear outcome for either position, leaving the result that the chair could later tell the working group what it had decided. The further comment by the IESG that the action has resulted in working group activity to address the issues is equally flawed. There were attempts to disambiguate the FEC0 space prior to the SF fiasco, but those were consistently savaged by those who want nothing more than to declare the routing space to be globally flat by IETF fiat. Those same people are working to prevent a different form of local prefix from being defined, and now are feeling emboldened as it appears that this current work is an addition to the architecture rather than a refinement. Which returns us to the ambiguity of the original question, was this a vote about removing ambiguity from the site-local prefix, or removing limited routing scope from the architecture? People expressed opinions about each of those as the basis of their yes vote, but the scope of routing is an operational decision of network managers, therefore not something the IETF gets to decide. Since the votes were mixed as a common Yes, the vote must be invalidated. At every step, this exercise has exposed failures in how the IETF conducts its business. It is now up to the IAB to recommend that the IESG go back, *seriously* set aside their technical biases, and reconsider the process breakdowns. Anything less and we set the precedent that it really doesn't matter how badly a chair abuses the process as long as the IESG agrees with the outcome. Tony FYI: video of the SF session: ftp://limestone.uoregon.edu/pub/videolab/video/ietf56/ietf56 > The IESG has reviewed the appeal by Tony Hain of the IPv6 Working Group > chairs' declaration of consensus on the issue of site local addresses in > the IPv6 address architecture. > > Tony's appeal requests that the declaration of consensus be > overturned due > to the ambiguity of the question asked. > > As is to be expected of a technical discussion where there are many > opinions, the discussion of the site-local issue at the San > Francisco IETF > meeting went all over the map, with many unanswered questions. > However, the question asked by the chairs, with clarification from > the AD, was clear. "Does the group want to go away from site-local > addressing, deprecate it, work out how to get it out, [or] does > the group want to keep it and figure out what the right usage model > is for it?" The clarifying statement was "Deprecate [...] means > somewhere to the left of the 'limited use' model?" The spectrum > of choices, including the 'limited use' model, had been presented > during that same meeting. Although the group had decided to > rule out the 'limited use' model (and presumably anything to the > left of it as well) in Atlanta, nothing precludes new information > from prompting a review of old decisions. > > The question posed on the list was more concise, simply "Should we > deprecate IPv6 site-local unicast addressing?" This question is > not ambiguous. > > The deprecation of site-local addresses in their current form has > served a useful role in forcing the working group to recognize the > problems that the original definition had and work to address them. > The IESG finds nothing unusual about how the question was asked or > how the working group has proceeded. > > There is strong consensus in the IESG that deprecation is the > correct technical decision, but we have done our best to separate > our technical preferences from the process issue in considering > this appeal. > > In summary, the IESG upholds the chairs' and INT ADs' decisions. > > The IESG > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 9 21:46:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20304 for ; Thu, 9 Oct 2003 21:46:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7mLq-0007UL-Os for ipv6-archive@odin.ietf.org; Thu, 09 Oct 2003 21:45:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9A1jsAX028779 for ipv6-archive@odin.ietf.org; Thu, 9 Oct 2003 21:45:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7mLq-0007U6-IQ for ipv6-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 21:45:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20269 for ; Thu, 9 Oct 2003 21:45:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7mLn-0007T8-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 21:45:51 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7mLn-0007T5-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 21:45:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7mL0-0007J8-Rf; Thu, 09 Oct 2003 21:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7mK3-0007If-OQ for ipv6@optimus.ietf.org; Thu, 09 Oct 2003 21:44:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20246 for ; Thu, 9 Oct 2003 21:43:54 -0400 (EDT) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7mK0-0007SY-00 for ipv6@ietf.org; Thu, 09 Oct 2003 21:44:00 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A7mJz-0007SV-00 for ipv6@ietf.org; Thu, 09 Oct 2003 21:43:59 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h9A1hvt09567 for ; Fri, 10 Oct 2003 04:43:57 +0300 (EET DST) Received: from daebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 10 Oct 2003 04:43:57 +0300 Received: from daebe009.NOE.Nokia.com ([172.18.242.190]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 9 Oct 2003 20:43:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: test Date: Thu, 9 Oct 2003 20:43:55 -0500 Message-ID: <8D260779A766FB4A9C1739A476F84FA476C64D@daebe009.americas.nokia.com> Thread-Topic: test Thread-Index: AcOOz/cnDGowdaWiQqmTB7rW7cqt1w== To: X-OriginalArrivalTime: 10 Oct 2003 01:43:56.0547 (UTC) FILETIME=[F7EE4D30:01C38ECF] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable please ignore.. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 9 21:59:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20694 for ; Thu, 9 Oct 2003 21:59:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7mYh-0008QN-08 for ipv6-archive@odin.ietf.org; Thu, 09 Oct 2003 21:59:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9A1xABZ032383 for ipv6-archive@odin.ietf.org; Thu, 9 Oct 2003 21:59:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7mYg-0008QE-RK for ipv6-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 21:59:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20638 for ; Thu, 9 Oct 2003 21:59:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7mYd-0007c8-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 21:59:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7mYd-0007c5-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 21:59:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7mYY-0008MC-DS; Thu, 09 Oct 2003 21:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7mY7-0008Jm-4t for ipv6@optimus.ietf.org; Thu, 09 Oct 2003 21:58:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20627; Thu, 9 Oct 2003 21:58:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7mY3-0007bi-00; Thu, 09 Oct 2003 21:58:31 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1A7mY3-0007al-00; Thu, 09 Oct 2003 21:58:31 -0400 Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4393E61BA7; Fri, 10 Oct 2003 03:57:57 +0200 (CEST) Date: Fri, 10 Oct 2003 03:54:08 +0200 From: Harald Tveit Alvestrand To: Tony Hain , IAB Cc: The IESG , ipv6@ietf.org, IETF Subject: Re: Appeal to the IAB on the site-local issue Message-ID: <53402438.1065758048@localhost> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tony, speaking only for myself: I am saddened to see the length to which you are willing to go in attempting to use process mechanisms to overturn a technical WG decision to which you do not agree. After reviewing the video, I personally concluded that *no matter what the merits of the case*, the WG had clearly made a decision. My judgment of the the form of the discussion was that it was an informed one; my judgment of the arguments raised was that it was a correct one. But there's absolutely no doubt in my mind that the WG made a decision, and that the chairs were procedurally correct in recording that decision as the outcome of the meeting. That is, after all, what you claimed to be appealing. Harald --On 9. oktober 2003 16:59 -0700 Tony Hain wrote: > I am saddened that it has come to this, but the IESG action has simply > prolonged the process. The only clarity in their '...somewhere to the > left...' justification is their willingness to let personal technical > biases blind them to the process failure. As such, please consider this > note to be an appeal to the IAB against the IESG decision to reject my > appeal. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 9 22:15:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21160 for ; Thu, 9 Oct 2003 22:15:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7moQ-0001NK-P7 for ipv6-archive@odin.ietf.org; Thu, 09 Oct 2003 22:15:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9A2FQTN005280 for ipv6-archive@odin.ietf.org; Thu, 9 Oct 2003 22:15:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7moQ-0001N5-Ii for ipv6-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 22:15:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21119 for ; Thu, 9 Oct 2003 22:15:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7moN-0007m6-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 22:15:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7moN-0007m1-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 22:15:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7mo3-0001E6-8v; Thu, 09 Oct 2003 22:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7mne-0001DJ-3z for ipv6@optimus.ietf.org; Thu, 09 Oct 2003 22:14:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21075; Thu, 9 Oct 2003 22:14:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7mna-0007kv-00; Thu, 09 Oct 2003 22:14:34 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1A7mna-0007kW-00; Thu, 09 Oct 2003 22:14:34 -0400 Subject: RE: Appeal to the IAB on the site-local issue Date: Thu, 9 Oct 2003 19:14:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Appeal to the IAB on the site-local issue thread-index: AcOO0oAdTcnqwDyrQWqgZCxFUMDlWQAAMnfg From: "Michel Py" To: "Harald Tveit Alvestrand" , "Tony Hain" , "IAB" Cc: "The IESG" , , "IETF" Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Harald, > Harald Tveit Alvestrand > But there's absolutely no doubt in my mind that the WG made a > decision, and that the chairs were procedurally correct in > recording that decision as the outcome of the meeting. There many people, including some that actually _wrote_ the procedures, that disagree with you. As of myself, I am not completely happy with the way Tony has worded his appeal (although I do agree with it), which is why I will file one on different grounds as soon as this one as been ruled. Since it appears that there is a waiting list to file an appeal on this matter, I am sure that we will be entertained for the next two or three years to come. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 01:14:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26039 for ; Fri, 10 Oct 2003 01:14:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7pb5-0002mU-6v for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 01:13:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9A5DpKc010684 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 01:13:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7pb5-0002mF-1S for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 01:13:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25937 for ; Fri, 10 Oct 2003 01:13:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7pb1-0001jb-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 01:13:48 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7pb1-0001jY-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 01:13:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7paI-0002di-GE; Fri, 10 Oct 2003 01:13:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7pZZ-0002cj-Bm for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 01:12:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25856; Fri, 10 Oct 2003 01:12:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7pZV-0001gj-00; Fri, 10 Oct 2003 01:12:13 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1A7pZV-0001gH-00; Fri, 10 Oct 2003 01:12:13 -0400 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Oct 2003 22:11:42 -0700 Received: from 157.54.8.109 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 09 Oct 2003 22:11:42 -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(6.0.3790.0); Thu, 9 Oct 2003 22:11:42 -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(6.0.3790.0); Thu, 9 Oct 2003 22:11:40 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 9 Oct 2003 22:11:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Appeal to the IAB on the site-local issue Date: Thu, 9 Oct 2003 22:11:40 -0700 Message-ID: Thread-Topic: Appeal to the IAB on the site-local issue thread-index: AcOO0oAdTcnqwDyrQWqgZCxFUMDlWQAAMnfgAAXCpnA= From: "Christian Huitema" To: "Michel Py" , "Harald Tveit Alvestrand" , "Tony Hain" , "IAB" Cc: "The IESG" , , "IETF" X-OriginalArrivalTime: 10 Oct 2003 05:11:40.0522 (UTC) FILETIME=[FD09F4A0:01C38EEC] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > Harald Tveit Alvestrand > > But there's absolutely no doubt in my mind that the WG made a > > decision, and that the chairs were procedurally correct in > > recording that decision as the outcome of the meeting. >=20 > There many people, including some that actually _wrote_ the procedures, > that disagree with you.=20 Please explain or retract. I was the note-taker during that particular session, and I don't recall ever stating that the chair's decision did not reflect the result of the meeting.=20 -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 01:24:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26465 for ; Fri, 10 Oct 2003 01:24:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7plC-0003oj-8X for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 01:24:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9A5OI5k014667 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 01:24:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7plB-0003md-QZ for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 01:24:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26404 for ; Fri, 10 Oct 2003 01:24:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7pl8-0001tV-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 01:24:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7pl8-0001tS-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 01:24:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7pkv-0003eg-Hf; Fri, 10 Oct 2003 01:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7pjx-0003cZ-5A for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 01:23:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26355; Fri, 10 Oct 2003 01:22:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7pjt-0001sG-00; Fri, 10 Oct 2003 01:22:57 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1A7pjq-0001s1-00; Fri, 10 Oct 2003 01:22:54 -0400 Subject: RE: Appeal to the IAB on the site-local issue Date: Thu, 9 Oct 2003 22:22:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Appeal to the IAB on the site-local issue thread-index: AcOO0oAdTcnqwDyrQWqgZCxFUMDlWQAAMnfgAAXCpnAAALDl0A== From: "Michel Py" To: "Christian Huitema" , "Harald Tveit Alvestrand" , "IAB" Cc: "The IESG" , , "IETF" Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Christian, >> Michel Py wrote:=20 >> There many people, including some that actually _wrote_ >> the procedures, that disagree with you.=20 > Christian Huitema wrote: > Please explain or retract. I was the note-taker during that > particular session, and I don't recall ever stating that the > chair's decision did not reflect the result of the meeting. Neither do I. I was not referring to you. By "_wrote_ the procedures", I did not mean "wrote the proceedings". As an example, I was referring to Scott Bradner's posts the; relation with the procedure being that Scott is the editor of RFC2026; I do acknowledge that Scott might not have been speaking as the editor of RFC2026; nevertheless I consider (as many other people do) Scott as an expert in terms of procedure. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 05:55:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15818 for ; Fri, 10 Oct 2003 05:55:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7typ-0003Qe-VC for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 05:54:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9A9sdoK013181 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 05:54:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7typ-0003QK-4O for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 05:54:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15770 for ; Fri, 10 Oct 2003 05:54:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7tyl-0004bQ-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 05:54:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7tyk-0004bM-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 05:54:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7tyD-0003HN-Ru; Fri, 10 Oct 2003 05:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7txP-0003Gg-36 for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 05:53:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15753 for ; Fri, 10 Oct 2003 05:53:01 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7txK-0004b0-00 for ipv6@ietf.org; Fri, 10 Oct 2003 05:53:07 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A7txK-0004ax-00 for ipv6@ietf.org; Fri, 10 Oct 2003 05:53:06 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h9A9r6611124 for ; Fri, 10 Oct 2003 12:53:06 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 10 Oct 2003 12:53:05 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 10 Oct 2003 12:53:06 +0300 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 10 Oct 2003 12:53:05 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 10 Oct 2003 12:53:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Updated text for Node Req: Issue23: DNS issues Date: Fri, 10 Oct 2003 12:53:04 +0300 Message-ID: Thread-Topic: FWD: RE: Node Req: Issue23: DNS issues Thread-Index: AcOICWbbUY0cpNi2SRSIYI3UyDhLxQGDeDiQ To: , Cc: X-OriginalArrivalTime: 10 Oct 2003 09:53:05.0555 (UTC) FILETIME=[4D4D8630:01C38F14] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all,=20 After discussing with some DNS folk, the suggested text for section 5.2 = is as=20 follows: 5.2 DNS All nodes, that need to resolve names, SHOULD implement stub-resolver [RFC1034 section 5.3.1] functionality with support for: - AAAA type Resource Records [RFC1886bis]; - reverse addressing in ip6.arpa [RFC3152]; - EDNS0 [RFC2671] to allow for DNS packet sizes larger than 512 = octets. =20 Those nodes are RECOMMENDED to support DNS security extentions=20 [DNSSEC-INTRO], [DNSSEC-REC] and [DNSSEC-PROT]. Those nodes are NOT RECOMMENDED to support the experimental A6 and=20 DNAME Resource Records [RFC3363]. "Format for Literal IPv6 Addresses in URL's" [RFC-2732] MUST be = supported if=20 applications on the node use URL's. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D add references for: [RFC2671] [RFC3152] [RFC1886bis] [DNSSEC-INTRO] draft-ietf-dnsext-dnssec-intro. [DNSSEC-REC] draft-ietf-dnsext-dnssec-records. [DNSSEC-PROT] draft-ietf-dnsext-dnssec-protocol. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 11:02:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02243 for ; Fri, 10 Oct 2003 11:02:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ymK-0000h5-E5 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 11:02:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AF24gu002662 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 11:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ymJ-0000gr-AA for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 11:02:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02178 for ; Fri, 10 Oct 2003 11:01:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ymG-0004en-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 11:02:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7ymG-0004ek-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 11:02:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ylK-0000SC-R3; Fri, 10 Oct 2003 11:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ykQ-0000Q2-8a for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 11:00:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02098; Fri, 10 Oct 2003 10:59:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ykM-0004e3-00; Fri, 10 Oct 2003 11:00:02 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1A7ykM-0004dz-00; Fri, 10 Oct 2003 11:00:02 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 0B1D913FD8; Fri, 10 Oct 2003 10:59:58 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05558-03; Fri, 10 Oct 2003 10:59:56 -0400 (EDT) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 59F6914108; Fri, 10 Oct 2003 10:59:55 -0400 (EDT) Date: Fri, 10 Oct 2003 10:56:33 -0400 From: Keith Moore To: Scott Bradner Cc: moore@cs.utk.edu, iab@iab.org, iesg@ietf.org, ietf@ietf.org, ipv6@ietf.org Subject: Re: Appeal to the IAB on the site-local issue Message-Id: <20031010105633.33615cf3.moore@cs.utk.edu> In-Reply-To: <200310101416.h9AEGgOV001915@newdev.harvard.edu> References: <200310101416.h9AEGgOV001915@newdev.harvard.edu> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit - I don't see anything in our documented processes that requires a greater degree of consensus to change an existing specification. Rather I see an expectation built into our process that undesirable or unworkable features will be removed as a standard progresses from proposed to draft to full standard. - I can understand a belief that 3/4 majority is on the rough edge of rough consensus. But even assuming that rough consensus requires a greater plurality, there was certainly a sufficient demonstration of opinion that any revision to existing specifications that did include site local was unlikely to gain consensus and that trying to fix site-local was not a useful expenditure of the WG's energy. And there was also growing evidence that we had not found a workable way to use site local, which would by itself be sufficient to bar site-local from advancing in grade along with the rest of IPv6. So even accepting that there was something less than consensus in the WG's decision, in some sense it's a moot point. Site-local was a dead end anyway, both politically and technically. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 11:10:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02687 for ; Fri, 10 Oct 2003 11:10:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yuE-0001RG-Sw for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 11:10:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AFAEDi005524 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 11:10:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yuE-0001R1-OE for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 11:10:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02637 for ; Fri, 10 Oct 2003 11:10:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yu9-0004o1-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 11:10:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7yu8-0004ny-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 11:10:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yu2-0001N6-Er; Fri, 10 Oct 2003 11:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ytc-0001La-Mj for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 11:09:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02607; Fri, 10 Oct 2003 11:09:26 -0400 (EDT) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ytZ-0004nG-00; Fri, 10 Oct 2003 11:09:33 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A7ytY-0004n7-00; Fri, 10 Oct 2003 11:09:33 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9AF9SR15340; Fri, 10 Oct 2003 18:09:28 +0300 (EET DST) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 10 Oct 2003 18:09:27 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 10 Oct 2003 10:09:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Appeal to the IAB on the site-local issue Date: Fri, 10 Oct 2003 11:09:22 -0400 Message-ID: Thread-Topic: Appeal to the IAB on the site-local issue Thread-Index: AcOPOTTKussVoZEJS8Ken2C8SzLXCQAAmaog To: , Cc: , , X-OriginalArrivalTime: 10 Oct 2003 15:09:25.0486 (UTC) FILETIME=[7E3928E0:01C38F40] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Scott, Speaking only for myself, I would like to address a couple of the=20 points that you have made. =20 > It is my opinion that there is a difference between a working group > deciding to adopt a technology and a working group deciding=20 > to delete a technology from an existing IETF specification. It is my=20 > opinion that the second case should require a stronger demonstration=20 > of consensus to change since the decision effects existing = implementations,=20 > documentation, text books etc. First, I disagree with your basic premise. We don't make any=20 distinction between these cases, but if we did, all other things being equal, I think it should be harder to add a new feature to a=20 specification than to take one out. Removing a feature from a=20 specification doesn't even prevent people from using it, whereas adding a feature requires people to implement new code to be compliant with the specification. But, regardless of our differing opinions on this theoretical point, I=20 am not sure how it applies to this situation. Although a prefix for=20 site-local addressing was set aside in the IPv6 Address Architecture=20 (a PS RFC), the entire specification for the concept of site-local=20 addressing, including how you would actually use these addresses, was=20 only ever documented in the IPv6 Scoped Addressing Architecture I-D. At = the time that this decision was made by the WG, the latest version of=20 that I-D had expired. Various versions of the I-D had been considered by the WG for years, but we had never reached rough consensus to send=20 this I-D to the IESG for publication. > The claim was made on the list that there was not consensus=20 > to keep site local addresses, I think that is the wrong question=20 > to ask - the proposal was to change a specification after its=20 > publication there should have been a rough consensus to remove the=20 > feature. I'm not sure where this is coming from. You quoted the consensus=20 finding later in your message: > > The chairs have read all of the messages on the list, and=20 > > based on your considerable input, we have determined that=20 > > the IPv6 WG does have rough consensus to deprecate the usage=20 > > of IPv6 site-local unicast addressing AND to investigate=20 > > alternative mechanisms for local addressing and local access > > control. In other words, we found that there was consensus to deprecate AND replace site-locals, not that there was a lack of consensus to keep them. In response to your appended letter: > humm - it is not all that often that we have said that 2/3 is rough > consensus in the IETF - in my exterience if 1/3 is not in support > then I would not claim consensus (even 6 grit) - 3/4 would be very > rough indeed, 5/6 would be the mininum I would say was "rough=20 > consensus" The actual ratio of YES to NO responses to this poll was closer to 3/4. Also, the poll was not the only tool that the WG chairs (I was one of them at the time) used to determine the consensus of the=20 WG. There was considerable discussion regarding this issue -- in the WG meeting and on the list. This included a fairly large number of people who gave conditional replies on the list, or who clarified their meeting postion on the list along the lines of: (1) I do not think we should deprecate site-local unless/until we replace them, or (2) Although I think that we should deprecate site-locals, I also think that we need a replacement. The chairs consensus call was based on lengthy and careful consideration of all of the information contributed by the WG, not just on the results of the opinion poll. It is still my personal opinion that we correctly judged the=20 consensus of the WG regarding this matter. Margaret=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 12:13:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05191 for ; Fri, 10 Oct 2003 12:13:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zsq-0005pX-8M for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 12:12:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AGCqAq022408 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 12:12:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zsp-0005pL-Pb for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 12:12:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05151 for ; Fri, 10 Oct 2003 12:12:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7zso-0005ex-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 12:12:50 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7zsn-0005eu-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 12:12:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zs1-0005aL-Cd; Fri, 10 Oct 2003 12:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zrO-0005Yi-57 for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 12:11:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05075; Fri, 10 Oct 2003 12:11:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7zrM-0005dk-00; Fri, 10 Oct 2003 12:11:20 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.101]) by ietf-mx with esmtp (Exim 4.12) id 1A7zrL-0005cU-00; Fri, 10 Oct 2003 12:11:19 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id h9AG0bHe394900; Fri, 10 Oct 2003 12:00:37 -0400 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9AG0Ybk192338; Fri, 10 Oct 2003 12:00:34 -0400 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id h9AFxcGB005192; Fri, 10 Oct 2003 11:59:44 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id h9AFxcQR005188; Fri, 10 Oct 2003 11:59:38 -0400 Message-Id: <200310101559.h9AFxcQR005188@rotala.raleigh.ibm.com> To: "Michel Py" cc: "Harald Tveit Alvestrand" , "Tony Hain" , "IAB" , "The IESG" , ipv6@ietf.org, "IETF" Subject: Re: Appeal to the IAB on the site-local issue In-Reply-To: Message from michel@arneill-py.sacramento.ca.us of "Thu, 09 Oct 2003 19:14:02 PDT." Date: Fri, 10 Oct 2003 11:59:37 -0400 From: Thomas Narten Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Michel, > There many people, including some that actually _wrote_ the procedures, > that disagree with you. This is FUD. If there are people that agree with Tony's appeal, let them speak for themselves. In all the email on this thread (and the many conversations I have had with folk), I have had a _very_ hard time seeing anyone truly supporting Tony's appeal (with the exception of kre, who posted specifically in support of it). Scott Bradner has already posted separately clarifying his views. And let's be very clear. Disagreeing with the decision to deprecate is not the same thing as agreeing with Tony's appeal. His appeal is very specific and focuses on a process question. One can disagree with the the decision to deprecate and simultaneously disagree with the appeal. Not to beat an obvious point, one can't just appeal a decision because one doesn't like it, one has to have specific reasons (as listed in 2026). > As of myself, I am not completely happy with the > way Tony has worded his appeal (although I do agree with it), which is > why I will file one on different grounds as soon as this one as been > ruled. Since it appears that there is a waiting list to file an appeal > on this matter, I am sure that we will be entertained for the next two > or three years to come. You might want to consult RFC 2026. There is a statute of limitations with regards to appeals: > All appeals must be initiated within two months of the public > knowledge of the action or decision to be challenged. If you are waiting to see the results of the current appeal before filing yet another one, you'd better have grounds other than issues with the original actions some months ago. A statute of limitations is apparently a necessary thing (unfortunately), precisely to prevent issues from dragging out over "the next two or three years to come". Popping up a level, there's a more basic thing that I fail to understand about this appeal. If the decision to deprecate was so wrong and flawed, how does one explain that the community seems to support it? From some of Tony's notes, one would think that process ran amok in this case with a horrible end result that goes against the will of the WG. But I don't see the community agreeing with that view. E.g., see a recent note from the IPv6 chairs on the subject (appended). From it, it is clear that there is strong community support to deprecate SLs. Thus, the idea that the consensus call was fatally flawed, that the community doesn't support the decision and that we consequently somehow need to reset the clock and pretend that the last 6 months didn't happen and that we must start the entire conversation over about what to do with SLs just doesn't make any sense to me. Thomas From: Bob Hinden & Brian Haberman To: ipv6@ietf.org Cc: hinden@iprg.nokia.com, Brian Haberman Date: Tue, 16 Sep 2003 10:55:33 -0700 Subject: Results of Poll The results of the poll (appended below) started by the chairs in early August to get more feed back from the working about how to deprecate site-local are as follows: Preference A 32 45% Preference B 31 44% Preference C 8 11% -------------------------- Total Votes 71 100% The raw votes are available at: http://people.nokia.net/~hinden/ipv6-choices.html If we missed your preference or got it wrong, please let us know. There are a few conclusions that can be seen in this poll. Only 11% of the people responding wanted to defer the deprecation of site-local until an alternative was deployed. 89% wanted to deprecate prior to an alternative being standardized or at the same time an alternative was standardized. There was not a consensus about tieing the deprecation of site-local to defining an alternative or do the deprecation before defining an alternative. The working group is closely split on this. Even combing preferences B & C (i.e., 55%) does not form a consensus. Based on this, the chairs will plan to move the deprecation document and the local addressing specification forward at approximately the same time, but will not do anything to officially tie them together. Bob Hinden / Brian Haberman IPv6 w.g. chairs >Date: Mon, 04 Aug 2003 11:06:55 -0700 >To: ipng@sunroof.eng.sun.com >From: Bob Hinden >Subject: Moving forward on Site-Local and Local Addressing >Cc: hinden@iprg.nokia.com > >[IPv6 working group chair hat on] > >I think the working group has been making good progress on replacing >site-local addresses and wanted to get feed back from the working group on >how we should move forward. This is not intended to directly relate to >the ongoing appeal of the working groups decision to deprecate the usage >site-local addresses, but to get feedback on how to proceed. I think it >is very important that we move forward on this issue and not rehash what >has happened in the past. > >We now have a combined local addressing requirements document >, a specific alternative to >site-local addresses draft >(accepted as a working group item at the Vienna IETF), and will soon have >a draft describing why site-local addresses are being deprecated and doing >the formal deprecation (authors identified and outline discussed at the >Vienna IETF). Note that all of these documents will proceed through the >normal working group and IETF processes of last calls and review. > >I think legitimate questions have been raised about how the working group >should go about deprecating site-local addresses given their maturity in >the current specifications and use in deployed products. Specifically >should they be deprecated independently from having an alternative >solution available, at the same time an alternative is available, or >sometime after an alternative is available. A forth alternative is to not >replace site-local addresses in any form, but I think the working group >has made it clear that this is not a reasonable alternative. > >I would like to hear from the working group on how we should proceed. I >think the choices are: > >A) Deprecate Site-Local addresses independently from having an alternative >solution available. This would mean that the working group should treat >the deprecation, and requirements and solution documents outlined above >independently from each other. If there was no consensus on an >alternative a replacement would not happen. > >B) Deprecate Site-Local addresses at the same time as a alternative >solution is agreed to. This would mean advancing both documents at the >same time and making them include normative references to each other to >insure that they were published at the same time. This would result in >the deprecation only happening if a consensus was reached on an alternative. > >C) Deprecate Site-Local addresses after an alternative is defined, >standardized, and in operational practice. This would mean not advancing >a deprecation document until there was operational evidence that the >alternative was working and shown to be an improvement over Site-Local >addresses. > >Note: In the above choices "Deprecate Site-Local addresses" means >publishing an RFC that does the formal deprecation. > >Please respond to the list with your preference, or if there is an >alternative approach that is an improvement from the ones I outlined. I >hope that many of you will respond. > >Thanks, >Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 12:13:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05243 for ; Fri, 10 Oct 2003 12:13:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ztH-00063y-J6 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 12:13:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AGDHeV023102 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 12:13:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zt1-0005sw-UL for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 12:13:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05162 for ; Fri, 10 Oct 2003 12:12:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7zt0-0005fH-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 12:13:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7zt0-0005fE-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 12:13:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zt0-0005qF-DJ; Fri, 10 Oct 2003 12:13:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7vvT-0005Ag-F0 for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 07:59:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22339; Fri, 10 Oct 2003 07:59:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7vvS-0001ff-00; Fri, 10 Oct 2003 07:59:18 -0400 Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx with esmtp (Exim 4.12) id 1A7vvR-0001eX-00; Fri, 10 Oct 2003 07:59:17 -0400 Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250]) by comcast.net (rwcrmhc11) with SMTP id <2003101011583901300qn25oe> (Authid: sdawkins@comcast.net); Fri, 10 Oct 2003 11:58:39 +0000 Message-ID: <088701c38f25$dd017cd0$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: "Michel Py" , "Harald Tveit Alvestrand" , "Tony Hain" , "IAB" Cc: "The IESG" , , "IETF" References: Subject: Re: Appeal to the IAB on the site-local issue Date: Fri, 10 Oct 2003 06:58:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Speaking as an outsider on this particular topic... Is there any reason why these appeals should be single-threaded? As much fun as it might be to continue to rotate this topic on a spit, we've been discussing whether we actually made this decision or not for six months. Continuing to discuss it for another two or three years is just pathological. If it was the WRONG decision, deciding that we made the decision, and letting the wrongness blossom/fester and become evident to all, would be an improvement. Spencer ----- Original Message ----- From: "Michel Py" > Harald, > > > Harald Tveit Alvestrand > > But there's absolutely no doubt in my mind that the WG made a > > decision, and that the chairs were procedurally correct in > > recording that decision as the outcome of the meeting. > > There many people, including some that actually _wrote_ the procedures, > that disagree with you. As of myself, I am not completely happy with the > way Tony has worded his appeal (although I do agree with it), which is > why I will file one on different grounds as soon as this one as been > ruled. Since it appears that there is a waiting list to file an appeal > on this matter, I am sure that we will be entertained for the next two > or three years to come. > > Michel. > > > > _______________________________________________ > This message was passed through ietf_censored@carmen.ipv6.cselt.it, which is a sublist of ietf@ietf.org. Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator (ietf_admin@ngnet.it). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 12:13:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05273 for ; Fri, 10 Oct 2003 12:13:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ztO-00068q-Ne for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 12:13:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AGDQcv023602 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 12:13:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ztO-00068b-In for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 12:13:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05185 for ; Fri, 10 Oct 2003 12:13:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ztN-0005gD-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 12:13:25 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7ztM-0005g6-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 12:13:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zt5-00060b-Hp; Fri, 10 Oct 2003 12:13:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7y4b-0005ms-8q for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 10:16:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29868; Fri, 10 Oct 2003 10:16:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7y4Y-0003yP-00; Fri, 10 Oct 2003 10:16:50 -0400 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx with esmtp (Exim 4.12) id 1A7y4X-0003yL-00; Fri, 10 Oct 2003 10:16:49 -0400 Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h9AEGg6U001916; Fri, 10 Oct 2003 10:16:42 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h9AEGgOV001915; Fri, 10 Oct 2003 10:16:42 -0400 (EDT) Date: Fri, 10 Oct 2003 10:16:42 -0400 (EDT) From: Scott Bradner Message-Id: <200310101416.h9AEGgOV001915@newdev.harvard.edu> To: iab@iab.org Subject: re: Appeal to the IAB on the site-local issue Cc: iesg@ietf.org, ietf@ietf.org, ipv6@ietf.org Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , IAB, Please consider this input for the IAB discussion on Tony's appeal of the site local decision. This should not be considered a separate appeal. (Which I would think would have to start at the beginning with the working group chairs.) I do not have an opinion on the particulars of Tony's appeal since I was not at the meeting in question and only followed the discussion on the mailing list. Nor is this an opinion based on the technical question under discussion. (Although I think some of the cures proposed to the site-local disease are quite a bit worse than the disease itself.) I would like to reiterate the concern I expressed on the mailing list back in July - I think there may been a violation of the IETF consensus process in this case. It is my opinion that there is a difference between a working group deciding to adopt a technology and a working group deciding to delete a technology from an existing IETF specification. It is my opinion that the second case should require a stronger demonstration of consensus to change since the decision effects existing implementations, documentation, text books etc. But even without any need to show any extra level of consensus I did not see that even a minimal level of rough consensus was demonstrated to remove site local addresses. The claim was made on the list that there was not consensus to keep site local addresses, I think that is the wrong question to ask - the proposal was to change a specification after its publication there should have been a rough consensus to remove the feature. I did not see rough consensus to do so based on my monitoring the list. Scott (this is the letter I sent back in July on the topic) From sob Mon Jul 28 15:11:01 2003 To: Erik.Nordmark@Sun.COM Subject: Re: state-of-art SLs Cc: ipng@sunroof.eng.sun.com In-Reply-To: > The chairs have read all of the messages on the list, and based on your > considerable input, we have determined that the IPv6 WG does have rough > consensus to deprecate the usage of IPv6 site-local unicast addressing AND > to investigate alternative mechanisms for local addressing and local access . control. humm - it is not all that often that we have said that 2/3 is rough consensus in the IETF - in my exterience if 1/3 is not in support then I would not claim consensus (even 6 grit) - 3/4 would be very rough indeed, 5/6 would be the mininum I would say was "rough consensus" just when does "rough consensus" faid out in this model? Scott -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 14:01:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09937 for ; Fri, 10 Oct 2003 14:01:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81Zh-0005mS-Ax for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 14:01:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AI1Dh1022219 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 14:01:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81Zh-0005mI-64 for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 14:01:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09894 for ; Fri, 10 Oct 2003 14:01:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A81Ze-00070K-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 14:01:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A81Ze-00070H-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 14:01:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81YZ-0005Zl-VT; Fri, 10 Oct 2003 14:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81YO-0005Yl-Db for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 13:59:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09819 for ; Fri, 10 Oct 2003 13:59:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A81YL-0006yu-00 for ipv6@ietf.org; Fri, 10 Oct 2003 13:59:49 -0400 Received: from evrtwa1-ar8-4-65-016-099.evrtwa1.dsl-verizon.net ([4.65.16.99] helo=tndh.net) by ietf-mx with esmtp (Exim 4.12) id 1A81YK-0006yn-00 for ipv6@ietf.org; Fri, 10 Oct 2003 13:59:48 -0400 Received: from eaglet (127.0.0.1:3236) by tndh.net with [XMail 1.16 (Win32/Ix86) ESMTP Server] id for from ; Fri, 10 Oct 2003 10:59:54 -0700 From: "Tony Hain" To: Cc: , , Subject: RE: Appeal to the IAB on the site-local issue Date: Fri, 10 Oct 2003 10:59:45 -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.6604 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Additional input for your consideration. Margaret.Wasserman@nokia.com wrote: > ... > In other words, we found that there was consensus to deprecate AND > replace site-locals, ... Witness the situation where the chair is after the fact defining what the working group agreed to. There was nothing about 'replacement' in the question that was asked. Coupling this with her earlier comment: > I think it should be harder to add a new feature to a specification > than to take one out. shows that, now as AD, the bar for a disambiguated local range will be higher if the pronouncement is allowed to stand, than what is necessary to fix the existing specification. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 14:05:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10113 for ; Fri, 10 Oct 2003 14:05:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81de-0006HD-8G for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 14:05:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AI5Iqe024122 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 14:05:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81de-0006Gi-19 for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 14:05:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10071 for ; Fri, 10 Oct 2003 14:05:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A81db-00073Q-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 14:05:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A81db-00073N-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 14:05:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81dP-00066L-Eg; Fri, 10 Oct 2003 14:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81dK-00065b-Oc for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 14:04:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10051 for ; Fri, 10 Oct 2003 14:04:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A81dH-000731-00 for ipv6@ietf.org; Fri, 10 Oct 2003 14:04:55 -0400 Received: from evrtwa1-ar8-4-65-016-099.evrtwa1.dsl-verizon.net ([4.65.16.99] helo=tndh.net) by ietf-mx with esmtp (Exim 4.12) id 1A81dF-00072o-00 for ipv6@ietf.org; Fri, 10 Oct 2003 14:04:54 -0400 Received: from eaglet (127.0.0.1:3440) by tndh.net with [XMail 1.16 (Win32/Ix86) ESMTP Server] id for from ; Fri, 10 Oct 2003 11:05:00 -0700 From: "Tony Hain" To: "Thomas Narten" , "Michel Py" Cc: "Harald Tveit Alvestrand" , "Tony Hain" , "IAB" , "The IESG" , , "IETF" Subject: RE: Appeal to the IAB on the site-local issue Date: Fri, 10 Oct 2003 11:04:50 -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.6604 (9.0.2911.0) In-reply-to: <200310101559.h9AFxcQR005188@rotala.raleigh.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thomas Narten wrote: > ... > Popping up a level, there's a more basic thing that I fail to > understand about this appeal. If the decision to deprecate was so > wrong and flawed, how does one explain that the community seems to > support it? You are listening to a very limited subset of the 'community'. I have had several questions from fortune 500 network managers as to 'what now?' They plan to roll out IPv6 with addresses that are in either the FEC0 range anyway, or are trusting that the proposed replacement FC00 will be finalized soon. > From some of Tony's notes, one would think that process > ran amok in this case with a horrible end result that goes against the > will of the WG. But I don't see the community agreeing with that view. > E.g., see a recent note from the IPv6 chairs on the subject > (appended). From it, it is clear that there is strong community > support to deprecate SLs. Take the biased questions in context, all choices started with 'Deprecate Site-Local ...' You can get any answer you want as long as you get to frame the question and later define what the answer means. Tony > Thus, the idea that the consensus call was > fatally flawed, that the community doesn't support the decision and > that we consequently somehow need to reset the clock and pretend that > the last 6 months didn't happen and that we must start the entire > conversation over about what to do with SLs just doesn't make any > sense to me. > > Thomas > > From: Bob Hinden & Brian Haberman > To: ipv6@ietf.org > Cc: hinden@iprg.nokia.com, Brian Haberman > Date: Tue, 16 Sep 2003 10:55:33 -0700 > Subject: Results of Poll > > The results of the poll (appended below) started by the chairs in early > August to get more feed back from the working about how to deprecate > site-local are as follows: > > Preference A 32 45% > Preference B 31 44% > Preference C 8 11% > -------------------------- > Total Votes 71 100% > > The raw votes are available at: > > http://people.nokia.net/~hinden/ipv6-choices.html > > If we missed your preference or got it wrong, please let us know. > > There are a few conclusions that can be seen in this poll. > > Only 11% of the people responding wanted to defer the deprecation of > site-local until an alternative was deployed. 89% wanted to deprecate > prior to an alternative being standardized or at the same time an > alternative was standardized. > > There was not a consensus about tieing the deprecation of site-local to > defining an alternative or do the deprecation before defining an > alternative. The working group is closely split on this. Even combing > preferences B & C (i.e., 55%) does not form a consensus. > > Based on this, the chairs will plan to move the deprecation document and > the local addressing specification forward at approximately the > same time, > but will not do anything to officially tie them together. > > Bob Hinden / Brian Haberman > IPv6 w.g. chairs > > > > >Date: Mon, 04 Aug 2003 11:06:55 -0700 > >To: ipng@sunroof.eng.sun.com > >From: Bob Hinden > >Subject: Moving forward on Site-Local and Local Addressing > >Cc: hinden@iprg.nokia.com > > > >[IPv6 working group chair hat on] > > > >I think the working group has been making good progress on replacing > >site-local addresses and wanted to get feed back from the > working group on > >how we should move forward. This is not intended to directly relate to > >the ongoing appeal of the working groups decision to deprecate the usage > >site-local addresses, but to get feedback on how to proceed. I think it > >is very important that we move forward on this issue and not rehash what > >has happened in the past. > > > >We now have a combined local addressing requirements document > >, a specific alternative to > >site-local addresses draft > >(accepted as a working group item at the Vienna IETF), and will > soon have > >a draft describing why site-local addresses are being deprecated > and doing > >the formal deprecation (authors identified and outline discussed at the > >Vienna IETF). Note that all of these documents will proceed through the > >normal working group and IETF processes of last calls and review. > > > >I think legitimate questions have been raised about how the > working group > >should go about deprecating site-local addresses given their maturity in > >the current specifications and use in deployed products. Specifically > >should they be deprecated independently from having an alternative > >solution available, at the same time an alternative is available, or > >sometime after an alternative is available. A forth alternative > is to not > >replace site-local addresses in any form, but I think the working group > >has made it clear that this is not a reasonable alternative. > > > >I would like to hear from the working group on how we should proceed. I > >think the choices are: > > > >A) Deprecate Site-Local addresses independently from having an > alternative > >solution available. This would mean that the working group should treat > >the deprecation, and requirements and solution documents outlined above > >independently from each other. If there was no consensus on an > >alternative a replacement would not happen. > > > >B) Deprecate Site-Local addresses at the same time as a alternative > >solution is agreed to. This would mean advancing both documents at the > >same time and making them include normative references to each other to > >insure that they were published at the same time. This would result in > >the deprecation only happening if a consensus was reached on an > alternative. > > > >C) Deprecate Site-Local addresses after an alternative is defined, > >standardized, and in operational practice. This would mean not > advancing > >a deprecation document until there was operational evidence that the > >alternative was working and shown to be an improvement over Site-Local > >addresses. > > > >Note: In the above choices "Deprecate Site-Local addresses" means > >publishing an RFC that does the formal deprecation. > > > >Please respond to the list with your preference, or if there is an > >alternative approach that is an improvement from the ones I outlined. I > >hope that many of you will respond. > > > >Thanks, > >Bob > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 14:37:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11312 for ; Fri, 10 Oct 2003 14:37:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A828c-0000ON-Qs for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 14:37:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AIbId9001498 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 14:37:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A828c-0000Nx-0O for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 14:37:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11268 for ; Fri, 10 Oct 2003 14:37:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A828Z-0007Nc-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 14:37:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A828Y-0007NZ-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 14:37:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A828L-0000FJ-PN; Fri, 10 Oct 2003 14:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A827f-00008P-5G for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 14:36:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11235; Fri, 10 Oct 2003 14:36:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A827b-0007Mi-00; Fri, 10 Oct 2003 14:36:16 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A827b-0007Me-00; Fri, 10 Oct 2003 14:36:15 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9AIZacb005067; Fri, 10 Oct 2003 11:35:38 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AMK37233; Fri, 10 Oct 2003 11:31:17 -0700 (PDT) Message-Id: <6.0.0.22.2.20031010111733.041e6000@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 10 Oct 2003 11:34:04 -0700 To: Margaret.Wasserman@nokia.com From: Fred Baker Subject: Removing features Cc: , , , , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , At 08:09 AM 10/10/2003, Margaret.Wasserman@nokia.com wrote: >Removing a feature from a specification doesn't even prevent people from >using it I'm changing the thread subject. While this is relevant to the subject of Tony's appeal, it is also a general debate orthogonal to Tony's appeal. It is a side note that may prove relevant. While your assertion may generally be true, this particular change does prevent people from using it, and I'm not sure the assertion is true as worded. The site-local proposal says that there is an assurance that a particular block of addresses is available to a network administration to use in whatever way it chooses within the confines of its own network, on the proviso that it neither advertise those addresses outside its network in routing nor trust announcements of the block by others, and presumably also ingress filters for the address prefix. Removing the concept removes that capability. YMMV as to whether you want the capability, but you cannot accurately say that the capability still exists once it has been removed. Your assertion is also dangerous in protocols. If a capability is deprecated (remains defined but its implementation/use is discouraged, as for example true of TOS routing in OSPF, cf RFCs 1583, 2178, and 2328), then an implementation that contains the capability can accurately say it is using a superset of the specification. If the capability is simply removed, one has to presume that at some time in the future the bits will be reused with different semantics, making the implementation that yesterday was using a superset of the specification an active hazard today, and causing operational networks that were using the capability to have to make some potentially hard choices. So in the general case I don't see a problem with deprecating things under the right circumstances, but I do have a problem with removing them outright. Deprecation doesn't prevent people from using them, but outright removal can be dangerous. And in this case, the assertion that one can still use the address prefix in a local manner is simply incorrect; it can be assigned at the whim of IANA, and network administrations need to plan accordingly. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 14:46:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11799 for ; Fri, 10 Oct 2003 14:46:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A82HE-0001Kx-85 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 14:46:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AIkCEX005133 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 14:46:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A82HE-0001Kg-1S for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 14:46:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11738 for ; Fri, 10 Oct 2003 14:46:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A82HB-0007Vw-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 14:46:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A82HA-0007Vp-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 14:46:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A82H5-0001BS-Jc; Fri, 10 Oct 2003 14:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A82G8-00017J-P9 for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 14:45:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11620; Fri, 10 Oct 2003 14:44:55 -0400 (EDT) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A82G5-0007Tw-00; Fri, 10 Oct 2003 14:45:01 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A82G4-0007To-00; Fri, 10 Oct 2003 14:45:00 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9AIiwv26172; Fri, 10 Oct 2003 21:44:58 +0300 (EET DST) Received: from daebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 10 Oct 2003 21:44:57 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 10 Oct 2003 11:43:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Removing features Date: Fri, 10 Oct 2003 14:43:49 -0400 Message-ID: Thread-Topic: Removing features Thread-Index: AcOPXYGny6eNvc5IT4axQxuM6Avu+gAADypw To: Cc: , , , , X-OriginalArrivalTime: 10 Oct 2003 18:43:52.0986 (UTC) FILETIME=[73D9D7A0:01C38F5E] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Fred, > So in the general case I don't see a problem with deprecating=20 > things under the right circumstances, but I do have a problem with=20 > removing them outright. Deprecation doesn't prevent people from using=20 > them, but outright removal can be dangerous. And in this case, the=20 > assertion that one can still use the address prefix in a local manner=20 > is simply incorrect; it can be assigned at the whim of IANA, and=20 > network administrations need to plan accordingly.=20 Actually, we are being very careful about this in the deprecation of IPv6 site-local addressing. Christian Huitema and Brian Carpenter=20 have co-authored a very carefully written deprecation document that=20 makes it clear how these addresses should be treated to avoid problems=20 with existing site-local implementations. And, we are planning to=20 instruct IANA not to return these addresses to the regular allocation=20 pool. Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 14:54:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12451 for ; Fri, 10 Oct 2003 14:54:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A82P0-0002Oy-5a for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 14:54:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AIsERK009228 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 14:54:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A82Oz-0002Ol-W5 for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 14:54:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12407 for ; Fri, 10 Oct 2003 14:54:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A82Ox-0007il-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 14:54:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A82Ow-0007ii-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 14:54:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A82Oo-0002Ku-80; Fri, 10 Oct 2003 14:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A82Nu-0002Cc-Jb for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 14:53:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12292; Fri, 10 Oct 2003 14:52:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A82Nq-0007gj-00; Fri, 10 Oct 2003 14:53:03 -0400 Received: from alicia.nttmcl.com ([216.69.69.10]) by ietf-mx with esmtp (Exim 4.12) id 1A82Np-0007e9-00; Fri, 10 Oct 2003 14:53:02 -0400 Received: from nttmcl.com (daal.nttmcl.com [216.69.69.11]) by alicia.nttmcl.com (8.12.9/8.12.5) with ESMTP id h9AIqMHB029432; Fri, 10 Oct 2003 11:52:23 -0700 (PDT) (envelope-from gene@nttmcl.com) Message-ID: <3F86FFD5.4050706@nttmcl.com> Date: Fri, 10 Oct 2003 11:52:05 -0700 From: "Eugene M. Kim" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en, ko-kr, ko MIME-Version: 1.0 To: Tony Hain CC: IETF IPv6 Working Group , The Internet Engineering Task Force , The Internet Engineering Steering Group , The Internet Architecture Board Subject: Re: Appeal to the IAB on the site-local issue References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tony Hain wrote: >You are listening to a very limited subset of the 'community'. I have had >several questions from fortune 500 network managers as to 'what now?' They >plan to roll out IPv6 with addresses that are in either the FEC0 range >anyway, or are trusting that the proposed replacement FC00 will be finalized >soon. > > With all due respect, it seems that it would be beneficial for both camps (for and against SL) to hear, even now, the real concerns directly from the operation people and to let them participate in the decision themselves. I'm afraid isn't particularly effective nor or appealing just to claim `There are many people who are silent now but have their stake in SL and would be jeopardized by this decision,' when the discussion and decision processes have been open to the public. I'm sure that the IAB and the IESG would also be happy to hear opinions directly from them, because that will give a clearer and broader view. It'd be a totally different story though, if you officially represented a group of operation people when you opposed SL deprecation. I apologize if this was indeed the case. Regards, Eugene -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 15:10:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13786 for ; Fri, 10 Oct 2003 15:10:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A82dz-0003VX-Gr for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 15:09:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AJ9h79013477 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 15:09:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A82dv-0003VG-Fj for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 15:09:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13680 for ; Fri, 10 Oct 2003 15:09:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A82ds-0000BE-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 15:09:36 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A82ds-0000BB-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 15:09:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A82dK-0003KO-Ic; Fri, 10 Oct 2003 15:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8205-0008FQ-28 for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 14:28:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10991; Fri, 10 Oct 2003 14:28:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8201-0007Kw-00; Fri, 10 Oct 2003 14:28:25 -0400 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx with esmtp (Exim 4.12) id 1A8200-0007Kp-00; Fri, 10 Oct 2003 14:28:24 -0400 Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h9AIId6U002823; Fri, 10 Oct 2003 14:18:39 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h9AIIdLF002822; Fri, 10 Oct 2003 14:18:39 -0400 (EDT) Date: Fri, 10 Oct 2003 14:18:39 -0400 (EDT) From: Scott Bradner Message-Id: <200310101818.h9AIIdLF002822@newdev.harvard.edu> To: michel@arneill-py.sacramento.ca.us, narten@us.ibm.com Subject: Re: Appeal to the IAB on the site-local issue Cc: alh-ietf@tndh.net, harald@alvestrand.no, iab@iab.org, iesg@ietf.org, ietf@ietf.org, ipv6@ietf.org In-Reply-To: <200310101559.h9AFxcQR005188@rotala.raleigh.ibm.com> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , note that this survey was done *after* the decision was announced as a done deal - I, for one, took that into account when I responded ---- From: Bob Hinden & Brian Haberman To: ipv6@ietf.org Cc: hinden@iprg.nokia.com, Brian Haberman Date: Tue, 16 Sep 2003 10:55:33 -0700 Subject: Results of Poll The results of the poll (appended below) started by the chairs in early August to get more feed back from the working about how to deprecate site-local are as follows: Preference A 32 45% Preference B 31 44% Preference C 8 11% -------------------------- Total Votes 71 100% The raw votes are available at: http://people.nokia.net/~hinden/ipv6-choices.html If we missed your preference or got it wrong, please let us know. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 15:33:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15360 for ; Fri, 10 Oct 2003 15:33:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A830i-0004ve-Um for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 15:33:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AJXC4R018940 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 15:33:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A830i-0004vP-Nq for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 15:33:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15330 for ; Fri, 10 Oct 2003 15:33:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A830h-0000Sw-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 15:33:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A830g-0000Ss-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 15:33:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A830X-0004oF-UU; Fri, 10 Oct 2003 15:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A830E-0004nP-6Y for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 15:32:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15310; Fri, 10 Oct 2003 15:32:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A830B-0000SP-00; Fri, 10 Oct 2003 15:32:39 -0400 Received: from as13-3-2.rny.s.bonet.se ([217.215.166.49] helo=klapautius.it.su.se) by ietf-mx with esmtp (Exim 4.12) id 1A830A-0000SH-00; Fri, 10 Oct 2003 15:32:38 -0400 Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h9ALUuR22076; Fri, 10 Oct 2003 23:30:57 +0200 Message-ID: <3F87250F.7050700@it.su.se> Date: Fri, 10 Oct 2003 23:30:55 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en, en-us MIME-Version: 1.0 To: "Eugene M. Kim" CC: Tony Hain , IETF IPv6 Working Group , The Internet Engineering Task Force , The Internet Engineering Steering Group , The Internet Architecture Board Subject: Re: Appeal to the IAB on the site-local issue References: <3F86FFD5.4050706@nttmcl.com> In-Reply-To: <3F86FFD5.4050706@nttmcl.com> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eugene M. Kim wrote: | | With all due respect, it seems that it would be beneficial for both | camps (for and against SL) to hear, even now, the real concerns directly | from the operation people and to let them participate in the decision | themselves. ... Been there. Done that. Didn't work. This vast Moral Majority of the Site-Locals either don't exist or live entierly behind NATs or other boxes which prevent them from receiving the call to arms to participate in the debate. ;-) Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/hyUP8Jx8FtbMZncRAjBrAJ9mn99C+vUGrNifGl+moqvMz31qPgCfavjp ZpDTz3E6/Z54/T4qRpL8W3o= =LQPP -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 15:40:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16023 for ; Fri, 10 Oct 2003 15:40:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A837j-000603-H6 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 15:40:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AJeRgO023056 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 15:40:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A837j-0005zn-Cq for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 15:40:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15964 for ; Fri, 10 Oct 2003 15:40:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A837h-0000YV-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 15:40:25 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A837h-0000YR-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 15:40:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A837P-0005lX-Nz; Fri, 10 Oct 2003 15:40:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A836l-0005dH-Bu for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 15:39:27 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15840; Fri, 10 Oct 2003 15:39:18 -0400 (EDT) Message-Id: <200310101939.PAA15840@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-addr-arch-v4-00.txt Date: Fri, 10 Oct 2003 15:39:18 -0400 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --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) : R. Hinden, S. Deering Filename : draft-ietf-ipv6-addr-arch-v4-00.txt Pages : 25 Date : 2003-10-10 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-3513 'IP Version 6 Addressing Architecture'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-addr-arch-v4-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-addr-arch-v4-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: <2003-10-10143327.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-addr-arch-v4-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-addr-arch-v4-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-10143327.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 15:46:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16867 for ; Fri, 10 Oct 2003 15:46:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83Ck-0006qy-ED for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 15:45:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AJjcL5026337 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 15:45:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83Cj-0006qe-O2 for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 15:45:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16762 for ; Fri, 10 Oct 2003 15:45:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A83Ch-0000nM-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 15:45:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A83Ca-0000nC-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 15:45:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83CB-0006hS-Ei; Fri, 10 Oct 2003 15:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83BP-0006eB-L4 for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 15:44:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16542; Fri, 10 Oct 2003 15:44:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A83BK-0000iq-00; Fri, 10 Oct 2003 15:44:10 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1A83BJ-0000il-00; Fri, 10 Oct 2003 15:44:09 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id DD891141B4; Fri, 10 Oct 2003 15:44:08 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13876-04; Fri, 10 Oct 2003 15:44:07 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 1A3D71412A; Fri, 10 Oct 2003 15:44:07 -0400 (EDT) Date: Fri, 10 Oct 2003 15:40:11 -0400 From: Keith Moore To: Fred Baker Cc: moore@cs.utk.edu, Margaret.Wasserman@nokia.com, sob@harvard.edu, iab@iab.org, iesg@ietf.org, ietf@ietf.org, ipv6@ietf.org Subject: Re: Removing features Message-Id: <20031010154011.17ee6634.moore@cs.utk.edu> In-Reply-To: <6.0.0.22.2.20031010111733.041e6000@mira-sjc5-b.cisco.com> References: <6.0.0.22.2.20031010111733.041e6000@mira-sjc5-b.cisco.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > At 08:09 AM 10/10/2003, Margaret.Wasserman@nokia.com wrote: > >Removing a feature from a specification doesn't even prevent people > >from using it > > I'm changing the thread subject. While this is relevant to the subject > of Tony's appeal, it is also a general debate orthogonal to Tony's > appeal. It is a side note that may prove relevant. While your > assertion may generally be true, this particular change does prevent > people from using it, and I'm not sure the assertion is true as > worded. Given that the objections to site local were based on the realization that using it actually causes harm to applications and to the network, then I agree with you. Most of us realize that we cannot prevent harmful behavior, especially on a private network. But the intent of deprecating site-local was at the very minimum to strongly discourage its use. > The site-local proposal says that there is an assurance that a > particular block of addresses is available to a network administration > to use in whatever way it chooses within the confines of its own > network, on the proviso that it neither advertise those addresses > outside its network in routing nor trust announcements of the block by > others, and presumably also ingress filters for the address prefix. It turns out that those usage constraints are not sufficient to avoid harm to the network as a whole, and after numerous attempts we have not been able to define a set of constraints that still allow use of site-local while avoiding that harm. > Your assertion is also dangerous in protocols. If a capability is > deprecated (remains defined but its implementation/use is discouraged, > as for example true of TOS routing in OSPF, cf RFCs 1583, 2178, and > 2328), then an implementation that contains the capability can > accurately say it is using a superset of the specification. The terms you are using are biased. A vendor could define a "superset" of IP that had the "capability" of routing addresses to destinations other than those intended by the source, or modifying the contents of messages sent by the source, or masquerading as the destination and issuing responses that appear to come from the destination. A DNS server could add the "capability" of misrepresenting the status of a name given in a query. Indeed, all of these "capabilities" exist in some product or another. It also turns out that all of these "capabilities" cause harm to applications. It's a fallacy to believe, and disingeneous to pretend, that providing new "capabilities" or a "superset" of a protocol is at worst a benign activity. There exist "capabilities" that do harm. In the case of site-locals, it happens that this "capability" was part of an IETF specification. So once we realized that site-locals were harmful, it became our responsibility to fix them. I agree, as do most of us, that we should make considerable effort to avoid disruptive changes to published specifications. However it was only after investigating several proposals for less disruptive fixes, and finding all of them insufficient, that there emerged a consensus to deprecate site-locals. > If the > capability is simply removed, one has to presume that at some time in > the future the bits will be reused with different semantics, making > the implementation that yesterday was using a superset of the > specification an active hazard today, and causing operational networks > that were using the capability to have to make some potentially hard > choices. We can promise to not re-assign them, and we can keep our promise. But if site administrators decide to move away from site-locals, this is a good thing, as it will minimize the harm done by having them in the wild. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 15:48:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17245 for ; Fri, 10 Oct 2003 15:48:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83FM-0007Pr-Vq for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 15:48:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AJmK2d028501 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 15:48:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83FM-0007Pc-6L for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 15:48:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17115 for ; Fri, 10 Oct 2003 15:48:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A83FK-0000tf-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 15:48:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A83FK-0000tc-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 15:48:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83F5-0007Bp-UD; Fri, 10 Oct 2003 15:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83Ex-00079Y-1N for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 15:47:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17074; Fri, 10 Oct 2003 15:47:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A83Eu-0000sT-00; Fri, 10 Oct 2003 15:47:52 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1A83Et-0000sK-00; Fri, 10 Oct 2003 15:47:51 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id EE7AB14129; Fri, 10 Oct 2003 15:47:51 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14254-06; Fri, 10 Oct 2003 15:47:51 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id B5CC014196; Fri, 10 Oct 2003 15:47:50 -0400 (EDT) Date: Fri, 10 Oct 2003 15:43:55 -0400 From: Keith Moore To: "Tony Hain" Cc: moore@cs.utk.edu, narten@us.ibm.com, michel@arneill-py.sacramento.ca.us, harald@alvestrand.no, alh-ietf@tndh.net, iab@iab.org, iesg@ietf.org, ipv6@ietf.org, ietf@ietf.org Subject: Re: Appeal to the IAB on the site-local issue Message-Id: <20031010154355.11275d3e.moore@cs.utk.edu> In-Reply-To: References: <200310101559.h9AFxcQR005188@rotala.raleigh.ibm.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > You are listening to a very limited subset of the 'community'. I have had > several questions from fortune 500 network managers as to 'what now?' They > plan to roll out IPv6 with addresses that are in either the FEC0 range > anyway, or are trusting that the proposed replacement FC00 will be finalized > soon. maybe those people are being fed bad information. the question is, by whom? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 16:02:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18703 for ; Fri, 10 Oct 2003 16:02:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83Sb-00087a-1L for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 16:02:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AK21Ce031218 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 16:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83Sa-00087R-NZ for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 16:02:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18613 for ; Fri, 10 Oct 2003 16:01:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A83SZ-0001Mo-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 16:01:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A83SY-0001Ml-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 16:01:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83Rf-0007ub-Vx; Fri, 10 Oct 2003 16:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83M9-0007m0-N7 for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 15:55:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17905; Fri, 10 Oct 2003 15:55:13 -0400 (EDT) From: Valdis.Kletnieks@vt.edu Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A83M7-00018A-00; Fri, 10 Oct 2003 15:55:19 -0400 Received: from turing-police.cc.vt.edu ([128.173.14.107]) by ietf-mx with esmtp (Exim 4.12) id 1A83M7-000180-00; Fri, 10 Oct 2003 15:55:19 -0400 Received: from turing-police.cc.vt.edu (IDENT:valdis@localhost [127.0.0.1]) by turing-police.cc.vt.edu (8.12.10/8.12.10) with ESMTP id h9AJt6RX003398; Fri, 10 Oct 2003 15:55:06 -0400 Message-Id: <200310101955.h9AJt6RX003398@turing-police.cc.vt.edu> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4+dev To: Fred Baker Cc: iab@iab.org, iesg@ietf.org, ietf@ietf.org, ipv6@ietf.org Subject: Re: Removing features In-Reply-To: Your message of "Fri, 10 Oct 2003 11:34:04 PDT." <6.0.0.22.2.20031010111733.041e6000@mira-sjc5-b.cisco.com> References: <6.0.0.22.2.20031010111733.041e6000@mira-sjc5-b.cisco.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-616238898P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 10 Oct 2003 15:55:06 -0400 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --==_Exmh_-616238898P Content-Type: text/plain; charset=us-ascii On Fri, 10 Oct 2003 11:34:04 PDT, Fred Baker said: > The site-local proposal says that there is an assurance that a particular > block of addresses is available to a network administration to use in > whatever way it chooses within the confines of its own network, on the > proviso that it neither advertise those addresses outside its network in > routing nor trust announcements of the block by others, and presumably also > ingress filters for the address prefix. Removing the concept removes that > capability. YMMV as to whether you want the capability, but you cannot > accurately say that the capability still exists once it has been removed. On the flip side, the biggest basis for removing the feature is the fact that RFC1918 contains essentially the same provision for IPv4, and 1918 addresses are continually leaking like sieves, and nobody (to my knowledge) was able to point at magic router filter dust that would prevent it from happening on IPv6. So the basic concept is (in my opinion) broken and needs to be euthanized. > outright. Deprecation doesn't prevent people from using them, but outright > removal can be dangerous. And in this case, the assertion that one can > still use the address prefix in a local manner is simply incorrect; it can > be assigned at the whim of IANA, and network administrations need to plan > accordingly. And in fact, we've seen this effect in operation recently, when the 69/8 address space was allocated but often unreachable due to bogon filters.... All in all, however, I think outright removal, although short-term more painful, will be less troublesome than many years of debugging problems caused by 1918-style leakage of addresses for a "deprecated" feature. --==_Exmh_-616238898P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE/hw6acC3lWbTT17ARAkKHAKC9AnIs9ADnIlVNJNob6L/Yu+khUACfdZ7h jYoBYJJed2s3k68TNYUEQu8= =VMnG -----END PGP SIGNATURE----- --==_Exmh_-616238898P-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 16:27:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20857 for ; Fri, 10 Oct 2003 16:27:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83qW-0001f6-D8 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 16:26:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AKQiGM006382 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 16:26:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83qW-0001er-5w for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 16:26:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20777 for ; Fri, 10 Oct 2003 16:26:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A83qU-00024q-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 16:26:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A83qT-00024m-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 16:26:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83pq-0001Qr-AF; Fri, 10 Oct 2003 16:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83p4-0001Gu-9A for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 16:25:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20663; Fri, 10 Oct 2003 16:25:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A83p1-000231-00; Fri, 10 Oct 2003 16:25:12 -0400 Received: from ns2.sea.interquest.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1A83p1-00022y-00; Fri, 10 Oct 2003 16:25:11 -0400 Received: from ssprunk (ip135.post-vineyard.dfw.interquest.net [66.135.181.135]) by ns2.sea (8.12.10/8.12.5) with SMTP id h9AKP5fa005942; Fri, 10 Oct 2003 13:25:06 -0700 Message-ID: <011f01c38f6c$99c12dc0$6401a8c0@ssprunk> From: "Stephen Sprunk" To: "Leif Johansson" , "Eugene M. Kim" Cc: "Tony Hain" , "IETF IPv6 Working Group" , "The Internet Engineering Task Force" , "The Internet Engineering Steering Group" , "The Internet Architecture Board" References: <3F86FFD5.4050706@nttmcl.com> <3F87250F.7050700@it.su.se> Subject: Re: Appeal to the IAB on the site-local issue Date: Fri, 10 Oct 2003 15:23:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thus spake "Leif Johansson" > Been there. Done that. Didn't work. This vast Moral Majority of the > Site-Locals either don't exist or live entierly behind NATs or other > boxes which prevent them from receiving the call to arms to participate > in the debate. ;-) Or we all just got sick of the bickering and accepted defeat (unlike Tony). For the record, I can't support deprecating site locals until we have something else approved to replace them -- at which point I say good riddance. There are several drafts in the WG to that end which haven't gained any momentum thus far. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 16:43:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22087 for ; Fri, 10 Oct 2003 16:43:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A846e-0003Fg-CM for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 16:43:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AKhOCU012494 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 16:43:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A846e-0003FR-47 for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 16:43:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22041 for ; Fri, 10 Oct 2003 16:43:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A846c-0002SG-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 16:43:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A846b-0002SD-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 16:43:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A846I-00035n-7C; Fri, 10 Oct 2003 16:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A845b-000315-8O for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 16:42:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21929; Fri, 10 Oct 2003 16:42:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A845Y-0002Od-00; Fri, 10 Oct 2003 16:42:16 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A845Y-0002NA-00; Fri, 10 Oct 2003 16:42:16 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 10 Oct 2003 13:49:46 -0700 Received: from cisco.com (rtp-vpn2-432.cisco.com [10.82.241.176]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h9AKecYb007313; Fri, 10 Oct 2003 13:40:39 -0700 (PDT) Message-ID: <3F871946.400@cisco.com> Date: Fri, 10 Oct 2003 13:40:38 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Sprunk CC: Leif Johansson , "Eugene M. Kim" , Tony Hain , IETF IPv6 Working Group , The Internet Engineering Task Force , The Internet Engineering Steering Group , The Internet Architecture Board Subject: Re: Appeal to the IAB on the site-local issue References: <3F86FFD5.4050706@nttmcl.com> <3F87250F.7050700@it.su.se> <011f01c38f6c$99c12dc0$6401a8c0@ssprunk> In-Reply-To: <011f01c38f6c$99c12dc0$6401a8c0@ssprunk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Stephen Sprunk wrote: > Or we all just got sick of the bickering and accepted defeat (unlike Tony). > > For the record, I can't support deprecating site locals until we have > something else approved to replace them -- at which point I say good > riddance. There are several drafts in the WG to that end which haven't > gained any momentum thus far. And this is why the appeal is in my opinion untimely. The working group has not yet been given a chance to provide any documentation on that "What next?" question Tony asked. For the IESG or the IAB to interfere at this stage would be micromanagement. But here we are. Tony has decided to push an appeal of a "vote", and not even one that generated a document. That the appeal has even gotten this far seems is a flaw in the process. Had the IESG been able to disallow the appeal, simply on this basis, then perhaps the working group could actually provide documents about which we could argue over technical merit. As it stands, I predict yet another round of appeals once IETF last call closes, and the document is reviewed by the IESG. Welcome to Court TV, IETF style. Eliot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 17:25:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23643 for ; Fri, 10 Oct 2003 17:25:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A84kz-0005H3-6x for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 17:25:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ALP5uP020267 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 17:25:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A84ky-0005Go-TY for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 17:25:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23602 for ; Fri, 10 Oct 2003 17:24:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A84kw-0002wS-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 17:25:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A84kw-0002wP-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 17:25:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A84jy-00052X-Gu; Fri, 10 Oct 2003 17:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A84jn-00051S-To for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 17:23:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23546; Fri, 10 Oct 2003 17:23:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A84jk-0002vP-00; Fri, 10 Oct 2003 17:23:48 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1A84jk-0002vL-00; Fri, 10 Oct 2003 17:23:48 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 78CF314020; Fri, 10 Oct 2003 17:23:48 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27824-04; Fri, 10 Oct 2003 17:23:47 -0400 (EDT) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id A3F8913FE5; Fri, 10 Oct 2003 17:23:45 -0400 (EDT) Date: Fri, 10 Oct 2003 17:20:25 -0400 From: Keith Moore To: "Stephen Sprunk" Cc: moore@cs.utk.edu, leifj@it.su.se, gene@nttmcl.com, alh-ietf@tndh.net, ipv6@ietf.org, ietf@ietf.org, iesg@ietf.org, iab@iab.org Subject: Re: Appeal to the IAB on the site-local issue Message-Id: <20031010172025.704837be.moore@cs.utk.edu> In-Reply-To: <011f01c38f6c$99c12dc0$6401a8c0@ssprunk> References: <3F86FFD5.4050706@nttmcl.com> <3F87250F.7050700@it.su.se> <011f01c38f6c$99c12dc0$6401a8c0@ssprunk> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > For the record, I can't support deprecating site locals until we have > something else approved to replace them replace them for what purpose? different people wanted site locals for different purposes. some of those purposes are dubious. others inherently cause harm. we're not going to find a single solution that satisfies all of the purposes for which people thought site-locals were a good idea. and that is a good thing. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 17:43:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24305 for ; Fri, 10 Oct 2003 17:43:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A852O-0006T2-K0 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 17:43:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ALh4Q8024854 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 17:43:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A852O-0006Sn-FR for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 17:43:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24268 for ; Fri, 10 Oct 2003 17:42:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A852L-0003At-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 17:43:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A852L-0003Ao-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 17:43:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A851N-0006BO-TZ; Fri, 10 Oct 2003 17:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A850q-00065s-9f for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 17:41:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24157; Fri, 10 Oct 2003 17:41:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A850n-00038F-00; Fri, 10 Oct 2003 17:41:25 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A850m-00037z-00; Fri, 10 Oct 2003 17:41:24 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9ALdgUt023299; Fri, 10 Oct 2003 14:39:42 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AMK57713; Fri, 10 Oct 2003 14:35:23 -0700 (PDT) Message-Id: <6.0.0.22.2.20031010142000.04624670@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 10 Oct 2003 14:29:24 -0700 To: Valdis.Kletnieks@vt.edu From: Fred Baker Subject: Re: Removing features Cc: iab@iab.org, iesg@ietf.org, ietf@ietf.org, ipv6@ietf.org In-Reply-To: <200310101955.h9AJt6RX003398@turing-police.cc.vt.edu> References: <6.0.0.22.2.20031010111733.041e6000@mira-sjc5-b.cisco.com> <200310101955.h9AJt6RX003398@turing-police.cc.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , At 12:55 PM 10/10/2003, Valdis.Kletnieks@vt.edu wrote: >All in all, however, I think outright removal, although short-term more >painful, will be less troublesome than many years of debugging problems >caused by 1918-style leakage of addresses for a "deprecated" feature. That may be so. It is a third discussion, and is appropriate to the IPv6 list. The first discussion is Tony's appeal, which is a procedural discussion and should not be debated on the basis of whether one agrees or disagrees with the particular feature (site-local addresses) but on the basis of whether the right consensus development and recognition procedures were followed. The Author/Editor of the procedural description has commented that it looked problematic to him. The second is the side point I raised with Margaret: in the general case of "things in specifications", removing something from a specification does not mean that someone can still use it. Deprecation protects such a usage, but removal does not. The third point, the one you address, is where all this started out, which is whether or not one should entertain site-local addresses at all. It is relevant to neither the procedural discussion nor the general discussion about removing features. But it is clearly something that the IPv6 working group needs to have a consensus opinion on. That is actually not the subject of either appeal, and should not enter into the discussion of either appeal, as it has no bearing on the thing appealed - which is the procedural issue. Using the wrong procedure to accomplish the right result (if one assumes that this is what happened) is just as bad as using the right procedure to produce the wrong result. One wants to use the right procedure *and* produce the right result. When I changed the topic, I changed the subject line... Let's not confuse issues. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 17:46:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24462 for ; Fri, 10 Oct 2003 17:46:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8558-00072v-LZ for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 17:45:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ALjswj027079 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 17:45:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8558-00072g-El for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 17:45:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24427 for ; Fri, 10 Oct 2003 17:45:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8555-0003EN-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 17:45:51 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8555-0003EK-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 17:45:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A854J-0006ji-5e; Fri, 10 Oct 2003 17:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8547-0006j8-Nu for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 17:44:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24386; Fri, 10 Oct 2003 17:44:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8544-0003Cx-00; Fri, 10 Oct 2003 17:44:48 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1A8543-0003Cu-00; Fri, 10 Oct 2003 17:44:48 -0400 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9ALhted010164; Fri, 10 Oct 2003 23:43:58 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 10 Oct 2003 23:43:20 +0200 Subject: Re: Removing features Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: iab@iab.org, iesg@ietf.org, ietf@ietf.org, ipv6@ietf.org To: Valdis.Kletnieks@vt.edu From: Iljitsch van Beijnum In-Reply-To: <200310101955.h9AJt6RX003398@turing-police.cc.vt.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On vrijdag, okt 10, 2003, at 21:55 Europe/Amsterdam, Valdis.Kletnieks@vt.edu wrote: > the biggest basis for removing the feature is the fact that > RFC1918 contains essentially the same provision for IPv4, and 1918 > addresses > are continually leaking like sieves, and nobody (to my knowledge) was > able to > point at magic router filter dust that would prevent it from happening > on IPv6. > So the basic concept is (in my opinion) broken and needs to be > euthanized. This is based on the assumption that leaking RFC 1918 routing information or packets with RFC 1918 source or destination addresses is actually harmful in and of itself. This is a broken assumption. If people are going to send bogus routes or packets, then having RFC 1918 addresses in them is the least harmful way to do it. Now obviously people shouldn't send out bogus routes or packets, but this is a problem that is completely unrelated to private addressing issues. It's just that private addresses make this problem much more visible. Removing that which is clearly wrong only helps to make sure the wrongness that remains is less visible. And if you're unable to figure out how to filter private addresses in routing updates or IP traffic, there are numerous non-magical books out there that will tell you how to do this. >> outright. Deprecation doesn't prevent people from using them, but >> outright >> removal can be dangerous. And in this case, the assertion that one can >> still use the address prefix in a local manner is simply incorrect; >> it can >> be assigned at the whim of IANA, and network administrations need to >> plan >> accordingly. > And in fact, we've seen this effect in operation recently, when the > 69/8 address > space was allocated but often unreachable due to bogon filters.... > All in all, however, I think outright removal, although short-term > more painful, > will be less troublesome than many years of debugging problems caused > by > 1918-style leakage of addresses for a "deprecated" feature. Your argument is self-defeating. If we were to recycle FEC0::/10 this would be the 69.0.0.0/8 but ten times worse. Everybody knew that 69.0.0.0/8 would be assigned at some point, so the people filtering this range knew what they were doing (or at least, they should have). FEC0::/10 on the other hand has been in the specification as a fixed special purpose range for a lot of years, and presumably people have implemented their networks accordingly. Pulling the rug from under them by removing this address range from the spefication and (at least theoretically) allowing it to be reassigned for a different purpose is insane. And that's not even considering the lack of alternatives at this point in time. We may not be able to come up with a reasonable way for networks that implement site local addressing and interconnect with other networks that do the same, but there is still a very real need for addresses that can be used in disconnected IPv6 networks. I believe that forcing people who just want to interconnect a few boxes to do some testing to obtain globally routable IPv6 unicast space is a very bad idea. As long as there aren't any alternatives, FEC0::/10 should be used for this. And even after we have alternatives, FEC0::/10 should forever be set aside to avoid problems. > Huh? Iljitsch van Beijnum -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 18:05:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25434 for ; Fri, 10 Oct 2003 18:05:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A85Nl-0007t7-VC for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 18:05:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AM59nO030321 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 18:05:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A85Nl-0007sy-PO for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 18:05:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25356 for ; Fri, 10 Oct 2003 18:04:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A85Ni-0003WT-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 18:05:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A85Ni-0003WN-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 18:05:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A85Mf-0007Z8-W4; Fri, 10 Oct 2003 18:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A85ML-0007Y0-V1 for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 18:03:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25188; Fri, 10 Oct 2003 18:03:31 -0400 (EDT) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A85MI-0003Ua-00; Fri, 10 Oct 2003 18:03:38 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A85MH-0003UT-00; Fri, 10 Oct 2003 18:03:37 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9AM3ZZ04816; Sat, 11 Oct 2003 01:03:35 +0300 (EET DST) Received: from daebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 11 Oct 2003 01:03:35 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 10 Oct 2003 17:03:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Removing features Date: Fri, 10 Oct 2003 18:03:31 -0400 Message-ID: Thread-Topic: Removing features Thread-Index: AcOPd1/+YXk8uCDNSGq4vJ5C4Xuh1gAAZMNA To: , Cc: , , , X-OriginalArrivalTime: 10 Oct 2003 22:03:33.0656 (UTC) FILETIME=[58E30180:01C38F7A] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable =20 > The second is the side point I raised with Margaret: in the=20 > general case of "things in specifications", removing something=20 > from a specification does not mean that someone can still use=20 > it. Deprecation protects such a usage, but removal does not. Scott's posting made a distinction between adding and removing features, lumping site-local deprecation into the "removing features" category. I echoed his terminology. I agree with you that there is a difference between simply removing a feature (which might cause serious backwards compatibility concerns, and could be quite irresponsible in some cases) and carefully deprecating a feature (while considering the affects on current implementations and preserving backwards=20 compatibility). In the IPv6 site-local case, the decision was made=20 to deprecate site-local addresses, and that is what we are working=20 to do. The proposals currently on the table reserve the current=20 site-local prefix, so that it will not be reallocated by IANA. Fred, I hope that this resolves your technical concern about this particular case, and I apologize for not making this distinction clear in my response to Scott. =20 > That is actually not the=20 > subject of either appeal, and should not enter into the discussion of=20 > either appeal,... As far as I know, there is only one appeal currently open regarding this subject. Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 18:12:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26240 for ; Fri, 10 Oct 2003 18:12:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A85Uj-0000QE-1K for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 18:12:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AMCKNS001616 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 18:12:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A85Ui-0000Pz-QV for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 18:12:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26113 for ; Fri, 10 Oct 2003 18:12:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A85Uf-0003b5-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 18:12:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A85Uf-0003b2-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 18:12:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A85UP-0000GI-LU; Fri, 10 Oct 2003 18:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A85Tf-0008UU-FG for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 18:11:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25974; Fri, 10 Oct 2003 18:11:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A85Tc-0003ZT-00; Fri, 10 Oct 2003 18:11:12 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A85Tb-0003Yj-00; Fri, 10 Oct 2003 18:11:11 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Oct 2003 15:18:30 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9AM9k7E028188; Fri, 10 Oct 2003 15:09:46 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AMK60803; Fri, 10 Oct 2003 15:05:23 -0700 (PDT) Message-Id: <6.0.0.22.2.20031010143040.04624358@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 10 Oct 2003 14:55:04 -0700 To: Leif Johansson From: Fred Baker Subject: Re: Appeal to the IAB on the site-local issue Cc: IETF IPv6 Working Group , The Internet Engineering Task Force , The Internet Engineering Steering Group , The Internet Architecture Board In-Reply-To: <3F87250F.7050700@it.su.se> References: <3F86FFD5.4050706@nttmcl.com> <3F87250F.7050700@it.su.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , At 02:30 PM 10/10/2003, Leif Johansson wrote: >>With all due respect, it seems that it would be beneficial for both camps >>(for and against SL) to hear, even now, the real concerns directly from >>the operation people and to let them participate in the decision >>themselves. ... > >Been there. Done that. Didn't work. This vast Moral Majority of the >Site-Locals either don't exist or live entierly behind NATs or other boxes >which prevent them from receiving the call to arms to participate in the >debate. ;-) Let's at least try to be fair and realistic. There is a fairly large and vocal camp from tier 1 and tier 2 operators in the IETF which presumes that the needs of a backbone service provider are the only needs that are relevant in any network and go around blasting anything they don't need as "clueless". But not all tier 1/2 operators are represented or choose to speak publicly, and not all networks are tier 1/2 networks. I have a fairly long history of sitting in the room with people from certain tier 1/2 operators who will tell me at dinner or in the hallway what they think about this or that, but are precluded from speaking for themselves publicly by the policy or culture of their employers. I'm not naming names, because that would be inappropriate (if they can't/won't speak for themselves because their employer doesn't want to tip a business hand, who am I to tip it for them?). But I guarantee you that they are present, and they don't necessarily agree with the vocal operators. When it comes to tertiary operators and enterprises, let's face it. They're vastly under-represented, and perhaps not at all represented. If they were represented as completely as the Tier 1/2 operators are, we would routinely have meetings with multiples of 10K attendees. They don't come to IETF meetings. They read about them in Network World and Computer Week, they tell their vendors what they are willing to buy, and their vendors come talk about the features smaller operators and enterprises are asking for. The vendors take a beating from the operational elite, who tell us - we have no clue how to run a network - we have no idea what features a network needs - there is no deployed (pick your protocol that is perhaps inappropriate in a Tier 1 backbone) in the whole wide world - Specifically, there is no operational deployment of the diffserv architecture (having heard this extensively from the gentleman from Telstra, I wonder if he ever talks to the gentleman from Comindico that I spoke with last week; they seem to live on different planets) - That everything we produce and talk about is what we want to sell, not what the tier 1/2 operators or anybody else wants to buy. - That whatever we say is inherently invalid because we are vendors. Interesting. Do we do these things for our health? Do we go generate features and then try to sell them to people? Do we keep beat our heads against the wall for a decade or more while there is no market and all problems are trivially solved using other technologies? Are we that idiotic? You know, I'd like to see a little more respect for people, and for the reports they make. Yes, it would be much better if operational staff from each of the Fortune 500 companies and larger tertiary operators came to the IETF and spoke for themselves. They don't, and that doesn't make their opinions or requirements irrelevant. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 19:02:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28441 for ; Fri, 10 Oct 2003 19:02:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A86GV-00034X-6p for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 19:01:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AN1h7e011806 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 19:01:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A86GU-00034L-VN for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 19:01:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28383 for ; Fri, 10 Oct 2003 19:01:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A86GR-0004B1-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 19:01:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A86GR-0004Ay-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 19:01:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A86Fq-0002zD-9s; Fri, 10 Oct 2003 19:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A86Fg-0002xq-Sp for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 19:00:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28304; Fri, 10 Oct 2003 19:00:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A86Fc-00049b-00; Fri, 10 Oct 2003 19:00:48 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1A86Fb-00049P-00; Fri, 10 Oct 2003 19:00:47 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id AC1BE141D8; Fri, 10 Oct 2003 19:00:46 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06500-02; Fri, 10 Oct 2003 19:00:46 -0400 (EDT) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 345BC14114; Fri, 10 Oct 2003 19:00:45 -0400 (EDT) Date: Fri, 10 Oct 2003 18:57:24 -0400 From: Keith Moore To: Iljitsch van Beijnum Cc: moore@cs.utk.edu, Valdis.Kletnieks@vt.edu, iab@iab.org, iesg@ietf.org, ietf@ietf.org, ipv6@ietf.org Subject: Re: Removing features Message-Id: <20031010185724.0525853b.moore@cs.utk.edu> In-Reply-To: References: <200310101955.h9AJt6RX003398@turing-police.cc.vt.edu> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > So the basic concept is (in my opinion) broken and needs to be > > euthanized. > > This is based on the assumption that leaking RFC 1918 routing > information or packets with RFC 1918 source or destination addresses is > actually harmful in and of itself. no, it's based on (among other things) first-hand experience that applications are expected to be able to use whatever addresses are given to them, regardless of whether or not those applications employ hosts that are outside of site boundaries. > And if you're unable to figure out how to filter private addresses in > routing updates or IP traffic, there are numerous non-magical books out > there that will tell you how to do this. attempts to filter such traffic just makes the breakage worse. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 19:08:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28751 for ; Fri, 10 Oct 2003 19:08:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A86Mr-0003zi-3S for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 19:08:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AN8HRI015348 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 19:08:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A86Mq-0003zT-Sf for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 19:08:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28685 for ; Fri, 10 Oct 2003 19:08:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A86Mn-0004HZ-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 19:08:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A86Mn-0004HW-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 19:08:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A86Md-0003qR-Up; Fri, 10 Oct 2003 19:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A86MZ-0003o9-Jw for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 19:07:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28673; Fri, 10 Oct 2003 19:07:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A86MV-0004H5-00; Fri, 10 Oct 2003 19:07:55 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A86MU-0004GY-00; Fri, 10 Oct 2003 19:07:54 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9AN6u7E006958; Fri, 10 Oct 2003 16:06:56 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AMK67302; Fri, 10 Oct 2003 16:02:37 -0700 (PDT) Message-Id: <6.0.0.22.2.20031010154931.04532fc0@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 10 Oct 2003 15:50:47 -0700 To: From: Fred Baker Subject: RE: Removing features Cc: , , , , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , At 03:03 PM 10/10/2003, Margaret.Wasserman@nokia.com wrote: >Fred, I hope that this resolves your technical concern about >this particular case, and I apologize for not making this >distinction clear in my response to Scott. yes, it does. In this case, I was responding to an increase in the complexity of the debate. Whether or not you like site locals, the process of the decision and such needs to be correct, so bringing up the technical merits or demerits of site local actively doesn't help. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 19:26:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29699 for ; Fri, 10 Oct 2003 19:26:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A86e9-00056l-1X for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 19:26:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ANQ9qE019634 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 19:26:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A86e8-00056b-RT for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 19:26:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29640 for ; Fri, 10 Oct 2003 19:25:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A86e7-0004dh-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 19:26:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A86e6-0004de-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 19:26:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A86d5-0004fE-Lc; Fri, 10 Oct 2003 19:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A86RQ-0004D1-3r for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 19:13:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29087; Fri, 10 Oct 2003 19:12:50 -0400 (EDT) From: Valdis.Kletnieks@vt.edu Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A86RO-0004PM-00; Fri, 10 Oct 2003 19:12:58 -0400 Received: from turing-police.cc.vt.edu ([128.173.14.107]) by ietf-mx with esmtp (Exim 4.12) id 1A86RN-0004PI-00; Fri, 10 Oct 2003 19:12:57 -0400 Received: from turing-police.cc.vt.edu (IDENT:valdis@localhost [127.0.0.1]) by turing-police.cc.vt.edu (8.12.10/8.12.10) with ESMTP id h9ANCtRX009416; Fri, 10 Oct 2003 19:12:55 -0400 Message-Id: <200310102312.h9ANCtRX009416@turing-police.cc.vt.edu> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4+dev To: Iljitsch van Beijnum Cc: iab@iab.org, iesg@ietf.org, ietf@ietf.org, ipv6@ietf.org Subject: Re: Removing features In-Reply-To: Your message of "Fri, 10 Oct 2003 23:43:20 +0200." References: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-557933910P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 10 Oct 2003 19:12:55 -0400 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --==_Exmh_-557933910P Content-Type: text/plain; charset=us-ascii On Fri, 10 Oct 2003 23:43:20 +0200, Iljitsch van Beijnum said: > And if you're unable to figure out how to filter private addresses in > routing updates or IP traffic, there are numerous non-magical books out > there that will tell you how to do this. The problem is that usually, the offending site isn't the one feeling the pain. We've been doing bogon filtering of 1918 addresses for a LONG time. The *real* fun is collateral damage - we filter inbound 1918 source addresses. A certain clueless Tier-1 numbers their point-to-points out of 1918 space. If one of those links tosses an ICMP error, it gets dropped at our border router. Does wonders for PMTU discovery when the frag-needed packet gets tossed. How many sites have to Get It Wrong before 30% of all the packets seen at the root nameservers are from 1918 space? > Your argument is self-defeating. If we were to recycle FEC0::/10 this > would be the 69.0.0.0/8 but ten times worse. Everybody knew that > 69.0.0.0/8 would be assigned at some point, so the people filtering > this range knew what they were doing (or at least, they should have). > FEC0::/10 on the other hand has been in the specification as a fixed > special purpose range for a lot of years, and presumably people have > implemented their networks accordingly. Pulling the rug from under them > by removing this address range from the spefication and (at least > theoretically) allowing it to be reassigned for a different purpose is > insane. Agreed. On the other hand, if we don't, we're stuck looking at having inbound FEC0::/10 packets for eternity. > And that's not even considering the lack of alternatives at this point > in time. We may not be able to come up with a reasonable way for > networks that implement site local addressing and interconnect with > other networks that do the same, but there is still a very real need > for addresses that can be used in disconnected IPv6 networks. I believe > that forcing people who just want to interconnect a few boxes to do > some testing to obtain globally routable IPv6 unicast space is a very > bad idea. As long as there aren't any alternatives, FEC0::/10 should be > used for this. And even after we have alternatives, FEC0::/10 should > forever be set aside to avoid problems. Well.. OK... *disconnected* networks, I can see the point. Unfortunately, unless you make a rule that an IPv6 host will categorically refuse to accept traffic to/from a FEC0::/10 host if it knows *ANY* other non-link-local prefixes, it will end up leaking. Yes, that means if you connect and learn other prefixes, you need to renumber the site-locals. It also means that if you have a router talking to the outside world, you aren't allowed to do NAT-style games - the router has to pretend your FEC0:/10 hosts don't exist. > > > > Huh? RFC2440 - OpenPGP Message Format. J. Callas, L. Donnerhacke, H. Finney, R. Thayer. November 1998. (Format: TXT=141371 bytes) (Status: PROPOSED STANDARD) --==_Exmh_-557933910P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE/hzz2cC3lWbTT17ARAuPzAJ9q6G28lqHCnviJqvvK8OwCz6scFwCgonxZ m/XVJACnYGYd6D2DLFv4CCc= =VBOm -----END PGP SIGNATURE----- --==_Exmh_-557933910P-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 10 20:09:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01199 for ; Fri, 10 Oct 2003 20:09:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A87JQ-0007e2-5S for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 20:08:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9B08mlZ029380 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 20:08:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A87JP-0007dn-Vc for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 20:08:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01178 for ; Fri, 10 Oct 2003 20:08:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A87JN-0005D1-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 20:08:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A87JN-0005Cx-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 20:08:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A87Hk-0007Ah-Dj; Fri, 10 Oct 2003 20:07:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A87HW-000793-0g for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 20:06:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01124 for ; Fri, 10 Oct 2003 20:06:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A87HT-0005BY-00 for ipv6@ietf.org; Fri, 10 Oct 2003 20:06:47 -0400 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by ietf-mx with esmtp (Exim 4.12) id 1A87HT-0005B8-00 for ipv6@ietf.org; Fri, 10 Oct 2003 20:06:47 -0400 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id F10A718E2 for ; Fri, 10 Oct 2003 20:06:17 -0400 (EDT) Date: Fri, 10 Oct 2003 20:06:17 -0400 From: Rob Austein To: ipv6@ietf.org Subject: Re: Removing features In-Reply-To: <200310102312.h9ANCtRX009416@turing-police.cc.vt.edu> References: <200310102312.h9ANCtRX009416@turing-police.cc.vt.edu> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20031011000617.F10A718E2@thrintun.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , No offense, folks, but if you really must have yet another round of this interminable discussion, could you please trim the cc: list? Four copies of each message is a bit much. Thanks. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Oct 11 02:14:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21941 for ; Sat, 11 Oct 2003 02:14:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8D15-0001FU-0j for ipv6-archive@odin.ietf.org; Sat, 11 Oct 2003 02:14:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9B6EEkE004801 for ipv6-archive@odin.ietf.org; Sat, 11 Oct 2003 02:14:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8D14-0001FM-8S for ipv6-web-archive@optimus.ietf.org; Sat, 11 Oct 2003 02:14:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21890 for ; Sat, 11 Oct 2003 02:14:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8D10-0000bY-00 for ipv6-web-archive@ietf.org; Sat, 11 Oct 2003 02:14:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8D0z-0000bV-00 for ipv6-web-archive@ietf.org; Sat, 11 Oct 2003 02:14:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Czv-00013V-R1; Sat, 11 Oct 2003 02:13:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Czo-00012l-7B for ipv6@optimus.ietf.org; Sat, 11 Oct 2003 02:12:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21745; Sat, 11 Oct 2003 02:12:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8Czj-0000a3-00; Sat, 11 Oct 2003 02:12:51 -0400 Received: from as13-3-2.rny.s.bonet.se ([217.215.166.49] helo=klapautius.it.su.se) by ietf-mx with esmtp (Exim 4.12) id 1A8Czi-0000Zw-00; Sat, 11 Oct 2003 02:12:50 -0400 Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h9B6Cbd23325; Sat, 11 Oct 2003 08:12:40 +0200 Message-ID: <3F879F55.6070009@it.su.se> Date: Sat, 11 Oct 2003 08:12:37 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Fred Baker CC: IETF IPv6 Working Group , The Internet Engineering Task Force , The Internet Engineering Steering Group , The Internet Architecture Board Subject: Re: Appeal to the IAB on the site-local issue References: <3F86FFD5.4050706@nttmcl.com> <3F87250F.7050700@it.su.se> <6.0.0.22.2.20031010143040.04624358@mira-sjc5-b.cisco.com> In-Reply-To: <6.0.0.22.2.20031010143040.04624358@mira-sjc5-b.cisco.com> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 | You know, I'd like to see a little more respect for people, and for the | reports they make. Yes, it would be much better if operational staff | from each of the Fortune 500 companies and larger tertiary operators | came to the IETF and spoke for themselves. They don't, and that doesn't | make their opinions or requirements irrelevant. I do (sort of) apologize for the tone of my email but I simply don't understand how the debate in the IETF will survive the trend to replace technical argument with "My Fortune 500 customers tell me foo and thus foo it must be.". Please tell me how that is fundamentally different from voting based on (in some way) market share. Don't take me wrong, I am not an air-headed academic who fails to understand the importance of beeing able to sell the solutions to people who are willing to pay for them. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/h59V8Jx8FtbMZncRAscCAKCDb6j3shAQ5ImB1Z0P/j9X75sBMgCgq1iG k3AN8B/NTdZuE4Vtn8wrdG0= =NsYR -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Oct 11 02:45:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23329 for ; Sat, 11 Oct 2003 02:45:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8DV5-0003lk-Gg for ipv6-archive@odin.ietf.org; Sat, 11 Oct 2003 02:45:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9B6jF8q014489 for ipv6-archive@odin.ietf.org; Sat, 11 Oct 2003 02:45:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8DV4-0003lb-Of for ipv6-web-archive@optimus.ietf.org; Sat, 11 Oct 2003 02:45:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23308 for ; Sat, 11 Oct 2003 02:45:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8DV0-00011k-00 for ipv6-web-archive@ietf.org; Sat, 11 Oct 2003 02:45:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8DV0-00011h-00 for ipv6-web-archive@ietf.org; Sat, 11 Oct 2003 02:45:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8DUu-0003g1-PK; Sat, 11 Oct 2003 02:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8DU7-0003eM-08 for ipv6@optimus.ietf.org; Sat, 11 Oct 2003 02:44:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23298; Sat, 11 Oct 2003 02:44:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8DU2-00011X-00; Sat, 11 Oct 2003 02:44:10 -0400 Received: from as13-3-2.rny.s.bonet.se ([217.215.166.49] helo=klapautius.it.su.se) by ietf-mx with esmtp (Exim 4.12) id 1A8DU1-00011U-00; Sat, 11 Oct 2003 02:44:09 -0400 Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h9B6hvd23366; Sat, 11 Oct 2003 08:43:58 +0200 Message-ID: <3F87A6AD.7020308@it.su.se> Date: Sat, 11 Oct 2003 08:43:57 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Leif Johansson CC: Fred Baker , IETF IPv6 Working Group , The Internet Engineering Task Force , The Internet Engineering Steering Group , The Internet Architecture Board Subject: Re: Appeal to the IAB on the site-local issue References: <3F86FFD5.4050706@nttmcl.com> <3F87250F.7050700@it.su.se> <6.0.0.22.2.20031010143040.04624358@mira-sjc5-b.cisco.com> <3F879F55.6070009@it.su.se> In-Reply-To: <3F879F55.6070009@it.su.se> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 | | Don't take me wrong, I am not an air-headed academic who fails to | understand the importance of beeing able to sell the solutions to | people who are willing to pay for them. Just to be very clear on this: I don't believe I have seen anyone in the SL debate who presented an 'academic' argument without insight into the commercial realities facing vendors. Even the most die-hard opponents of SL I believe understand this. The failure to accept the Furtune-500 argument is not the same as not understanding it. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/h6at8Jx8FtbMZncRAqftAJ930kLekkwbg1LzbQJwnkCJdOZXsQCgg2ou PNGLq07cMTfH94OX8cEJ44M= =v36K -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Oct 11 02:48:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23441 for ; Sat, 11 Oct 2003 02:48:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8DXu-0004IY-5j for ipv6-archive@odin.ietf.org; Sat, 11 Oct 2003 02:48:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9B6mAZt016519 for ipv6-archive@odin.ietf.org; Sat, 11 Oct 2003 02:48:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8DXt-0004IM-Ov for ipv6-web-archive@optimus.ietf.org; Sat, 11 Oct 2003 02:48:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23401 for ; Sat, 11 Oct 2003 02:47:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8DXp-00013o-00 for ipv6-web-archive@ietf.org; Sat, 11 Oct 2003 02:48:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8DXp-00013l-00 for ipv6-web-archive@ietf.org; Sat, 11 Oct 2003 02:48:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8DXn-00048K-3b; Sat, 11 Oct 2003 02:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8DX3-00044C-AO for ipv6@optimus.ietf.org; Sat, 11 Oct 2003 02:47:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23390; Sat, 11 Oct 2003 02:47:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8DWz-00013Q-00; Sat, 11 Oct 2003 02:47:13 -0400 Received: from as13-3-2.rny.s.bonet.se ([217.215.166.49] helo=klapautius.it.su.se) by ietf-mx with esmtp (Exim 4.12) id 1A8DWy-00013N-00; Sat, 11 Oct 2003 02:47:12 -0400 Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h9B6k4d23374; Sat, 11 Oct 2003 08:46:06 +0200 Message-ID: <3F87A72C.5050700@it.su.se> Date: Sat, 11 Oct 2003 08:46:04 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Valdis.Kletnieks@vt.edu, iab@iab.org, iesg@ietf.org, ietf@ietf.org, ipv6@ietf.org Subject: Re: Removing features References: In-Reply-To: X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Iljitsch van Beijnum wrote: | | This is based on the assumption that leaking RFC 1918 routing | information or packets with RFC 1918 source or destination addresses is | actually harmful in and of itself. This is a broken assumption. If Tell that to the root zone operators and brace for the reaction. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/h6cs8Jx8FtbMZncRAunXAJ9zQz+YXtdH6kjZy5BZL5CCYxU/JwCcCYjn BD6+OpZS7L5Itcg1WfoPzGg= =BRx5 -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Oct 11 07:11:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29317 for ; Sat, 11 Oct 2003 07:11:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Hes-0000Tf-Cm for ipv6-archive@odin.ietf.org; Sat, 11 Oct 2003 07:11:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9BBBcgZ001829 for ipv6-archive@odin.ietf.org; Sat, 11 Oct 2003 07:11:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Hes-0000TQ-81 for ipv6-web-archive@optimus.ietf.org; Sat, 11 Oct 2003 07:11:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29262 for ; Sat, 11 Oct 2003 07:11:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8Hen-0003Kr-00 for ipv6-web-archive@ietf.org; Sat, 11 Oct 2003 07:11:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8Hen-0003Ko-00 for ipv6-web-archive@ietf.org; Sat, 11 Oct 2003 07:11:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8HeI-0000Gy-EG; Sat, 11 Oct 2003 07:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Hdz-0000Ga-QR for ipv6@optimus.ietf.org; Sat, 11 Oct 2003 07:10:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29247 for ; Sat, 11 Oct 2003 07:10:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8Hdv-0003Kf-00 for ipv6@ietf.org; Sat, 11 Oct 2003 07:10:39 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1A8Hdu-0003Kc-00 for ipv6@ietf.org; Sat, 11 Oct 2003 07:10:38 -0400 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9BBAeed021592; Sat, 11 Oct 2003 13:10:40 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 11 Oct 2003 13:10:37 +0200 Subject: Re: Removing features Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ipv6@ietf.org To: Valdis.Kletnieks@vt.edu From: Iljitsch van Beijnum In-Reply-To: <200310102312.h9ANCtRX009416@turing-police.cc.vt.edu> Message-Id: <8AF41655-FBDB-11D7-B291-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On zaterdag, okt 11, 2003, at 01:12 Europe/Amsterdam, Valdis.Kletnieks@vt.edu wrote: > The problem is that usually, the offending site isn't the one feeling > the pain. > We've been doing bogon filtering of 1918 addresses for a LONG time. > The *real* fun is collateral damage - we filter inbound 1918 source > addresses. A certain clueless Tier-1 numbers their point-to-points > out of 1918 space. If one of those links tosses an ICMP error, > it gets dropped at our border router. > Does wonders for PMTU discovery when the frag-needed packet gets > tossed. Wouldn't the people behind this setup feel the pain too? I must say giving a router that handles links with different MTU sizes RFC 1918 addresses is an interesting choice. But then path MTU discovery has been broken (by assuming packet too big messages would *always* be returned) for 10 years and only recently the IETF and implementers have been starting to do something about that. > How many sites have to Get It Wrong before 30% of all the packets seen > at the root nameservers are from 1918 space? Dunno. What kind of pathalogical setup makes this happen anyway? Running a resolving nameserver behind a broken NAT? But only a few of those will generate lots of queries as they never see any answers. >> Your argument is self-defeating. If we were to recycle FEC0::/10 this >> would be the 69.0.0.0/8 but ten times worse. Everybody knew that >> 69.0.0.0/8 would be assigned at some point, so the people filtering >> this range knew what they were doing (or at least, they should have). >> FEC0::/10 on the other hand has been in the specification as a fixed >> special purpose range for a lot of years, and presumably people have >> implemented their networks accordingly. Pulling the rug from under >> them >> by removing this address range from the spefication and (at least >> theoretically) allowing it to be reassigned for a different purpose is >> insane. > Agreed. On the other hand, if we don't, we're stuck looking at > having inbound FEC0::/10 packets for eternity. I doubt that FEC0::/10 will be as prevalent as RFC 1918. But if you absolutely don't want to see them, you probably need to filter them for eternity, yes. > Well.. OK... *disconnected* networks, I can see the point. > Unfortunately, > unless you make a rule that an IPv6 host will categorically refuse to > accept traffic to/from a FEC0::/10 host if it knows *ANY* other > non-link-local > prefixes, it will end up leaking. Yes, that means if you connect and > learn > other prefixes, you need to renumber the site-locals. It also means > that > if you have a router talking to the outside world, you aren't allowed > to do > NAT-style games - the router has to pretend your FEC0:/10 hosts don't > exist. Yes, all of this is very problematic. What we really need is provider independent address space that is globally usable. If we can't make this happen I'm sure IPv6 will end up with much of the IPv4 unpleasantness, such as two-faced DNS if not full-out NAT. >>> >> Huh? > RFC2440 - OpenPGP Message Format. J. Callas, L. Donnerhacke, H. > Finney, R. > Thayer. November 1998. (Format: TXT=141371 bytes) (Status: > PROPOSED > STANDARD) But why bother signing your messages? We're discussing based on arguments here, it doesn't matter who makes them... -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Oct 12 00:04:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23789 for ; Sun, 12 Oct 2003 00:04:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8XT0-0003wd-Tu for ipv6-archive@odin.ietf.org; Sun, 12 Oct 2003 00:04:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9C44Q6D015164 for ipv6-archive@odin.ietf.org; Sun, 12 Oct 2003 00:04:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8XT0-0003wV-NJ for ipv6-web-archive@optimus.ietf.org; Sun, 12 Oct 2003 00:04:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23758 for ; Sun, 12 Oct 2003 00:04:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8XSy-0003Og-00 for ipv6-web-archive@ietf.org; Sun, 12 Oct 2003 00:04:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8XSy-0003Oc-00 for ipv6-web-archive@ietf.org; Sun, 12 Oct 2003 00:04:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8XRe-0003p4-47; Sun, 12 Oct 2003 00:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8XQh-0003nP-Ue for ipv6@optimus.ietf.org; Sun, 12 Oct 2003 00:02:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23688 for ; Sun, 12 Oct 2003 00:01:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8XQf-0003N1-00 for ipv6@ietf.org; Sun, 12 Oct 2003 00:02:01 -0400 Received: from dsl092-066-068.bos1.dsl.speakeasy.net ([66.92.66.68] helo=cyteen.hactrn.net) by ietf-mx with esmtp (Exim 4.12) id 1A8XQe-0003Jy-00 for ipv6@ietf.org; Sun, 12 Oct 2003 00:02:00 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 131BC3B7 for ; Sun, 12 Oct 2003 00:00:27 -0400 (EDT) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 12 Oct 2003 00:00:27 -0400 Message-Id: <20031012040027.131BC3B7@cyteen.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Messages | Bytes | Who --------+------+--------+----------+------------------------ 7.27% | 4 | 10.31% | 29369 | margaret.wasserman@nokia.com 9.09% | 5 | 8.08% | 23026 | moore@cs.utk.edu 9.09% | 5 | 6.95% | 19787 | leifj@it.su.se 9.09% | 5 | 5.86% | 16707 | michel@arneill-py.sacramento.ca.us 7.27% | 4 | 7.38% | 21034 | fred@cisco.com 5.45% | 3 | 7.94% | 22624 | alh-ietf@tndh.net 5.45% | 3 | 5.60% | 15952 | iljitsch@muada.com 3.64% | 2 | 6.77% | 19283 | john.loughney@nokia.com 3.64% | 2 | 5.09% | 14489 | samita.chakrabarti@eng.sun.com 3.64% | 2 | 4.05% | 11547 | valdis.kletnieks@vt.edu 3.64% | 2 | 3.12% | 8887 | brian@innovationslab.net 3.64% | 2 | 3.08% | 8778 | sob@harvard.edu 3.64% | 2 | 2.49% | 7103 | sra+ipng@hactrn.net 3.64% | 2 | 2.41% | 6852 | hinden@iprg.nokia.com 1.82% | 1 | 3.93% | 11210 | narten@us.ibm.com 1.82% | 1 | 2.44% | 6945 | chirayu@chirayu.org 1.82% | 1 | 1.72% | 4906 | internet-drafts@ietf.org 1.82% | 1 | 1.67% | 4744 | spencer@mcsr-labs.org 1.82% | 1 | 1.60% | 4568 | lear@cisco.com 1.82% | 1 | 1.54% | 4390 | huitema@windows.microsoft.com 1.82% | 1 | 1.49% | 4256 | gene@nttmcl.com 1.82% | 1 | 1.44% | 4094 | harald@alvestrand.no 1.82% | 1 | 1.38% | 3942 | stephen@sprunk.org 1.82% | 1 | 1.34% | 3819 | pekka.nikander@nomadiclab.com 1.82% | 1 | 1.17% | 3335 | bmanning@isi.edu 1.82% | 1 | 1.14% | 3249 | ericlklein@softhome.net --------+------+--------+----------+------------------------ 100.00% | 55 |100.00% | 284896 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 13 06:10:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28987 for ; Mon, 13 Oct 2003 06:10:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8zeV-00011Q-D5 for ipv6-archive@odin.ietf.org; Mon, 13 Oct 2003 06:10:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DAABoL003922 for ipv6-archive@odin.ietf.org; Mon, 13 Oct 2003 06:10:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8zeV-000115-4I for ipv6-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 06:10:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28947 for ; Mon, 13 Oct 2003 06:10:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8zeR-00016N-00 for ipv6-web-archive@ietf.org; Mon, 13 Oct 2003 06:10:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8zeQ-00016F-00 for ipv6-web-archive@ietf.org; Mon, 13 Oct 2003 06:10:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8zdO-0000tc-9G; Mon, 13 Oct 2003 06:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8zdJ-0000t4-UA for ipv6@optimus.ietf.org; Mon, 13 Oct 2003 06:08:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28899; Mon, 13 Oct 2003 06:08:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8zdF-00015U-00; Mon, 13 Oct 2003 06:08:53 -0400 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1A8zdE-00015H-00; Mon, 13 Oct 2003 06:08:52 -0400 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9DA8LNb112166; Mon, 13 Oct 2003 12:08:21 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9DA8EuB251724; Mon, 13 Oct 2003 12:08:15 +0200 Received: from zurich.ibm.com (sig-9-145-226-186.de.ibm.com [9.145.226.186]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA33196; Mon, 13 Oct 2003 12:08:12 +0200 Message-ID: <3F8A7972.AF55E365@zurich.ibm.com> Date: Mon, 13 Oct 2003 12:07:46 +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: ipv6@ietf.org CC: iab@iab.org, iesg@ietf.org, ietf@ietf.org Subject: Re: Removing features References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The word "deprecating" has a quite precise meaning in standards writing, which is not the same as "removing". Rather than debating this cross-posted on several lists, why don't people watch out for draft-ietf-ipv6-deprecate-site-local-01.txt which will appear in a few days, and see if they agree with the way it's written? And then debate it on the relevant list? Brian Margaret.Wasserman@nokia.com wrote: > > Hi Fred, > > > So in the general case I don't see a problem with deprecating > > things under the right circumstances, but I do have a problem with > > removing them outright. Deprecation doesn't prevent people from using > > them, but outright removal can be dangerous. And in this case, the > > assertion that one can still use the address prefix in a local manner > > is simply incorrect; it can be assigned at the whim of IANA, and > > network administrations need to plan accordingly. > > Actually, we are being very careful about this in the deprecation > of IPv6 site-local addressing. Christian Huitema and Brian Carpenter > have co-authored a very carefully written deprecation document that > makes it clear how these addresses should be treated to avoid problems > with existing site-local implementations. And, we are planning to > instruct IANA not to return these addresses to the regular allocation > pool. > > Margaret > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 13 06:27:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29344 for ; Mon, 13 Oct 2003 06:27:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8zv1-0001kQ-Q8 for ipv6-archive@odin.ietf.org; Mon, 13 Oct 2003 06:27:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DARF1j006712 for ipv6-archive@odin.ietf.org; Mon, 13 Oct 2003 06:27:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8zv1-0001kB-LK for ipv6-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 06:27:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29300 for ; Mon, 13 Oct 2003 06:27:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8zux-0001ER-00 for ipv6-web-archive@ietf.org; Mon, 13 Oct 2003 06:27:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8zux-0001EO-00 for ipv6-web-archive@ietf.org; Mon, 13 Oct 2003 06:27:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8zuo-0001f5-1S; Mon, 13 Oct 2003 06:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8zuL-0001dg-0D for ipv6@optimus.ietf.org; Mon, 13 Oct 2003 06:26:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29260; Mon, 13 Oct 2003 06:26:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8zuG-0001Dq-00; Mon, 13 Oct 2003 06:26:28 -0400 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1A8zuA-0001DW-00; Mon, 13 Oct 2003 06:26:27 -0400 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9DAP7Nb012936; Mon, 13 Oct 2003 12:25:22 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9DAOlA2080264; Mon, 13 Oct 2003 12:24:47 +0200 Received: from zurich.ibm.com (sig-9-145-226-186.de.ibm.com [9.145.226.186]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA35940; Mon, 13 Oct 2003 12:24:45 +0200 Message-ID: <3F8A7D53.8BA9138F@zurich.ibm.com> Date: Mon, 13 Oct 2003 12:24:19 +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: The Internet Architecture Board CC: Tony Hain , IETF IPv6 Working Group , The Internet Engineering Task Force , The Internet Engineering Steering Group Subject: Re: Appeal to the IAB on the site-local issue References: <3F86FFD5.4050706@nttmcl.com> <3F87250F.7050700@it.su.se> <011f01c38f6c$99c12dc0$6401a8c0@ssprunk> <3F871946.400@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I believe that the best outcome for the IETF, and for its constituency, including enterprise network operators, is for the IPv6 WG to get on with what it's doing (documenting the deprecation of site-local, and developing alternatives). I believe the worst outcome for the IETF would be to waste the time of busy people (and I'm sadly aware that this message will go to several thousand people) over a consensus call that was not even about a document but just a decision in principle. Personally I see no abuse of process in either the face to face consensus call or the subsequent email poll; the fact that the questions asked had some degree of ambiguity is simply a result of the complexity involved. I recommend that the IAB deals with this appeal as quickly as possible, and avoids future time wasting by constructing a response that makes further appeals on the same topic pointless. Personally, this is my last message on this thread and I won't be reading it again either. I have work to do. Brian Eliot Lear wrote: > > Stephen Sprunk wrote: > > Or we all just got sick of the bickering and accepted defeat (unlike Tony). > > > > For the record, I can't support deprecating site locals until we have > > something else approved to replace them -- at which point I say good > > riddance. There are several drafts in the WG to that end which haven't > > gained any momentum thus far. > > And this is why the appeal is in my opinion untimely. The working group > has not yet been given a chance to provide any documentation on that > "What next?" question Tony asked. For the IESG or the IAB to interfere > at this stage would be micromanagement. > > But here we are. Tony has decided to push an appeal of a "vote", and > not even one that generated a document. That the appeal has even gotten > this far seems is a flaw in the process. > > Had the IESG been able to disallow the appeal, simply on this basis, > then perhaps the working group could actually provide documents about > which we could argue over technical merit. As it stands, I predict yet > another round of appeals once IETF last call closes, and the document is > reviewed by the IESG. > > Welcome to Court TV, IETF style. > > Eliot > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 13 09:48:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04830 for ; Mon, 13 Oct 2003 09:48:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A933I-00026x-3n for ipv6-archive@odin.ietf.org; Mon, 13 Oct 2003 09:48:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DDm0Va008109 for ipv6-archive@odin.ietf.org; Mon, 13 Oct 2003 09:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A933H-00026i-U4 for ipv6-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 09:47:59 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04779 for ; Mon, 13 Oct 2003 09:47:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A931O-0001h0-CU; Mon, 13 Oct 2003 09:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A931K-0001eA-6r for ipv6@optimus.ietf.org; Mon, 13 Oct 2003 09:45:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04669 for ; Mon, 13 Oct 2003 09:45:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A931I-0002l6-00 for ipv6@ietf.org; Mon, 13 Oct 2003 09:45:56 -0400 Received: from smtp01.uc3m.es ([163.117.136.121] helo=smtp.uc3m.es) by ietf-mx with esmtp (Exim 4.12) id 1A931G-0002kk-00 for ipv6@ietf.org; Mon, 13 Oct 2003 09:45:54 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 3BA9743261; Mon, 13 Oct 2003 15:45:23 +0200 (CEST) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp01.uc3m.es (Postfix) with ESMTP id EC71C99ECC; Mon, 13 Oct 2003 15:45:20 +0200 (CEST) From: Juan Rodriguez Hervella Organization: UC3M To: Leif Johansson , Iljitsch van Beijnum Subject: Re: Removing features Date: Mon, 13 Oct 2003 15:45:15 +0200 User-Agent: KMail/1.5 Cc: ipv6@ietf.org References: <3F87A72C.5050700@it.su.se> In-Reply-To: <3F87A72C.5050700@it.su.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310131545.20345.jrh@it.uc3m.es> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Saturday 11 October 2003 08:46, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Iljitsch van Beijnum wrote: > > > | This is based on the assumption that leaking RFC 1918 routing > | information or packets with RFC 1918 source or destination addresses is > | actually harmful in and of itself. This is a broken assumption. If > > Tell that to the root zone operators and brace for the reaction. > Hello Leif, Do you know what are the problems that *root zone operators* are experiencing with RFC 1918 addresses ? It would be very interesting if you could explain (to me) some of these issues... I don't see why this kind of addresses could be a problem, as long as they don't use them.... -- JFRH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 13 10:05:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05814 for ; Mon, 13 Oct 2003 10:05:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A93Jf-000354-J4 for ipv6-archive@odin.ietf.org; Mon, 13 Oct 2003 10:04:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DE4tgb011841 for ipv6-archive@odin.ietf.org; Mon, 13 Oct 2003 10:04:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A93Jf-00034t-DI for ipv6-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 10:04:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05720 for ; Mon, 13 Oct 2003 10:04:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A93Jd-0002zn-00 for ipv6-web-archive@ietf.org; Mon, 13 Oct 2003 10:04:53 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A93Jc-0002zi-00 for ipv6-web-archive@ietf.org; Mon, 13 Oct 2003 10:04:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A93In-0002kA-Gh; Mon, 13 Oct 2003 10:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A93IL-0002jY-JN for ipv6@optimus.ietf.org; Mon, 13 Oct 2003 10:03:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05490 for ; Mon, 13 Oct 2003 10:03:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A93IJ-0002ym-00 for ipv6@ietf.org; Mon, 13 Oct 2003 10:03:31 -0400 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1A93II-0002yj-00 for ipv6@ietf.org; Mon, 13 Oct 2003 10:03:30 -0400 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 690A6830F; Mon, 13 Oct 2003 16:03:14 +0200 (CEST) From: "Jeroen Massar" To: "'Juan Rodriguez Hervella'" , "'Leif Johansson'" , "'Iljitsch van Beijnum'" Cc: Subject: RE: Removing features Date: Mon, 13 Oct 2003 16:01:41 +0200 Organization: Unfix Message-ID: <000801c39192$880b23b0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <200310131545.20345.jrh@it.uc3m.es> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Juan Rodriguez Hervella wrote: > On Saturday 11 October 2003 08:46, Leif Johansson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Iljitsch van Beijnum wrote: > > > > > > | This is based on the assumption that leaking RFC 1918 routing > > | information or packets with RFC 1918 source or=20 > destination addresses is > > | actually harmful in and of itself. This is a broken assumption. If > > > > Tell that to the root zone operators and brace for the reaction. > > >=20 > Hello Leif, >=20 > Do you know what are the problems that *root zone operators* are=20 > experiencing with RFC 1918 addresses ? It would be very interesting > if you could explain (to me) some of these issues... I don't see why > this kind of addresses could be a problem, as long as they > don't use them.... You might want to read http://www.as112.net/ Quote: "Because most answers generated by the Internet's root name = server system are negative, and many of those negative answers are in = response to PTR queries for RFC1918 and other ambiguous addresses" And that is only queries, you don't want to know how many RFC1918 sourced addresses they are dropping, can't send an icmp back now can you = :) Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP4qwRSmqKFIzPnwjEQIE0ACfcrujaQk7SyBxV2fzsTS7i2gDyZ4An0DE W9rVGRsLWATtHaVMhbhlpLAz =3Du790 -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 13 12:10:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13120 for ; Mon, 13 Oct 2003 12:10:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95GP-0001gs-Ta for ipv6-archive@odin.ietf.org; Mon, 13 Oct 2003 12:09:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DG9f58006492 for ipv6-archive@odin.ietf.org; Mon, 13 Oct 2003 12:09:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95GP-0001gd-Kv for ipv6-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 12:09:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12991 for ; Mon, 13 Oct 2003 12:09:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A95GO-0004q5-00 for ipv6-web-archive@ietf.org; Mon, 13 Oct 2003 12:09:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A95GN-0004q2-00 for ipv6-web-archive@ietf.org; Mon, 13 Oct 2003 12:09:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95Eq-0001JB-2R; Mon, 13 Oct 2003 12:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95EU-0001E5-UK for ipv6@optimus.ietf.org; Mon, 13 Oct 2003 12:07:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12866 for ; Mon, 13 Oct 2003 12:07:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A95ET-0004nh-00 for ipv6@ietf.org; Mon, 13 Oct 2003 12:07:41 -0400 Received: from bardisk.pilsnet.sunet.se ([192.36.125.26]) by ietf-mx with esmtp (Exim 4.12) id 1A95ES-0004nX-00 for ipv6@ietf.org; Mon, 13 Oct 2003 12:07:40 -0400 Received: from bardisk.pilsnet.sunet.se (localhost [IPv6:::1]) by bardisk.pilsnet.sunet.se (8.12.9p2/8.12.8) with ESMTP id h9DG7823045104 for ; Mon, 13 Oct 2003 18:07:08 +0200 (CEST) (envelope-from mansaxel@bardisk.pilsnet.sunet.se) Received: (from mansaxel@localhost) by bardisk.pilsnet.sunet.se (8.12.9p2/8.12.3/Submit) id h9DG781q045103 for ipv6@ietf.org; Mon, 13 Oct 2003 18:07:08 +0200 (CEST) Date: Mon, 13 Oct 2003 18:07:08 +0200 From: Mans Nilsson To: ipv6@ietf.org Subject: Re: Removing features Message-ID: <20031013160708.GC42400@sunet.se> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XMCwj5IQnwKtuyBG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-synced-from: Pilsnet Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --XMCwj5IQnwKtuyBG Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: RE: Removing features Date: Fri, Oct 10, 2003 at 11:59:24PM -0700 = Quoting Michel Py (michel@arneill-py.sacramento.ca.us): > Root zone operators, meaning like Verisign? Yes. They, in the part of their operation that runs root servers, feel the pain of leakage, as does USC-ISI, Cogent, UMD, NASA-ARC, ISC, DOD-NIC, ARL, Autonomica, RIPE, ICANN and WIDE. There is no reason to mix up the root server ops with the anycast debacle.= =20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE Am I elected yet? --XMCwj5IQnwKtuyBG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/is2s02/pMZDM1cURAsh/AJ9dbHa8E4oFbcs++A1ilvAjO6GPXwCdF68a R1IDm3ZvwJ7lAhqr8vfwIe4= =FIM6 -----END PGP SIGNATURE----- --XMCwj5IQnwKtuyBG-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 13 12:15:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13518 for ; Mon, 13 Oct 2003 12:15:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95LS-00029y-Cd for ipv6-archive@odin.ietf.org; Mon, 13 Oct 2003 12:14:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DGEsfj008298 for ipv6-archive@odin.ietf.org; Mon, 13 Oct 2003 12:14:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95LS-00029l-6o for ipv6-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 12:14:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13453 for ; Mon, 13 Oct 2003 12:14:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A95LQ-0004vc-00 for ipv6-web-archive@ietf.org; Mon, 13 Oct 2003 12:14:52 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A95LQ-0004vZ-00 for ipv6-web-archive@ietf.org; Mon, 13 Oct 2003 12:14:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95Kd-0001oY-40; Mon, 13 Oct 2003 12:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95KI-0001ly-1j for ipv6@optimus.ietf.org; Mon, 13 Oct 2003 12:13:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13337 for ; Mon, 13 Oct 2003 12:13:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A95KG-0004tC-00 for ipv6@ietf.org; Mon, 13 Oct 2003 12:13:40 -0400 Received: from bardisk.pilsnet.sunet.se ([192.36.125.26]) by ietf-mx with esmtp (Exim 4.12) id 1A95KG-0004sS-00 for ipv6@ietf.org; Mon, 13 Oct 2003 12:13:40 -0400 Received: from bardisk.pilsnet.sunet.se (localhost [IPv6:::1]) by bardisk.pilsnet.sunet.se (8.12.9p2/8.12.8) with ESMTP id h9DGD923045504 for ; Mon, 13 Oct 2003 18:13:09 +0200 (CEST) (envelope-from mansaxel@bardisk.pilsnet.sunet.se) Received: (from mansaxel@localhost) by bardisk.pilsnet.sunet.se (8.12.9p2/8.12.3/Submit) id h9DGD9HI045503 for ipv6@ietf.org; Mon, 13 Oct 2003 18:13:09 +0200 (CEST) Date: Mon, 13 Oct 2003 18:13:09 +0200 From: Mans Nilsson To: ipv6@ietf.org Subject: Re: Removing features Message-ID: <20031013161309.GE42400@sunet.se> References: <20031013160708.GC42400@sunet.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="maH1Gajj2nflutpK" Content-Disposition: inline In-Reply-To: <20031013160708.GC42400@sunet.se> User-Agent: Mutt/1.4.1i X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-synced-from: Pilsnet Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --maH1Gajj2nflutpK Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: Removing features Date: Mon, Oct 13, 2003 at 06:07:08PM +0200 = Quoting Mans Nilsson (mansaxel@sunet.se): > There is no reason to mix up the root server ops with the anycast debacle= .=20 I was not thinking! Substitute "anycast" with "wildcard" on the above line.= =20 Sorry!=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE Yow! I want my nose in lights! --maH1Gajj2nflutpK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/is8V02/pMZDM1cURAr2lAJ9g/tZdHHIqYxhGzDrH8QIED6mhTACfV3Mz 9NT6oX91Ron1Lj4xvJEwRyA= =UBWI -----END PGP SIGNATURE----- --maH1Gajj2nflutpK-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 13 15:59:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24407 for ; Mon, 13 Oct 2003 15:59:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A98qJ-0005oN-3y for ipv6-archive@odin.ietf.org; Mon, 13 Oct 2003 15:58:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DJwxth022333 for ipv6-archive@odin.ietf.org; Mon, 13 Oct 2003 15:58:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A98qI-0005o8-U3 for ipv6-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 15:58:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24317 for ; Mon, 13 Oct 2003 15:58:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A98qH-0007dD-00 for ipv6-web-archive@ietf.org; Mon, 13 Oct 2003 15:58:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A98qG-0007dA-00 for ipv6-web-archive@ietf.org; Mon, 13 Oct 2003 15:58:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A98oP-00050e-IE; Mon, 13 Oct 2003 15:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A98o4-0004zi-9v for ipv6@optimus.ietf.org; Mon, 13 Oct 2003 15:56:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24005; Mon, 13 Oct 2003 15:56:31 -0400 (EDT) Message-Id: <200310131956.PAA24005@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-deprecate-site-local-01.txt Date: Mon, 13 Oct 2003 15:56:30 -0400 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --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 : Deprecating Site Local Addresses Author(s) : C. Huitema, B. Carpenter Filename : draft-ietf-ipv6-deprecate-site-local-01.txt Pages : 10 Date : 2003-10-13 This document describes the issues surrounding the use of IPv6 site- local unicast addresses in their original form, and formally deprecates them. This deprecation does not prevent their continued use until a replacement has been standardized and implemented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-site-local-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-deprecate-site-local-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-deprecate-site-local-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-13145711.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-deprecate-site-local-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-deprecate-site-local-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-13145711.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 13 23:36:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11732 for ; Mon, 13 Oct 2003 23:36:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Fyo-0000i3-7O for ipv6-archive@odin.ietf.org; Mon, 13 Oct 2003 23:36:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9E3aEjs002727 for ipv6-archive@odin.ietf.org; Mon, 13 Oct 2003 23:36:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Fyn-0000hu-WF for ipv6-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 23:36:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11705 for ; Mon, 13 Oct 2003 23:36:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Fyl-0005HJ-00 for ipv6-web-archive@ietf.org; Mon, 13 Oct 2003 23:36:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9Fyl-0005HG-00 for ipv6-web-archive@ietf.org; Mon, 13 Oct 2003 23:36:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Fxf-0000XC-Rv; Mon, 13 Oct 2003 23:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Fwt-0000Vw-Bx for ipv6@optimus.ietf.org; Mon, 13 Oct 2003 23:34:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11657; Mon, 13 Oct 2003 23:34:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Fwq-0005G3-00; Mon, 13 Oct 2003 23:34:12 -0400 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx with esmtp (Exim 4.12) id 1A9Fwo-0005Ft-00; Mon, 13 Oct 2003 23:34:11 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 1D073BAD1; Mon, 13 Oct 2003 23:33:49 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Oct 2003 23:33:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Appeal to the IAB on the site-local issue Date: Mon, 13 Oct 2003 23:33:48 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA107@tayexc13.americas.cpqcorp.net> Thread-Topic: Appeal to the IAB on the site-local issue Thread-Index: AcOPSaYyBNicFkTzQ+yTuDCkgopc2QCtlkBA From: "Bound, Jim" To: "Scott Bradner" , Cc: , , X-OriginalArrivalTime: 14 Oct 2003 03:33:48.0745 (UTC) FILETIME=[FAD6E390:01C39203] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Scott, I agree with your caution about "removal" 100% and that it requires a much stronger consenus and test to execute removal, and do not want it done in anyway but from a serious analysis of those consequences. I also agree the issue has nothing to do with which side of the fence one sits on the issue. It is a process issue and removal is a very serious decision. But I read all the discussions that lead up to the March 2003 meeting, and was in that March 2003 meeting. It was one of the strongest consensus moments I have seen that happened that day in that room in that working group and was IMO over 3/4 of the attendees. And then the follow up email to the meeting did not overturn that consenus or the view of the Chairs, ADs, and no one jumped over the fence, who supported the decision to my knowledge. Hence, I agree with the bar you articulate for this case, but I for one truly believe the IETF process was met to proceed with the recommendation of the Chairs on this issue and is supported by strong cosensus of the IETF direct participants. Also the draft below URL provides a good initial discussion and framework of the issue and also a means to reduce any pain caused by this removal. It is not my endorsement of the draft at this time as a qualification. http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-site-local -01.txt Other questions not related to this specific issue you articulated so well are as follows for the future as input to you who knows far more about this than I and I realize that completely: 1. Why did the WG agree to this consensus? An important question? I will not comment on this in public. 2. Did the implementors who agreed understand the ramifications to code base and were they participants? The answer is yes. 3. Were the needs of the market considered in the decision? I don't think by all but do we ever use this bar? As I said to you once when you were on the IESG consistency is imperative. The market is reprsented by our participants. If participants are not here to support the IETF they do not get heard. We have no way to trust one or a few to represent an entire market other than present their individual view. That may or may not influence the WG, it depends on the respect the individual has with their peers I guess? I will stop there. Thanks for doing this and documenting the importance of "removal" publicly it is a very important understanding we must know well before we ever do removals. I do "feel" we had consenus as a note. /jim ************************************** "if it looks good, you'll see it; if it sounds good, you'll hear it, if it's marketed right, you'll buy it; but...if it's real, you'll feel it." Kid Rock ************************************** > -----Original Message----- > From: Scott Bradner [mailto:sob@harvard.edu]=20 > Sent: Friday, October 10, 2003 10:17 AM > To: iab@iab.org > Cc: iesg@ietf.org; ietf@ietf.org; ipv6@ietf.org > Subject: re: Appeal to the IAB on the site-local issue >=20 >=20 > IAB, >=20 > Please consider this input for the IAB discussion on Tony's=20 > appeal of the site local decision. This should not be=20 > considered a separate appeal. (Which I would think would have=20 > to start at the beginning with the working group chairs.) >=20 > I do not have an opinion on the particulars of Tony's appeal=20 > since I was not at the meeting in question and only followed=20 > the discussion on the mailing list. Nor is this an opinion=20 > based on the technical question under discussion. (Although=20 > I think some of the cures proposed to the site-local disease=20 > are quite a bit worse than the disease itself.) >=20 > I would like to reiterate the concern I expressed on the=20 > mailing list back in July - I think there may been a=20 > violation of the IETF consensus process=20 > in this case. >=20 > It is my opinion that there is a difference between a working=20 > group deciding to adopt a technology and a working group=20 > deciding to delete a technology from an existing IETF=20 > specification. It is my opinion that the second case should=20 > require a stronger demonstration of consensus to change since=20 > the decision effects existing implementations, documentation,=20 > text books etc. >=20 > But even without any need to show any extra level of=20 > consensus I did not see that even a minimal level of rough=20 > consensus was demonstrated to remove site local addresses. >=20 > The claim was made on the list that there was not consensus=20 > to keep site local addresses, I think that is the wrong=20 > question to ask - the proposal was to change a specification=20 > after its publication there should have been a rough=20 > consensus to remove the feature. >=20 > I did not see rough consensus to do so based on my monitoring=20 > the list. >=20 > Scott >=20 > (this is the letter I sent back in July on the topic) >=20 > From sob Mon Jul 28 15:11:01 2003 > To: Erik.Nordmark@Sun.COM > Subject: Re: state-of-art SLs > Cc: ipng@sunroof.eng.sun.com > In-Reply-To: >=20 >=20 > > The chairs have read all of the messages on the list, and based on=20 > > your considerable input, we have determined that the IPv6=20 > WG does have=20 > > rough consensus to deprecate the usage of IPv6 site-local unicast=20 > > addressing AND to investigate alternative mechanisms for local=20 > > addressing and local access > . control. >=20 > humm - it is not all that often that we have said that 2/3 is=20 > rough consensus in the IETF - in my exterience if 1/3 is not=20 > in support then I would not claim consensus (even 6 grit) -=20 > 3/4 would be very rough indeed, 5/6 would be the mininum I=20 > would say was "rough consensus" >=20 >=20 > just when does "rough consensus" faid out in this model? >=20 > Scott >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 14 03:45:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29080 for ; Tue, 14 Oct 2003 03:45:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9JrS-0004la-Bc for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 03:44:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9E7isQ5018320 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 03:44:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9JrR-0004lP-2m for ipv6-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 03:44:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29040 for ; Tue, 14 Oct 2003 03:44:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9JrO-0006yA-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 03:44:50 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9JrO-0006y7-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 03:44:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Jqc-0004en-1o; Tue, 14 Oct 2003 03:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Jq8-0004dc-3v for ipv6@optimus.ietf.org; Tue, 14 Oct 2003 03:43:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29020 for ; Tue, 14 Oct 2003 03:43:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Jq5-0006wz-00 for ipv6@ietf.org; Tue, 14 Oct 2003 03:43:29 -0400 Received: from smtp01.uc3m.es ([163.117.136.121] helo=smtp.uc3m.es) by ietf-mx with esmtp (Exim 4.12) id 1A9Jq4-0006wu-00 for ipv6@ietf.org; Tue, 14 Oct 2003 03:43:28 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 2139B4378B; Tue, 14 Oct 2003 09:37:59 +0200 (CEST) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp01.uc3m.es (Postfix) with ESMTP id 7FA8D99ED2; Tue, 14 Oct 2003 09:37:56 +0200 (CEST) From: Juan Rodriguez Hervella Organization: UC3M To: "Jeroen Massar" , "'Leif Johansson'" , "'Iljitsch van Beijnum'" Subject: Re: Removing features Date: Tue, 14 Oct 2003 09:37:37 +0200 User-Agent: KMail/1.5 Cc: References: <000801c39192$880b23b0$210d640a@unfix.org> In-Reply-To: <000801c39192$880b23b0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310140937.56128.jrh@it.uc3m.es> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Monday 13 October 2003 16:01, Jeroen Massar wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > Juan Rodriguez Hervella wrote: > > On Saturday 11 October 2003 08:46, Leif Johansson wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Iljitsch van Beijnum wrote: > > > > > > > > > | This is based on the assumption that leaking RFC 1918 routing > > > | information or packets with RFC 1918 source or > > > > destination addresses is > > > > > | actually harmful in and of itself. This is a broken assumption. If > > > > > > Tell that to the root zone operators and brace for the reaction. > > > > Hello Leif, > > > > Do you know what are the problems that *root zone operators* are > > experiencing with RFC 1918 addresses ? It would be very interesting > > if you could explain (to me) some of these issues... I don't see why > > this kind of addresses could be a problem, as long as they > > don't use them.... > > You might want to read http://www.as112.net/ > > Quote: "Because most answers generated by the Internet's root name server > system are negative, and many of those negative answers are in response to > PTR queries for RFC1918 and other ambiguous addresses" > > And that is only queries, you don't want to know how many RFC1918 > sourced addresses they are dropping, can't send an icmp back now can you :) I would have to read it again, but I think that ICMP error messages are sent with the source address of the output interface, so IMO it would be able to come back. Anyway, thank you very much for the info Jeroen ^--^ -- JFRH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 14 05:38:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01406 for ; Tue, 14 Oct 2003 05:38:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Lcw-0001mm-0z for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 05:38:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9E9c1oW006852 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 05:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Lcu-0001mB-RF for ipv6-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 05:38:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01375 for ; Tue, 14 Oct 2003 05:37:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Lcr-0007n9-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 05:37:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9Lcq-0007n6-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 05:37:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Lby-0001OD-Ea; Tue, 14 Oct 2003 05:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Lbr-0001NU-Dg for ipv6@optimus.ietf.org; Tue, 14 Oct 2003 05:36:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01348 for ; Tue, 14 Oct 2003 05:36:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Lbn-0007mp-00 for ipv6@ietf.org; Tue, 14 Oct 2003 05:36:51 -0400 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1A9Lbn-0007mm-00 for ipv6@ietf.org; Tue, 14 Oct 2003 05:36:51 -0400 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 2A42A830F; Tue, 14 Oct 2003 11:36:51 +0200 (CEST) From: "Jeroen Massar" To: "'Juan Rodriguez Hervella'" Cc: Subject: RE: Removing features Date: Tue, 14 Oct 2003 11:36:49 +0200 Organization: Unfix Message-ID: <00a101c39236$b1b4c7d0$210d640a@unfix.org> 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.4510 In-Reply-To: <200310140937.56128.jrh@it.uc3m.es> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Juan Rodriguez Hervella wrote: > > > Do you know what are the problems that *root zone operators* are > > > experiencing with RFC 1918 addresses ? It would be very interesting > > > if you could explain (to me) some of these issues... I don't see why > > > this kind of addresses could be a problem, as long as they > > > don't use them.... > > > > You might want to read http://www.as112.net/ > I would have to read it again, but I think that ICMP error > messages are sent with the source address of the output interface, so IMO > it would be able to come back. $stupiddevice --> non-filtering-ISP --> Transit --> Nameserver 192.168.0.1 x.x.x.x To which IP should the Nameserver, or for that matter anything filtering in between send the traffic? In the DFZ there is no route to 192.168.0.0/16, if there was is it is a still a bogon. AS112 concentrates on bogus queries from valid IP's though as the rootservers get queries for things like: 1.0.168.192.in-addr.arpa. PTR. Mind you if the ISP doesn't even filter RFC1918 space they are not filtering based on source address also. Thus that complete ISP is a perfect source for..... spoofed ddos'ses, now track those ;) ISP's should filter *any* source addresses that are not delegated to their clients, doing this more at the edge where the client connects to their network is a good thing. They should for stupidity's sake also only forward traffic that they know the destination is only at that client. Yes this breaks 'multihoming', but is that real multihoming? Not per my definition at least. uRPF etc come to mind also ofcourse. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP4vDpymqKFIzPnwjEQJ4+gCfav+ZRDKVvC75m21Y9ZUF+1YACbkAoJUI o7gclmYD8G7tWbqJ3n5mkm6O =gg+6 -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 14 06:01:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02099 for ; Tue, 14 Oct 2003 06:01:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Lzc-0002u8-Lb for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 06:01:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EA1SiM011164 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 06:01:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Lzc-0002tz-Gr for ipv6-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 06:01:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02059 for ; Tue, 14 Oct 2003 06:01:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9LzY-0000H0-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 06:01:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9LzY-0000Gx-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 06:01:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9LzC-0002ma-5f; Tue, 14 Oct 2003 06:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9LyY-0002lC-OQ for ipv6@optimus.ietf.org; Tue, 14 Oct 2003 06:00:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02019 for ; Tue, 14 Oct 2003 06:00:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9LyU-0000GE-00 for ipv6@ietf.org; Tue, 14 Oct 2003 06:00:18 -0400 Received: from smtp02.uc3m.es ([163.117.136.122] helo=smtp.uc3m.es) by ietf-mx with esmtp (Exim 4.12) id 1A9LyT-0000Fh-00 for ipv6@ietf.org; Tue, 14 Oct 2003 06:00:18 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 2EA4143136; Tue, 14 Oct 2003 11:59:48 +0200 (CEST) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp02.uc3m.es (Postfix) with ESMTP id E70E199FEA; Tue, 14 Oct 2003 11:59:47 +0200 (CEST) From: Juan Rodriguez Hervella Organization: UC3M To: "Jeroen Massar" Subject: Re: Removing features Date: Tue, 14 Oct 2003 11:59:44 +0200 User-Agent: KMail/1.5 Cc: References: <00a101c39236$b1b4c7d0$210d640a@unfix.org> In-Reply-To: <00a101c39236$b1b4c7d0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310141159.47559.jrh@it.uc3m.es> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tuesday 14 October 2003 11:36, Jeroen Massar wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > Juan Rodriguez Hervella wrote: > > > > > > > Do you know what are the problems that *root zone operators* are > > > > experiencing with RFC 1918 addresses ? It would be very interesting > > > > if you could explain (to me) some of these issues... I don't see why > > > > this kind of addresses could be a problem, as long as they > > > > don't use them.... > > > > > > You might want to read http://www.as112.net/ > > > > > I would have to read it again, but I think that ICMP error > > messages are sent with the source address of the output interface, so IMO > > it would be able to come back. > > $stupiddevice --> non-filtering-ISP --> Transit --> Nameserver > 192.168.0.1 x.x.x.x > > To which IP should the Nameserver, or for that matter anything > filtering in between send the traffic? In the DFZ there is no > route to 192.168.0.0/16, if there was is it is a still a bogon. > AS112 concentrates on bogus queries from valid IP's though as > the rootservers get queries for things like: 1.0.168.192.in-addr.arpa. PTR. > > Mind you if the ISP doesn't even filter RFC1918 space they are not > filtering based on source address also. Thus that complete ISP is > a perfect source for..... spoofed ddos'ses, now track those ;) > > ISP's should filter *any* source addresses that are not delegated > to their clients, doing this more at the edge where the client > connects to their network is a good thing. They should for > stupidity's sake also only forward traffic that they know the > destination is only at that client. Yes this breaks 'multihoming', > but is that real multihoming? Not per my definition at least. > uRPF etc come to mind also ofcourse. > > Greets, > Jeroen > > -----BEGIN PGP SIGNATURE----- > Version: Unfix PGP for Outlook Alpha 13 Int. > Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ > > iQA/AwUBP4vDpymqKFIzPnwjEQJ4+gCfav+ZRDKVvC75m21Y9ZUF+1YACbkAoJUI > o7gclmYD8G7tWbqJ3n5mkm6O > =gg+6 > -----END PGP SIGNATURE----- I agree with you Jeroen, I misunderstood the following phrase: > And that is only queries, you don't want to know how many RFC1918 > sourced addresses they are dropping, can't send an icmp back now can you :) I was thinking that you were talking about packets with "src=global dest=private", and I just wanted to note that ICMP error packets are sent with "src=, dest=global". I see private addressing is a really bad idea, and I quite agree with http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-site-local-01.txt See you and thanks again ! -- JFRH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 14 07:49:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04848 for ; Tue, 14 Oct 2003 07:49:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Nfd-0008LW-U0 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 07:48:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EBmvAb032081 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 07:48:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Nfd-0008LM-OR for ipv6-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 07:48:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04815 for ; Tue, 14 Oct 2003 07:48:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Nfc-0001FS-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 07:48:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9Nfc-0001FO-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 07:48:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Nej-0008FM-Ga; Tue, 14 Oct 2003 07:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Ndr-0008D4-8t for ipv6@optimus.ietf.org; Tue, 14 Oct 2003 07:47:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04772 for ; Tue, 14 Oct 2003 07:46:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Ndq-0001EM-00 for ipv6@ietf.org; Tue, 14 Oct 2003 07:47:06 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1A9Nde-0001EB-00 for ipv6@ietf.org; Tue, 14 Oct 2003 07:46:54 -0400 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9EBkled068728 for ; Tue, 14 Oct 2003 13:46:47 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 14 Oct 2003 13:46:46 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Raise the bar for v6? From: Iljitsch van Beijnum To: ipv6@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <16987DC7-FE3C-11D7-B291-00039388672E@muada.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We still don't have any IPv6 root nameservers. I gather one of the problems here is the limit on response message sizes for DNS queries. There are no doubt many other protocols that suffer from limitations in the original specs that are no longer relevant in today's implementations. I was thinking that it could make sense to retire some of these limitations in IPv6, even if they are not really IPv6-related. The rationale would be that a legacy application wouldn't normally be able to operate over IPv6 anyway, so raising the bar shouldn't lead to interoperability issues. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 14 08:13:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05655 for ; Tue, 14 Oct 2003 08:13:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9O3E-0001FF-CM for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 08:13:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ECDKap004661 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 08:13:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9O3D-0001Cx-LC for ipv6-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 08:13:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05619 for ; Tue, 14 Oct 2003 08:13:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9O3C-0001WV-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 08:13:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9O3C-0001WS-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 08:13:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9O2w-00015I-8O; Tue, 14 Oct 2003 08:13:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9O2F-00012M-1Z for ipv6@optimus.ietf.org; Tue, 14 Oct 2003 08:12:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05552 for ; Tue, 14 Oct 2003 08:12:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9O2E-0001Vq-00 for ipv6@ietf.org; Tue, 14 Oct 2003 08:12:18 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1A9O2D-0001Vn-00 for ipv6@ietf.org; Tue, 14 Oct 2003 08:12:17 -0400 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id h9ECC4v26222; Tue, 14 Oct 2003 05:12:04 -0700 (PDT) From: Bill Manning Message-Id: <200310141212.h9ECC4v26222@boreas.isi.edu> Subject: Re: Raise the bar for v6? In-Reply-To: <16987DC7-FE3C-11D7-B291-00039388672E@muada.com> from Iljitsch van Beijnum at "Oct 14, 3 01:46:46 pm" To: iljitsch@muada.com (Iljitsch van Beijnum) Date: Tue, 14 Oct 2003 05:12:04 -0700 (PDT) Cc: ipv6@ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit % We still don't have any IPv6 root nameservers. I gather one of the % problems here is the limit on response message sizes for DNS queries. No and Yes. There is an IPv6 native DNS system in place that supports the root zone and many TLDs. Its not the production DNS, but does meet the original design goal of best effort service. www.rs.net for details. the production DNS does have some limitations on response size and that is one of the impediments for getting native IPv6 on the production servers. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 14 08:49:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06801 for ; Tue, 14 Oct 2003 08:49:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ObW-00038x-MX for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 08:48:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ECmkcf012077 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 08:48:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ObW-00038i-BT for ipv6-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 08:48:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06767 for ; Tue, 14 Oct 2003 08:48:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9ObV-0001uo-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 08:48:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9ObU-0001ul-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 08:48:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Oao-0002yb-DK; Tue, 14 Oct 2003 08:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Oal-0002yC-20 for ipv6@optimus.ietf.org; Tue, 14 Oct 2003 08:47:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06716 for ; Tue, 14 Oct 2003 08:47:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Oaj-0001tq-00 for ipv6@ietf.org; Tue, 14 Oct 2003 08:47:57 -0400 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1A9Oai-0001ta-00 for ipv6@ietf.org; Tue, 14 Oct 2003 08:47:56 -0400 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9EClLo0084182 for ; Tue, 14 Oct 2003 14:47:22 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9EClMOh203004 for ; Tue, 14 Oct 2003 14:47:23 +0200 Received: from zurich.ibm.com (sig-9-145-145-162.de.ibm.com [9.145.145.162]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA55220; Tue, 14 Oct 2003 14:47:21 +0200 Message-ID: <3F8BF03F.1866AEE2@zurich.ibm.com> Date: Tue, 14 Oct 2003 14:46:55 +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: IPv6 CC: Thomas Narten Subject: Response to IESG comments on draft-ietf-ipv6-flow-label-07.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The IESG comments on this document are at https://www.ietf.org/IESG/EVALUATIONS/draft-ietf-ipv6-flow-label.bal It's taken a while for the authors to discover them, but here are our responses. We'd like the WG's reactions over the next few days, so that we can update the draft appropriately. > Ted Hardie (Discuss - August 7, 2003 teleconference Ted > reclassified this to a COMMENT): > This is very mild, and I could be talked out of it on the call, > but I do find it odd that the key motivational text is in > section 5.1, in the security requirements. This is the > text I mean: > > > The goal of the Flow Label is to allow different levels of service to > be provided for traffic streams on a common network infrastructure. A > variety of techniques may be used to achieve this, but the end result > will be that some packets receive different (e.g., better or worse) > service than others. The mapping of network traffic to the flow- > specific treatment is triggered by the IP addresses and Flow Label > value of the IPv6 header, > > This looks to me like it belongs in the introduction, so that the reader > can understand the impetus to the work. We think this is correct. Either this duplicates the introduction, or it belongs in the introduction. In any case, it doesn't belong in the security section. > > As a side note, I have some concerns about whether any protocol can > meet the explicit requirements in Section 4 and the implicit requirement > of "do some good" without running into the maw of some well-known > dragons, but the statement of requirements looks fair to me. We think that unspecified dragons are not useful to mention. In any case, they should be discussed in specific use case drafts, not here. See below for more comments on use cases. > Alex Zinin (Discuss): > > This document talks about per-flow state establishment and > processing on interim nodes. This is essentially IntServ > and it doesn't scale well. Not true. The notion of "flow" used here is more general than in intserv (or NSIS), although the default case of a flow is a single transport connection. When specific use cases for the flow label are written up, their individual scaling properties must indeed be documented. > > More comments from rtg-dir (Ross) below. > > General Comments > > It seems to me that the flow label has a purpose, and two possible > uses. To me the document seems to be not totally clear or perhaps > even wrong regarding which of the uses is the main one. > > The purpose is to identify flows. For example, this allows the flow to > be identified using only fields which are in fixed positions in the > IPv6 Header. This purpose seems to me to be well defined in the > document. That is deliberate. The idea of the draft is to tell IPv6 implementors (both hosts and router) what is the minimum set of functionality they MUST or SHOULD implement to enable use of the flow label. The draft doesn't purport to define specific use cases with their various detailed considerations. In fact, Ross's comment shows that we have done what we intended in the draft. Perhaps we need a more explicit statement about this in the introduction. > > Now that you have an indicator regarding what flow a particular packet > belongs to, what use would you have for this information? > > One possible use is for hashing packets, for example to spread traffic > across equal cost multi-paths without re-ordering packets from any one > flow. This seems like a pretty straightforward and sensible use, which > requires close to zero change to the Internet architecture, and which > is briefly mentioned in the document. > > The other possible use is for an explicit flow set up procedure. > However, since the flow are per-{source-address; destination-address; > flow field} triplet, it would seem that this won't scale much better > than the current int-serve specification. Thus it is not clear whether > this will end up being useful in practice. At best I would call this > experimental. We can think immediately of at least two other uses - as an e2e label for a whole class of traffic (coarse grain aggregation), and [this is new from recent debate inside the multi6 design team] as an e2e label for a multihoming session. > > In some places in the document it appears that the flow field is for > the purpose of identifying flows, and that either of the two uses > might be sensible reasons that you might want to identify flows. Yes. Exactly. > In > other places in the document it looks like the second purpose (which > to me seems the more speculative) is the reason for the flow field. It might be. > > I think that it would make sense to clearly separate these. What needs to be clearly stated is that specific applications of the flow label need to be / will be documented in specific use case documents. We're not sure that there is anything else we can do in the present draft. Ross's comment is a bit too general to generate specific text changes. > More specific comments > >> Section 1: > > First three paragraphs do a good job of defining the purpose of the > flow ID (to allow efficient flow classification based only on fields in > the fixed part of the IPv6 header). > > Fourth paragraph, first sentence: > The minimum level of IPv6 flow support consists > of labeling the flows. > > In a sense this is reasonable, but I am not sure precisely what it > means. > Does this mean: > > In order to be an IPv6 conformant node, IPv6 source > nodes MUST be able to label outgoing flows. > > or does this mean: > > In order to claim conformance to the IPv6 flow > label specification, IPv6 source nodes MUST support > labeling outgoing flows. > > Or does this mean something else? The second one. We can clarify this. > > >> Sections 2 and 3. > > This seems reasonable, and again defines the purpose of the > flow label in a reasonable way, as well as defining some very > reasonable requirements, for example specifying how a source > should set the flow value. > > >> Proposed New Section Between section 3 and 4: > > It seems to me that the most obviously worthwhile of the > potential uses of the flow label field is to allow routers to split > traffic on multiple paths (for example, for load sharing and traffic > engineering purposes), without having to look past the IPv6 > header. Thus speaks a routing person... > > One example of where this might be very useful is in the case > of encapsulation, for example over IPsec over IPv6 > or over GRE over IPv6 encapsulations. In this case > there might be a potentially very large number of high layer flows > which will be encapsulated with the same IPv6 source and > destination addresses in the outer IPv6 header. If you can hash > only on the outer IPv6 addresses, then you could get a lot of > traffic which is forced to take the same path. If you allow a finer > grain flow label to be placed in the flow label field, then you can > get a much more even distribution of traffic across, for example, > equal cost multi-paths. Indeed. This is one of the use cases that needs to be written up in its own document. Not squeezed in here. > I think that it is worth having a section on this possibility. I don't > think that this requires all that much text. > > There is one question which I have, which could be cleared up > in such a section: Specifically, the second sentence of section > 2 states: > > A Flow Label of zero is used to indicate packets > not part of any flow. > > Suppose that I am an IPv6 router which is hashing on source > address, destination address, and flow label, and I am using > the hash to split traffic among several paths. > > If I see a packet with a flow label of zero, which of the following do > I assume: > > - the node does not implement any flow labelling ability, and > therefore I must hash only on source and destination > address. > > - the node does implement flow labelling, and is telling me > that the packet is not part of any flow, and can therefore > be > forwarded on any path without regard for re-ordering. > > If we assume the latter, then implementation of the flow labelling > capability must be supported by all IPv6 source nodes (at least > to the point of sticking a non-zero value in the flow field), since > otherwise their packets might be re-ordered by nodes which > assume that their packets are not part of any flow. The use of the flow label doesn't affect the desired reordering semantics of the Internet, which remain "well, try not to reorder." So the functional difference between the two interpretations is small. In other words we don't intend a zero flow label to be a license to reorder. In fact we can't see any harm done by including a zero flow label in the hash - this will just be the default flow for a given srce/dest pair. So what? There's no presumption that each flow has a similar amount of traffic, anyway. We should perhaps add an explicit statement that a zero flow label does not imply that significant reordering is acceptable. > > I would suggest using zero to indicate that flow labelling is not > supported (and thus routers better keep the packets in order > based only on source and destination addresses). If we also > want to indicate that some packets are not part of a flow, we > might give them a random value, or a different special value. Well, we just don't see a major semantic difference between "I don't label flows" and "I decided not to label this packet". Both require default treatment. > > >> Section 4: > > The flow state establishment requirements in section 4 seem to be > very much incomplete. If there were a complete set of flow state > establishment requirements, then I think that the requirements > specified in this section are reasonable ones, and would be > included in the set. However, the two requirements specified in > section 4 seem to be such a small subset of the complete set of > requirements that I don't see why it is worth listing them at all. I > think that it would be cleaner just to say that methods and > requirements for explicit flow establishment are outside of the > scope of this document. No, these are a consensus view of the minimal requirements that all nodes must satisfy in order to allow co-existence of various different flow label use cases in the Internet. The individual use cases will add their own requirements. The WG wanted us to reduce the detail here to the vital minimum, and that's what we did. > > Naturally if section 4 were removed, then the last phrase of the > first paragraph of the abstract would also need to be removed > (page 1, phrase "and the requirements for flow state establishment > methods"). Similarly the second to last paragraph of section 1 > would need to be abbreviated. > > >>Section 5: > > First paragraph, last sentence: > > Even if the flow label were encrypted, its presence > as a constant value in a fixed position might assist > traffic analysis and cryptoanalysis. > > The flow label is supposed to be unstructured -- in the sense that if > I am not the source node, then I don't know anything about how the > source set the label, except that a different value means a different > flow. As such, I don't understand what encryption would do to change > the interpretation of a flow label. If two labels were encrypted to > the same exact value, then it would seem clear that they can't be > un-encrypted back to different values. If two flow labels were > encrypted to different values, then as a node in the middle observing > the packets going by I don't detect any difference. That's not the point. There have been a few famous crypto breaks in history due to fixed patterns occurring in the plaintext. The flow label increases the number of fixed (non-zero) bits in the packet header, and that is presumably still a cryptographic risk factor as it was in WW 2. > > Section 5.1, second paragraph (top of page 5), first sentence: > > Note that there is no guarantee that flow labels sent by a node are > not set in any manner that the node wants to, such as reusing flow > labels, against the recommendations in this document. > > This seems to be a rather awkward sentence, and should probably > be re-written. OK > > Additional Topic: Somewhere in the security section (probably in a new > subsection at the end) it might be worth mentioning that in those > locations where a firewall or filtering router is employed which looks > past the IP header to higher level headers, the flow label does > nothing to eliminate the need to continue to look at the higher > headers. OK > > Ross > > Jon Peterson (Discuss): > > Along the same lines as the comments from the Routing Area Directorate, but > with a few different issues in the text: > > I believe there are two purposes of flows given in the document - first, a > flow as a way of flagging a stream of related traffic coming from a node > (following Section 3, first paragraph), and second, a flow as something that > would be prioritized by routers (following Section 5.1, first paragraph). > There are a couple of ways in which the two seem to get mixed up. > > 1) In the last paragraph of 5.1, it suggests that a policy decision in the > source node should be made to determine whether or not an application or > transport protocol is allowed to use a non-zero Flow Label. But reading, for > example, the first paragraph of Section 3, the document suggests that "each > unrelated transport connection and application data stream" on a node should > be assigned to a new flow (which presumably means that they would have a > non-zero Flow Label). Yes, the policy can override the SHOULD. That could be clarified. > > 2) Section 3, second paragraph, says: > > To enable applications and transport protocols to define what packets > constitute a flow, the source node MUST provide means for the > applications and transport protocols to specify the Flow Label values > to be used with their flows. > > Given that there is some sort of policy decision associated with the > assignment of flows, I don't think applications and transport protocols > could really get to 'specify' these Flow Labels. Why not? Consider a use case where we use the flow label at "traffic type" granularity. A video codec application might want to use different flow labels for different levels of video encoding. It's not for the IPv6 WG to prevent that. > It also isn't clear how > collisions would be managed (Section 3, third paragraph) if it were possible > for any multiple applications on the same host to specify Flow Label values. We deleted a whole lot of implementation recommendations in this area, at the WG's request. It's entirely algorithmic but it takes you into API and local state areas that are out of place in a protocol spec. The IP stack has to cache all flow labels in current use, and whether collisions are allowed or disallowed is again a use case issue - you might want to use the same coarse flow label for the audio part of video flows and for VoIP - or you might not, depending on how you've chosen to use the flow label. Again, it isn't for the IPv6 WG to legislate on this. Brian -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 14 10:14:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11383 for ; Tue, 14 Oct 2003 10:14:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9PwY-0000WZ-Gr for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 10:14:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EEEYbH002009 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 10:14:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9PwX-0000Ti-Sr for ipv6-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 10:14:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11303 for ; Tue, 14 Oct 2003 10:14:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9PwV-00037b-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 10:14:31 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9PwU-00037Y-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 10:14:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Pw1-0000MC-Q4; Tue, 14 Oct 2003 10:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9PvS-0000Ln-08 for ipv6@optimus.ietf.org; Tue, 14 Oct 2003 10:13:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11179 for ; Tue, 14 Oct 2003 10:13:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9PvP-00036P-00 for ipv6@ietf.org; Tue, 14 Oct 2003 10:13:23 -0400 Received: from 248.cust3.nsw.dsl.ozemail.com.au ([203.103.158.248] helo=nosense.org) by ietf-mx with esmtp (Exim 4.12) id 1A9PvO-00035w-00 for ipv6@ietf.org; Tue, 14 Oct 2003 10:13:23 -0400 Received: from Dupy2.nosense.org (248.cust3.nsw.dsl.ozemail.com.au [203.103.158.248]) by nosense.org (Postfix) with SMTP id A19083F017 for ; Tue, 14 Oct 2003 23:43:37 +0930 (CST) Date: Tue, 14 Oct 2003 23:43:36 +0930 From: Mark Smith To: ipv6@ietf.org Subject: Will IPv4 be formally deprecated when IPv6 is good enough ? Message-Id: <20031014234336.33b20bf5.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> Organization: The No Sense Organisation X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, A recent discussion came up on the ipv6 mailing list regarding why the market picked up IPv4 NAT, initially asked by Geoff Huston, and posted to the list by Pekka Savola. Archives of the discussion are available at http://marc.theaimsgroup.com/?l=ipng&m=106389565013129&w=2 and http://marc.theaimsgroup.com/?l=ipng&m=106442112224359&w=2 A little later, it occured to me that maybe what the market might be missing is a statement from the IETF, IESG and/or IAB, that IPv6 is now *ready*, and can be deployed in production via the available transition mechanisms, slowly replacing IPv4 (+ NAT). Maybe the market is really just waiting for the engineers behind IPv6 to say "it's basically finished, its now ready for you to use, pending your applications being ported". Having a brief look at the list of IPng requirements in rfc1752, it would appear to me, with my limited knowledge of all the IPv6 development that has occured, that most of the goals have been met : "6.1 The IPng Technical Criteria document The criteria described in this document include: (from Kasten94) * complete specification - The proposal must completely describe the proposed protocol. We must select an IPng by referencing specific documents, not to future work. * architectural simplicity - The IP-layer protocol should be as simple as possible with functions located elsewhere that are more appropriately performed at protocol layers other than the IP layer. * scale - The IPng Protocol must allow identifying and addressing at least 10**9 leaf-networks (and preferably much more) * topological flexibility - The routing architecture and protocols ofIPng must allow for many different network topologies. They must not assume that the network's physical structure is a tree. * performance - A state of the art, commercial grade router must be able to process and forward IPng traffic at speeds capable of fully utilizing common, commercially available, high-speed media at the time. * robust service - The network service and its associated routing and control protocols must be robust. * transition - The protocol must have a straightforward transition plan from IPv4. * media independence - The protocol must work across an internetwork of many different LAN, MAN, and WAN media, with individual link speeds ranging from a ones-of-bits per second to hundreds of gigabits per second. * datagram service - The protocol must support an unreliable datagram delivery service. * configuration ease - The protocol must permit easy and largely distributed configuration and operation. Automatic configuration of hosts and routers is required. * security - IPng must provide a secure network layer. * unique names - IPng must assign unique names to all IP-Layer objects in the global, ubiquitous, Internet. These names may or may not have any location, topology, or routing significance. * access to standards - The protocols that define IPng and its associated protocols should be as freely available and redistributable as the IPv4 and related RFCs. There must be no specification-related licensing fees for implementing or selling IPng software. * multicast support - The protocol must support both unicast and multicast packet transmission. Dynamic and automatic routing of multicasts is also required. * extensibility - The protocol must be extensible; it must be able to evolve to meet the future service needs of the Internet. This evolution must be achievable without requiring network-wide software upgrades. * service classes - The protocol must allow network devices to associate packets with particular service classes and provide them with the services specified by those classes. * mobility - The protocol must support mobile hosts, networks and internetworks. * control protocol - The protocol must include elementary support for testing and debugging networks. (e.g., ping and traceroute) * tunneling support - IPng must allow users to build private internetworks on top of the basic Internet Infrastructure. Both private IP-based internetworks and private non-IP-based (e.g., CLNP or AppleTalk) internetworks must be supported." That brings to my mind two questions a) Is IPv4 going to be formally deprecated when IPv6 is good enough? If so, are the related IPv4 NAT RFCs also going to be deprecated at that time ? b) Is IPv6 good enough yet ? Thanks, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 14 11:03:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13695 for ; Tue, 14 Oct 2003 11:03:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Qh5-0003n4-5L for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 11:02:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EF2diX014564 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 11:02:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Qh4-0003mp-Tu for ipv6-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 11:02:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13660 for ; Tue, 14 Oct 2003 11:02:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Qh2-0003py-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 11:02:36 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9Qh1-0003pv-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 11:02:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9QgU-0003ZY-Hy; Tue, 14 Oct 2003 11:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Qfx-0003Yh-3R for ipv6@optimus.ietf.org; Tue, 14 Oct 2003 11:01:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13587 for ; Tue, 14 Oct 2003 11:01:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Qfu-0003ot-00 for ipv6@ietf.org; Tue, 14 Oct 2003 11:01:26 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1A9Qft-0003oC-00 for ipv6@ietf.org; Tue, 14 Oct 2003 11:01:26 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <4D6JVVFX>; Tue, 14 Oct 2003 11:00:43 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922DC6@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Brian E Carpenter'" , IPv6 Cc: Thomas Narten Subject: RE: Response to IESG comments on draft-ietf-ipv6-flow-label-07.tx t Date: Tue, 14 Oct 2003 11:00:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > > > It also isn't clear how > > collisions would be managed (Section 3, third paragraph) > if it were possible > > for any multiple applications on the same host to specify > Flow Label values. > > We deleted a whole lot of implementation recommendations in > this area, at the > WG's request. It's entirely algorithmic but it takes you > into API and local > state areas that are out of place in a protocol spec. The IP > stack has to > cache all flow labels in current use, and whether collisions > are allowed or > disallowed is again a use case issue - you might want to use the same > coarse flow label for the audio part of video flows and for > VoIP - or you > might not, depending on how you've chosen to use the flow > label. Again, > it isn't for the IPv6 WG to legislate on this. => FWIW, the collision is only an issue in two cases: 1. The actual value of the Flow label has a meaning, and/or, 2. Intermediate nodes have specific states for certain flows. Either of the above, or none of the above can occur depending on how the Flow label is getting used. Therefore, it would make sense to not restrict this specification and to put the onus on future specs that specify ways of using the flow label. Hesham > > Brian > > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > > NEW ADDRESS PLEASE UPDATE ADDRESS BOOK > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 14 11:35:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15092 for ; Tue, 14 Oct 2003 11:35:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RC2-0005Us-Bj for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 11:34:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EFYcp1021129 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 11:34:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RC2-0005Ui-4Z for ipv6-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 11:34:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14965 for ; Tue, 14 Oct 2003 11:34:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9RC1-0004DV-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 11:34:37 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9RC0-0004DS-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 11:34:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RBR-0005OQ-Tl; Tue, 14 Oct 2003 11:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RB1-0005Ny-5q for ipv6@optimus.ietf.org; Tue, 14 Oct 2003 11:33:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14933 for ; Tue, 14 Oct 2003 11:33:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9RB0-0004Cy-00 for ipv6@ietf.org; Tue, 14 Oct 2003 11:33:34 -0400 Received: from bardisk.pilsnet.sunet.se ([192.36.125.26]) by ietf-mx with esmtp (Exim 4.12) id 1A9RAz-0004Cp-00 for ipv6@ietf.org; Tue, 14 Oct 2003 11:33:33 -0400 Received: from bardisk.pilsnet.sunet.se (localhost [IPv6:::1]) by bardisk.pilsnet.sunet.se (8.12.9p2/8.12.8) with ESMTP id h9EFWw23042100; Tue, 14 Oct 2003 17:32:58 +0200 (CEST) (envelope-from mansaxel@bardisk.pilsnet.sunet.se) Received: (from mansaxel@localhost) by bardisk.pilsnet.sunet.se (8.12.9p2/8.12.3/Submit) id h9EFWwDj042099; Tue, 14 Oct 2003 17:32:58 +0200 (CEST) Date: Tue, 14 Oct 2003 17:32:58 +0200 From: Mans Nilsson To: Mark Smith Cc: ipv6@ietf.org Subject: Re: Will IPv4 be formally deprecated when IPv6 is good enough ? Message-ID: <20031014153258.GA39179@sunet.se> References: <20031014234336.33b20bf5.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: <20031014234336.33b20bf5.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> User-Agent: Mutt/1.4.1i X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-synced-from: Pilsnet Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Will IPv4 be formally deprecated when IPv6 is good enough ? Date: = Tue, Oct 14, 2003 at 11:43:36PM +0930 Quoting Mark Smith (ipv6@c753173126e0= bc8b057a22829880cf26.nosense.org): > That brings to my mind two questions >=20 > a) Is IPv4 going to be formally deprecated when IPv6 is good enough? If s= o, are the related IPv4 NAT RFCs also going to be deprecated at that time ? Do not think so. Maybe it is my limited mind, but I find it hard not to kee= p=20 v4 on some boxes.=20 =20 > b) Is IPv6 good enough yet ? I think so. There are valid concerns on two things; multihoming and address allocation procedures. There seems to be strong forces among the=20 researchers and vendors advocting that we halt and wait for the Grail of multihoming while we at the same time work very hard in preventing= =20 people from getting allocations, to preserve address space and keep the routing table size down. I think the address allocation problem is based on v4 habits. v6 is abundant. We need it to be available. Nothing will happen until people can get real allocations with relative ease, not so easy that nuisance allocations will occur, but almost. Give every AS number holder a /32 or something, and watch deployment speed up. With multihoming, strongly related to above, I suggest people cease waiting for the Grail and instead adopt the v4 model, aided by the=20 limited growth we'd see if people did not have to patch their nets together using disjunct prefixes. I believe routing table growth would be much slower, and there are suggestions I find supportive of this in some analyses of routing table characteristics, for example in : "Small ASes (those who originate only a few prefixes into the global routing system) do not contribute more than their fair share of either route entries or churn to the global routing system."=20 Thus, if most ASen were able to contain all their hosts within one single /32 per AS, we would see limited routing table growth for some years, during which there would be time to develop more sophisticated routing paradigms, if operational experience dictated such a need was indeed present. The key words here are "operational experience". We need to get people=20 start using v6 for everyday things.=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE This TOPS OFF my partygoing experience! Someone I DON'T LIKE is talking to me about a HEART-WARMING European film ... --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/jBcq02/pMZDM1cURAgMrAKCBmsY+Xaf3wbDInOkZX1qpfiLGUACeNUGF HZu6UUwK45ryyfClYmHdLSY= =3Gk4 -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 14 12:50:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18953 for ; Tue, 14 Oct 2003 12:50:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9SMx-0001tI-GD for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 12:50:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EGnxaT007269 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 12:49:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9SMx-0001tA-4J for ipv6-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 12:49:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18912 for ; Tue, 14 Oct 2003 12:49:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9SMv-0005DF-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 12:49:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9SMv-0005DC-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 12:49:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9SM1-0001nF-Jo; Tue, 14 Oct 2003 12:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9SLl-0001mp-Aq for ipv6@optimus.ietf.org; Tue, 14 Oct 2003 12:48:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18881 for ; Tue, 14 Oct 2003 12:48:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9SLj-0005Cn-00 for ipv6@ietf.org; Tue, 14 Oct 2003 12:48:43 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1A9SLj-0005Cf-00 for ipv6@ietf.org; Tue, 14 Oct 2003 12:48:43 -0400 Subject: RE: Will IPv4 be formally deprecated when IPv6 is good enough ? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Oct 2003 09:48:12 -0700 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: Thread-Topic: Will IPv4 be formally deprecated when IPv6 is good enough ? thread-index: AcOSZabnb648wQezQ+qpSaHfNwW+2wAB5CaQ From: "Michel Py" To: "Mark Smith" , Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Mark, > Mark Smith wrote: > a) Is IPv4 going to be formally deprecated when IPv6 is good > enough? If so, are the related IPv4 NAT RFCs also going to be > deprecated at that time ? IMHO it's not a matter of being good enough, it's a matter of how many IPv4 hosts are still up. The IETF deprecating IPv4 would not achieve a lot; there still are people that use an Apple II and even some that are writing software and design hardware for it. There will be millions of diehard IPv4 users for a long while. It's a matter when vendors become to remove IPv4 from stacks, stop supporting IPv4, and when operators begin to provide IPv6-only service. In my wildest dreams, 10 years at least; possibly 20 depending on how good the projections in terms of IPv4 exhaustion are. > b) Is IPv6 good enough yet? Not for most. As long as there is no killer app and as long as IPv4 addresses are available, the investments to move to IPv6 are often not worth what it brings. One of the troubles is that v6 does not even do what v4 does: No private addresses. No PI addresses. No multihoming. The other trouble is that there is no way to do without IPv4 as of today. In the enterprise, if someone that implements IPv6 today could plan on IPv4 removal within two or three years, that would be considered, but operating dual-stack for 10 or 20 years when IPv4 provides all necessary functions is a waste of money. Keep in mind: peer-to-peer applications from each desktop to every possible host on the Internet is not the highest priority of enterprises; it actually is heavily filtered and firewalled both ingress and egress. As far as the consumer goes, most on-line gaming and p2p now works across NAT and so does SIP I hear (with STUN). The only way the consumer is going to accept IPv6 is when it does not know it's there, which we are not anywhere close to. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 14 13:22:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19967 for ; Tue, 14 Oct 2003 13:22:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9SsH-0003iu-OM for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 13:22:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EHML6S014311 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 13:22:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9SsH-0003ik-Js for ipv6-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 13:22:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19916 for ; Tue, 14 Oct 2003 13:22:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9SsF-0005WH-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 13:22:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9SsF-0005WE-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 13:22:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Srx-0003a6-FU; Tue, 14 Oct 2003 13:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Sr8-0003ZD-D3 for ipv6@optimus.ietf.org; Tue, 14 Oct 2003 13:21:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19886 for ; Tue, 14 Oct 2003 13:20:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Sr6-0005V1-00 for ipv6@ietf.org; Tue, 14 Oct 2003 13:21:08 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A9Sr5-0005Uq-00 for ipv6@ietf.org; Tue, 14 Oct 2003 13:21:08 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9EHKUvC009514; Tue, 14 Oct 2003 10:20:33 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AMM77806; Tue, 14 Oct 2003 10:15:37 -0700 (PDT) Message-Id: <6.0.0.22.2.20031014101000.04566008@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 14 Oct 2003 10:19:58 -0700 To: Mark Smith From: Fred Baker Subject: Re: Will IPv4 be formally deprecated when IPv6 is good enough ? Cc: ipv6@ietf.org In-Reply-To: <20031014234336.33b20bf5.ipv6@c753173126e0bc8b057a22829880c f26.nosense.org> References: <20031014234336.33b20bf5.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , At 07:13 AM 10/14/2003, Mark Smith wrote: >A little later, it occured to me that maybe what the market might be >missing is a statement from the IETF, IESG and/or IAB, that IPv6 is now >*ready*, and can be deployed in production via the available transition >mechanisms, slowly replacing IPv4 (+ NAT). Maybe the market is really just >waiting for the engineers behind IPv6 to say "it's basically finished, its >now ready for you to use, pending your applications being ported". I personally would be very surprised if either the market is waiting for a blessing or IPv4 is deprecated. You might ask yourself whether moving RIP to historic (deprecated) and OSPF as "required for implementation in all routers" 1058 Routing Information Protocol. C.L. Hedrick. Jun-01-1988. (Format: TXT=93285 bytes) (Updated by RFC1388, RFC1723) (Status: HISTORIC) 2328 OSPF Version 2. J. Moy. April 1998. (Format: TXT=447367 bytes) (Obsoletes RFC2178) (Also STD0054) (Status: STANDARD) RFC 1812, section 7.2.1: "A router that implements any routing protocol (other than static routes) MUST IMPLEMENT OSPF (see Section [7.2.2]). A router MAY implement additional IGPs." has significantly affected anyone's willingness to configure RIP routing in a network. What *has* affected people's willingness to deploy or to do application work is a perception of someone else being willing to pay for them doing so and belief that it solves a problem they have. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 14 13:28:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20186 for ; Tue, 14 Oct 2003 13:28:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Sxq-0004BB-N0 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 13:28:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EHS6X2016059 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 13:28:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Sxq-0004Aw-Gr for ipv6-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 13:28:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20134 for ; Tue, 14 Oct 2003 13:27:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Sxo-0005ZC-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 13:28:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9Sxo-0005Z9-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 13:28:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Sxl-00047H-N5; Tue, 14 Oct 2003 13:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Sxd-00046r-Ng for ipv6@optimus.ietf.org; Tue, 14 Oct 2003 13:27:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20121 for ; Tue, 14 Oct 2003 13:27:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Sxa-0005Yw-00 for ipv6@ietf.org; Tue, 14 Oct 2003 13:27:50 -0400 Received: from atlas.fccn.pt ([193.136.7.1]) by ietf-mx with smtp (Exim 4.12) id 1A9SxZ-0005Yb-00 for ipv6@ietf.org; Tue, 14 Oct 2003 13:27:49 -0400 Received: (qmail 42979 invoked by uid 2502); 14 Oct 2003 17:27:17 -0000 Received: from cfriacas@fccn.pt by atlas.fccn.pt with qmail-scanner-0.94 (. Clean. Processed in 0.125043 secs); 14/10/2003 18:27:17 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 14 Oct 2003 17:27:17 -0000 Date: Tue, 14 Oct 2003 18:27:17 +0100 (WEST) From: Carlos Friacas To: Mark Smith cc: ipv6@ietf.org Subject: Re: Will IPv4 be formally deprecated when IPv6 is good enough ? In-Reply-To: <20031014234336.33b20bf5.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> Message-ID: References: <20031014234336.33b20bf5.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , My 2 (euro-)cents: > That brings to my mind two questions > > a) Is IPv4 going to be formally deprecated when IPv6 is good enough? No. > If so, are the related IPv4 NAT RFCs also going to be deprecated at that > time ? No. > b) Is IPv6 good enough yet ? No. Still a lot of work to be done. Regards, ./Carlos "Upgrade the Internet! -- Now!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup FCCN - Fundacao para a Computacao Cientifica Nacional fax:+351 218472167 "Internet is just routes (127855/472), naming (millions) and... people!" -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 14 14:08:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21928 for ; Tue, 14 Oct 2003 14:08:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TaD-0006vW-RR for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 14:07:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EI7jmm026618 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 14:07:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TaD-0006vF-FP for ipv6-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 14:07:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21862 for ; Tue, 14 Oct 2003 14:07:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9TaB-000665-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 14:07:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9TaA-000662-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 14:07:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TZX-0006bO-L1; Tue, 14 Oct 2003 14:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TZ4-0006SQ-S1 for ipv6@optimus.ietf.org; Tue, 14 Oct 2003 14:06:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21781 for ; Tue, 14 Oct 2003 14:06:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9TZ2-00064V-00 for ipv6@ietf.org; Tue, 14 Oct 2003 14:06:32 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A9TZ1-00063j-00 for ipv6@ietf.org; Tue, 14 Oct 2003 14:06:31 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 14 Oct 2003 11:02:34 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9EI5weH029904; Tue, 14 Oct 2003 11:05:58 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AMM84103; Tue, 14 Oct 2003 11:01:03 -0700 (PDT) Message-Id: <6.0.0.22.2.20031014102300.044542d8@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 14 Oct 2003 10:52:10 -0700 To: "Michel Py" From: Fred Baker Subject: IPv6 adoption behavior Cc: "Mark Smith" , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , At 09:48 AM 10/14/2003, Michel Py wrote: >In my wildest dreams, 10 years at least; possibly 20 depending on how good >the projections in terms of IPv4 exhaustion are. Frankly, it's not about IPv4 exhaustion, it is about market adoption of IPv6. IPv4 address exhaustion will never occur. As we approach 100% allocation (being now a tad over 60% allocation), the level of administrative pushback on a new allocation requests will increase, until they get to a point where ISPs will find it simpler and more cost-effective to purchase allocations from each other. A market will develop, and the price of an allocation will change as demand approaches supply. Eventually, the price of purchasing an allocation from another ISP will be perceived and used as a competitive weapon, and the market will become a very difficult one. But supply will never become zero. It will simply become expensive. That is economics 101. We will, at the same time, go through an S curve in IPv6 deployment. We currently see a certain level of ISP and Enterprise deployment, and sometimes see edge-ISP-edge connectivity, most commonly on research networks. At the point where it becomes probable that the only or preferred way one can access a peer enterprise with which one has or seeks a business relationship is via IPv6, perhaps for some critical application, IPv6 deployment will start to grow very strongly. As it approaches saturation of the current IPv4 Internet, systems which choose IPv6 in preference to IPv4 will use IPv6 when they can, and IPv4 traffic will start to subside. When IPv4 volume becomes too marginal, ISPs will start shutting it down. The question(s) that raises are "will ever occur, and if so, when?" My crystal ball is as cloudy as anyone's. But I would expect that it is all a matter of economics. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 14 14:28:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22970 for ; Tue, 14 Oct 2003 14:28:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Tu1-000837-FO for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 14:28:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EISDVe030937 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 14:28:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Tu1-00082u-9x for ipv6-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 14:28:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22941 for ; Tue, 14 Oct 2003 14:28:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Tty-0006LB-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 14:28:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9Tty-0006L8-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 14:28:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Ttq-0007zC-GG; Tue, 14 Oct 2003 14:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Tt5-0007y5-HC for ipv6@optimus.ietf.org; Tue, 14 Oct 2003 14:27:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22894 for ; Tue, 14 Oct 2003 14:27:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Tt2-0006KR-00 for ipv6@ietf.org; Tue, 14 Oct 2003 14:27:12 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1A9Tt2-0006K6-00 for ipv6@ietf.org; Tue, 14 Oct 2003 14:27:12 -0400 Subject: RE: IPv6 adoption behavior MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Oct 2003 11:26:35 -0700 Content-class: urn:content-classes:message Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: IPv6 adoption behavior thread-index: AcOSfgGpEkSK+pTUT3iZ4dhJP1jscwAAGFfw From: "Michel Py" To: "Fred Baker" Cc: "Mark Smith" , Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Fred, > Fred Baker wrote: > Frankly, it's not about IPv4 exhaustion, it is about market > adoption of IPv6. > IPv4 address exhaustion will never occur. As we approach 100% > allocation (being now a tad over 60% allocation), the level > of administrative pushback on a new allocation requests will > increase, until they get to a point where ISPs will find it > simpler and more cost-effective to purchase allocations from > each other. A market will develop, and the price of an > allocation will change as demand approaches supply. And as prices rise we can expect a gray market of IPv4 blocks much worse than what we see today. > Eventually, the price of purchasing an allocation from > another ISP will be perceived and used as a competitive > weapon, and the market will become a very difficult one. > But supply will never become zero. It will simply become > expensive. That is economics 101. Agree. However, this has an unfortunate side effect: Since money will differentiate the haves from the haves-not, it is a reasonable assumption that large organizations such as multinational corporations and developed countries will actually never run out of IPv4 addresses because they are and possibly will remain in the top tier that can afford them. Why is this unfortunate? Because these large organizations can indeed delay IPv6 deployment until the last minute. > At the point where it becomes probable that the only or preferred > way one can access a peer enterprise with which one has or seeks > a business relationship is via IPv6 Which unfortunately will likely be delayed for the reasons I mentioned above. > As it approaches saturation of the current IPv4 Internet, systems > which choose IPv6 in preference to IPv4 will use IPv6 when they > can, and IPv4 traffic will start to subside. When IPv4 volume > becomes too marginal, ISPs will start shutting it down. Yep. > The question(s) that raises are "will plan> ever occur, and if so, when?" Indeed. > My crystal ball is as cloudy as anyone's. But I would expect > that it is all a matter of economics. I concur. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 14 16:11:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29217 for ; Tue, 14 Oct 2003 16:11:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9VVz-0006ms-FE for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 16:11:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EKBVQA026091 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 16:11:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9VVz-0006mj-6T for ipv6-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 16:11:31 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29168 for ; Tue, 14 Oct 2003 16:11:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9VTb-0006WE-28; Tue, 14 Oct 2003 16:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9VTW-0006Vw-DR for ipv6@optimus.ietf.org; Tue, 14 Oct 2003 16:08:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28933 for ; Tue, 14 Oct 2003 16:08:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9VTU-0007cy-00 for ipv6@ietf.org; Tue, 14 Oct 2003 16:08:56 -0400 Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx with esmtp (Exim 4.12) id 1A9VTT-0007cf-00 for ipv6@ietf.org; Tue, 14 Oct 2003 16:08:55 -0400 Received: from gih505.telstra.net (dhcp12.potaroo.net [203.10.60.12]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h9EJv1Re013714; Wed, 15 Oct 2003 05:57:05 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20031015054658.00b3f550@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 15 Oct 2003 05:54:41 +1000 To: Fred Baker , "Michel Py" From: Geoff Huston Subject: Re: IPv6 adoption behavior Cc: "Mark Smith" , In-Reply-To: <6.0.0.22.2.20031014102300.044542d8@mira-sjc5-b.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , At 10:52 AM 14/10/2003 -0700, Fred Baker wrote: >At 09:48 AM 10/14/2003, Michel Py wrote: >>In my wildest dreams, 10 years at least; possibly 20 depending on how >>good the projections in terms of IPv4 exhaustion are. > >Frankly, it's not about IPv4 exhaustion, it is about market adoption of IPv6. > >IPv4 address exhaustion will never occur. As we approach 100% allocation >(being now a tad over 60% allocation), the level of administrative >pushback on a new allocation requests will increase, until they get to a >point where ISPs will find it simpler and more cost-effective to purchase >allocations from each other. A market will develop, and the price of an >allocation will change as demand approaches supply. Eventually, the price >of purchasing an allocation from another ISP will be perceived and used as >a competitive weapon, and the market will become a very difficult one. But >supply will never become zero. It will simply become expensive. > >That is economics 101. And is also described in RFC 1744. >My crystal ball is as cloudy as anyone's. But I would expect that it is >all a matter of economics. Indeed. The only other factor here is that it is not entirely a clean substitution, as NATs provide an alternative product which is an imperfect substitution. The extent to which the market, over the past few years, has tended towards NATs despite the negative effects in both local and network domains is quickly becoming the dominant factor in any economic consideration of this entire IPv4 / IPv6 area. Geoff -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 14 17:05:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02515 for ; Tue, 14 Oct 2003 17:05:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9WLd-0001tA-LJ for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 17:04:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EL4rKK007259 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 17:04:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9WLd-0001sT-C9 for ipv6-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 17:04:53 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02467 for ; Tue, 14 Oct 2003 17:04:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9WKn-0001fx-Rs; Tue, 14 Oct 2003 17:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9WK1-0001fL-Ig for ipv6@optimus.ietf.org; Tue, 14 Oct 2003 17:03:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02445 for ; Tue, 14 Oct 2003 17:03:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9WJz-00018G-00 for ipv6@ietf.org; Tue, 14 Oct 2003 17:03:11 -0400 Received: from dhcp4.se.kurtis.pp.se ([195.43.225.73] helo=laptop2.kurtis.autonomica.se) by ietf-mx with esmtp (Exim 4.12) id 1A9WJy-00018C-00 for ipv6@ietf.org; Tue, 14 Oct 2003 17:03:10 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h9EL2xwr002752; Tue, 14 Oct 2003 23:03:01 +0200 (CEST) Date: Tue, 14 Oct 2003 17:44:50 +0200 Subject: Re: Removing features Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Leif Johansson , Iljitsch van Beijnum , ipv6@ietf.org To: Juan Rodriguez Hervella From: Kurt Erik Lindqvist In-Reply-To: <200310131545.20345.jrh@it.uc3m.es> Message-Id: <58B6FA76-FE5D-11D7-BF24-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> | This is based on the assumption that leaking RFC 1918 routing >> | information or packets with RFC 1918 source or destination >> addresses is >> | actually harmful in and of itself. This is a broken assumption. If >> >> Tell that to the root zone operators and brace for the reaction. >> > > Hello Leif, > > Do you know what are the problems that *root zone operators* are > experiencing with RFC 1918 addresses ? It would be very interesting > if you could explain (to me) some of these issues... I don't see why > this kind of addresses could be a problem, as long as they > don't use them.... > Questions sourced from RFC1918 addresses and queries about RFC1918 in-addr.arpa (which should be handled by the AS112 servers) are the top two garbage requests at i.root-servers.net. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP4wZ9KarNKXTPFCVEQKvWACg+TD7bVjddhBowLiuesM0lI9qP/kAn26l M+WVJDvf4jiEab/8gdDU41Z/ =Y/1i -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 14 18:13:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06459 for ; Tue, 14 Oct 2003 18:13:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9XPM-0006uQ-4V for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 18:12:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EMCmIY026552 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 18:12:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9XPM-0006uB-0F for ipv6-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 18:12:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06387 for ; Tue, 14 Oct 2003 18:12:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9XPJ-0002U0-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 18:12:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9XPI-0002Tx-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 18:12:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9XOc-0006oF-4A; Tue, 14 Oct 2003 18:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9XO7-0006nu-Ti for ipv6@optimus.ietf.org; Tue, 14 Oct 2003 18:11:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06208 for ; Tue, 14 Oct 2003 18:11:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9XO4-0002Sa-00 for ipv6@ietf.org; Tue, 14 Oct 2003 18:11:28 -0400 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1A9XO3-0002SW-00 for ipv6@ietf.org; Tue, 14 Oct 2003 18:11:28 -0400 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id SAA04345; Tue, 14 Oct 2003 18:11:24 -0400 (EDT) Date: Tue, 14 Oct 2003 18:11:24 -0400 (EDT) From: Dan Lanciani Message-Id: <200310142211.SAA04345@ss10.danlan.com> To: ipv6@ietf.org Subject: Re: IPv6 adoption behavior Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Geoff Huston writes: |Indeed. The only other factor here is that it is not entirely a clean |substitution, |as NATs provide an alternative product which is an imperfect substitution. |The extent |to which the market, over the past few years, has tended towards NATs despite |the negative effects in both local and network domains is quickly |becoming the dominant factor in any economic consideration of this entire |IPv4 / IPv6 area. IMO, to consider IPv6 even as an imperfect substitution for IPv4+NAT is to vastly overstate IPv6 functionality. IPv6 offers absolutely nothing as a replacement for NAT's primary function: isolation of the customer network from the (typically business-driven) address policies of the service provider (e.g., cost, limits on number and stability, etc.). If anything IPv6 moves in the opposite direction by providing more invasive mechanisms than existing DHCP leases for the provider to disrupt the customer's network. It's all well and good to speculate that IPv6 customers won't *need* the isolation that NAT now offers with IPv4 because of (insert your favorite fantasy about transparent renumbering or philanthropic ISPs) but none of those dodges exist at present. Moreover, discussion of solutions that could actually fulfill the prophesy of rendering isolation unnecessary (e.g., source routing in its guise of locator/ identifier separation) are systematically relegated to small discussion lists where they pose no threat of implementation. You might be able to call IPv6 an imperfect substitution for IPv4 *without* NAT except for the glaring problem of single-address multi-homing support. Similarly, IPv6+NAT might be said to be an imperfect substitution for IPv4+NAT, and is probably what we will end up with if we end up with IPv6 (as an IPv4 replacement) at all. More likely v4 and v6 will continue in parallel forever since the upgrade costs are significant, especially when you consider the reduced functionality. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 14 18:13:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06550 for ; Tue, 14 Oct 2003 18:13:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9XPb-00074y-Ps for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 18:13:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EMD3QX027170 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 18:13:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9XPb-00072z-Bs for ipv6-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 18:13:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06421 for ; Tue, 14 Oct 2003 18:12:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9XPY-0002UO-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 18:13:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9XPY-0002UI-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 18:13:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9XPZ-0006xu-On; Tue, 14 Oct 2003 18:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9XOm-0006pR-1a for ipv6@optimus.ietf.org; Tue, 14 Oct 2003 18:12:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06298 for ; Tue, 14 Oct 2003 18:12:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9XOj-0002TG-00 for ipv6@ietf.org; Tue, 14 Oct 2003 18:12:09 -0400 Received: from as13-3-2.rny.s.bonet.se ([217.215.166.49] helo=klapautius.it.su.se) by ietf-mx with esmtp (Exim 4.12) id 1A9XOi-0002TD-00 for ipv6@ietf.org; Tue, 14 Oct 2003 18:12:08 -0400 Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h9F09Ww21509; Wed, 15 Oct 2003 02:09:32 +0200 Message-ID: <3F8C903C.1080503@it.su.se> Date: Wed, 15 Oct 2003 02:09:32 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Juan Rodriguez Hervella , Iljitsch van Beijnum , ipv6@ietf.org Subject: Re: Removing features References: <58B6FA76-FE5D-11D7-BF24-000A9598A184@kurtis.pp.se> In-Reply-To: <58B6FA76-FE5D-11D7-BF24-000A9598A184@kurtis.pp.se> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 |>Hello Leif, |> |>Do you know what are the problems that *root zone operators* are |>experiencing with RFC 1918 addresses ? It would be very interesting |>if you could explain (to me) some of these issues... I don't see why |>this kind of addresses could be a problem, as long as they |>don't use them.... |> | | Questions sourced from RFC1918 addresses and queries about RFC1918 | in-addr.arpa (which should be handled by the AS112 servers) are the top | two garbage requests at i.root-servers.net. | | - kurtis - | Sorry I missed your question. Anyway: Yeah, What Kurtis said. I sent a reference to a presentation to the list a few days back. It contains numbers. leifj -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/jJA88Jx8FtbMZncRAqYtAJ4peJa0ZM2G1//sa3YxlnLpfGIztwCfbRlQ Y6WF9o5gGyuGvuMmJYiP/ek= =UYDG -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 14 19:35:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09527 for ; Tue, 14 Oct 2003 19:35:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9YhS-00037c-Ps for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 19:35:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ENZYFI012000 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 19:35:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9YhS-00037T-Ip for ipv6-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 19:35:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09464 for ; Tue, 14 Oct 2003 19:35:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9YhQ-0003V1-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 19:35:32 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9YhQ-0003Uy-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 19:35:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Ygx-00031H-1H; Tue, 14 Oct 2003 19:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Yg7-00030h-I1 for ipv6@optimus.ietf.org; Tue, 14 Oct 2003 19:34:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09432 for ; Tue, 14 Oct 2003 19:33:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Yg3-0003UO-00 for ipv6@ietf.org; Tue, 14 Oct 2003 19:34:07 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1A9Yg3-0003UL-00 for ipv6@ietf.org; Tue, 14 Oct 2003 19:34:07 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id F18531412B; Tue, 14 Oct 2003 19:34:07 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25855-13; Tue, 14 Oct 2003 19:34:07 -0400 (EDT) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id AF0F51409A; Tue, 14 Oct 2003 19:34:06 -0400 (EDT) Date: Tue, 14 Oct 2003 19:30:31 -0400 From: Keith Moore To: Dan Lanciani Cc: moore@cs.utk.edu, ipv6@ietf.org Subject: Re: IPv6 adoption behavior Message-Id: <20031014193031.35a47f72.moore@cs.utk.edu> In-Reply-To: <200310142211.SAA04345@ss10.danlan.com> References: <200310142211.SAA04345@ss10.danlan.com> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 14 Oct 2003 18:11:24 -0400 (EDT) Dan Lanciani wrote: > IPv6 offers absolutely nothing as a > replacement for NAT's primary function: isolation of the customer network > from the (typically business-driven) address policies of the service > provider(e.g., cost, limits on number and stability, etc.). NAT isolates customer networks from upstream address policies only by severely limiting their functionality. The functionality of an IPv6 network is better than that of a NATted IPv4 network even if the IPv6 address changes frequently. However I agree that we need to define some expectations about address stability - both to serve as models for service agreements between customers and ISPs, and to serve as guidance for applications developers. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 14 19:48:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10035 for ; Tue, 14 Oct 2003 19:48:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Ytc-0004R2-D1 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 19:48:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ENm8QI017042 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 19:48:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Ytb-0004Nh-Dk for ipv6-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 19:48:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09992 for ; Tue, 14 Oct 2003 19:47:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9YtZ-0003eu-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 19:48:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9YtZ-0003er-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 19:48:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9YtW-0004Hs-8R; Tue, 14 Oct 2003 19:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Yse-0004H6-8t for ipv6@optimus.ietf.org; Tue, 14 Oct 2003 19:47:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09954 for ; Tue, 14 Oct 2003 19:46:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Ysc-0003e1-00 for ipv6@ietf.org; Tue, 14 Oct 2003 19:47:06 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1A9Ysb-0003dy-00 for ipv6@ietf.org; Tue, 14 Oct 2003 19:47:05 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9ENl34t007161 for ; Tue, 14 Oct 2003 16:47:03 -0700 (PDT) Received: from NAEXFE03.na.qualcomm.com (naexfe03.qualcomm.com [172.30.32.23]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9ENkxhl017622 for ; Tue, 14 Oct 2003 16:47:01 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXFE03.na.qualcomm.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Oct 2003 16:47:00 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6470.0 Subject: Test ... please ignore Date: Tue, 14 Oct 2003 16:46:59 -0700 Message-ID: <17D8F6DF3ED94D40BD607380866D9B7F327BCF@NAEX01.na.qualcomm.com> Thread-Topic: Test ... please ignore Thread-Index: AcOSrXXC0PBAkrq/Tomkw80tLOkryQ== From: "Barany, Peter" To: X-OriginalArrivalTime: 14 Oct 2003 23:47:00.0159 (UTC) FILETIME=[75E734F0:01C392AD] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 14 22:55:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14765 for ; Tue, 14 Oct 2003 22:55:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9boy-0006aA-1n for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 22:55:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9F2tW3v025296 for ipv6-archive@odin.ietf.org; Tue, 14 Oct 2003 22:55:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9box-0006Zv-TO for ipv6-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 22:55:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14743 for ; Tue, 14 Oct 2003 22:55:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9bou-0005WW-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 22:55:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9bou-0005WT-00 for ipv6-web-archive@ietf.org; Tue, 14 Oct 2003 22:55:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9boV-0006Tw-Ga; Tue, 14 Oct 2003 22:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9bo4-0006TU-4z for ipv6@optimus.ietf.org; Tue, 14 Oct 2003 22:54:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14736 for ; Tue, 14 Oct 2003 22:54:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9bo0-0005WK-00 for ipv6@ietf.org; Tue, 14 Oct 2003 22:54:32 -0400 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1A9bnz-0005WH-00 for ipv6@ietf.org; Tue, 14 Oct 2003 22:54:31 -0400 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id WAA06546; Tue, 14 Oct 2003 22:54:28 -0400 (EDT) Date: Tue, 14 Oct 2003 22:54:28 -0400 (EDT) From: Dan Lanciani Message-Id: <200310150254.WAA06546@ss10.danlan.com> To: ipv6@ietf.org Subject: Re: IPv6 adoption behavior Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Keith Moore wrote: |On Tue, 14 Oct 2003 18:11:24 -0400 (EDT) |Dan Lanciani wrote: | |> IPv6 offers absolutely nothing as a |> replacement for NAT's primary function: isolation of the customer network |> from the (typically business-driven) address policies of the service |> provider(e.g., cost, limits on number and stability, etc.). | |NAT isolates customer networks from upstream address policies only by severely |limiting their functionality. Clearly many users care a lot about the isolation and little about the functionality that you believe is being limited. Rather than trying to convince them that they are wrong for wanting to keep their networks running, how about proposing a way to achieve that isolation without limiting the functionality that you want to preserve? If we cannot implement such a solution (and I doubt that we can since it changes the economics of address rentals), do you really think it is reasonable to demand that everyone give up what they need to have what you think they should want? |The functionality of an IPv6 network is better |than that of a NATted IPv4 network even if the IPv6 address changes |frequently. To paraphrase your comments on host-based source routing, the functionality of an IPv6 network whose addresses are changing frequently enough to make its users' applications unusable is nil. Conjecture: ``frequently enough'' likely isn't all that frequently. We just don't have the tools and models for dealing with addresses changing out from under applications. Even if we did, I've yet to see any commitment from apps folks that they would be willing to deal with such changing addresses. And I think that dealing with changing addresses is a much harder problem for an application than dealing with scoped addresses. It's also something that will have to be handled by all applications, not just those using referals. |However I agree that we need to define some expectations about address |stability - both to serve as models for service agreements between customers |and ISPs, and to serve as guidance for applications developers. Ultimately, I believe that stability is a binary property. Either someone other than the owner of the network can change the address or they can't. Anything that depends on the provider (and its provider and so on) to neither screw up nor decide to change terms for economic reasons is not stability. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 00:43:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16924 for ; Wed, 15 Oct 2003 00:43:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9dVL-00049y-IC for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 00:43:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9F4hNAS015986 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 00:43:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9dVL-00049l-BX for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 00:43:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16898 for ; Wed, 15 Oct 2003 00:43:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9dVI-0006JF-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 00:43:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9dVI-0006JC-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 00:43:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9dV0-00045n-DS; Wed, 15 Oct 2003 00:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9dU9-00043x-Qk for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 00:42:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16856 for ; Wed, 15 Oct 2003 00:41:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9dU7-0006Hs-00 for ipv6@ietf.org; Wed, 15 Oct 2003 00:42:07 -0400 Received: from mail002.readyhosting.com ([63.119.175.16]) by ietf-mx with esmtp (Exim 4.12) id 1A9dU6-0006Hb-00 for ipv6@ietf.org; Wed, 15 Oct 2003 00:42:06 -0400 Received: from yhhan2 [202.20.193.254] by mail002.readyhosting.com (SMTPD32-6.06) id AF3B48D013C; Tue, 14 Oct 2003 23:38:19 -0500 Message-ID: <013d01c392d6$a0a37770$f12f024b@yhhan2> From: "Youn-Hee Han" To: Subject: just test... please ignore this Date: Wed, 15 Oct 2003 13:41:38 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0138_01C39322.0EFDC8B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0138_01C39322.0EFDC8B0 Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: base64 dGVzdA== ------=_NextPart_000_0138_01C39322.0EFDC8B0 Content-Type: text/html; charset="utf-7" Content-Transfer-Encoding: base64 Ky92OEFQQUFoLURPQ1RZUEUgSFRNTCBQVUJMSUMgK0FDSS0tLy9XM0MvL0RURCBIVE1MIDQuMCBU cmFuc2l0aW9uYWwvL0VOK0FDSUFQZy0NCitBRHctSFRNTCtBRDRBUEEtSEVBRCtBRDQtDQorQUR3 LU1FVEEgaHR0cC1lcXVpditBRDAtQ29udGVudC1UeXBlIGNvbnRlbnQrQUQwQUlnLXRleHQvaHRt bCtBRHMtIGNoYXJzZXQrQUQwLXV0Zi03K0FDSUFQZy0NCitBRHctTUVUQSBjb250ZW50K0FEMEFJ Zy1NU0hUTUwgNi4wMC4yODAwLjEyMjYrQUNJLSBuYW1lK0FEMC1HRU5FUkFUT1IrQUQ0LQ0KK0FE dy1TVFlMRStBRDRBUEEtL1NUWUxFK0FENC0NCitBRHctL0hFQUQrQUQ0LQ0KK0FEdy1CT0RZIGJn Q29sb3IrQUQwQUl3LWZmZmZmZitBRDQtDQorQUR3LURJVitBRDRBUEEtRk9OVCBzaXplK0FEMC0y K0FENC10ZXN0K0FEdy0vRk9OVCtBRDRBUEEtL0RJVitBRDRBUEEtL0JPRFkrQUQ0QVBBLS9IVE1M K0FENC0NCg== ------=_NextPart_000_0138_01C39322.0EFDC8B0-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 02:15:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00431 for ; Wed, 15 Oct 2003 02:15:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9evb-0001lT-B5 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 02:14:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9F6EZTW006775 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 02:14:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9evZ-0001lC-9M for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 02:14:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29938 for ; Wed, 15 Oct 2003 02:14:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9evV-000787-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 02:14:29 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9evV-000784-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 02:14:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ev5-0001Zu-HP; Wed, 15 Oct 2003 02:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9euu-0001XS-HE for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 02:13:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29332 for ; Wed, 15 Oct 2003 02:13:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9euq-000779-00 for ipv6@ietf.org; Wed, 15 Oct 2003 02:13:48 -0400 Received: from batch15.uni-muenster.de ([128.176.188.113]) by ietf-mx with esmtp (Exim 4.12) id 1A9eup-00076u-00 for ipv6@ietf.org; Wed, 15 Oct 2003 02:13:47 -0400 Received: from zivlnx01.uni-muenster.de (ZIVLNX01.UNI-MUENSTER.DE [128.176.188.24]) by batch15.uni-muenster.de (Postfix) with ESMTP id A8188131D; Wed, 15 Oct 2003 08:13:08 +0200 (MES) Received: from localhost (localhost.uni-muenster.de [127.0.0.1]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id 73A9F312D7; Wed, 15 Oct 2003 08:13:44 +0200 (CEST) Received: from kummerog.uni-muenster.de (KUMMEROG.UNI-MUENSTER.DE [128.176.184.156]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id BA622312BD; Wed, 15 Oct 2003 08:13:43 +0200 (CEST) Subject: Re: IPv6 adoption behavior From: "Christian Strauf (JOIN)" To: Fred Baker Cc: Michel Py , Mark Smith , ipv6@ietf.org In-Reply-To: <6.0.0.22.2.20031014102300.044542d8@mira-sjc5-b.cisco.com> References: <6.0.0.22.2.20031014102300.044542d8@mira-sjc5-b.cisco.com> Content-Type: text/plain; charset=ISO-8859-15 Organization: JOIN-Team, WWU-Muenster Message-Id: <1066198423.27651.41.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 15 Oct 2003 08:13:44 +0200 X-Virus-Scanned: by AMaViS 0.3.12pre7 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA29334 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > My crystal ball is as cloudy as anyone's. But I would expect that it is= all=20 > a matter of economics.=20 I very much agree with you on this point. The problem is that right now it's too hard to sell IPv6 (in the literal sense of the word). I believe that one of the reasons for this is that some features that are theoretically distinctly easier to realise with IPv6, e.g. easier end-to-end security or de-NAT-ification because of bigger address space, need a lot of improvement and development to be deployable in a commercial surrounding. E.g., unless there are (simplified speaking) stable and good interoperable IPsec implementations for improved end-to-end security and a good number of firewalls with stateful filtering to really replace current v4 solutions that employ NAT, it will be difficult to convince sales people that there actually is something about IPv6 that can be sold as a feature that makes it better than IPv4 (if we leave aside IPv4 address exhaustion for the moment). It would make sense to look into which implementations need to be programmed first to create a market for IPv6 and to write proposals on what kind of implementations that might be. However, I believe that this is not the IETF's task, or is it? Cheers, Christian --=20 JOIN - IP Version 6 in the WiN Christian Strauf A DFN project Westf=E4lische Wilhelms-Universit=E4t M=FC= nster http://www.join.uni-muenster.de Zentrum f=FCr Informationsverarbeitung Team: join@uni-muenster.de R=F6ntgenstrasse 9-13 Priv: strauf@uni-muenster.de D-48149 M=FCnster / Germany GPG-/PGP-Key-ID: 1DFAAA9A Fon: +49 251 83 31639, Fax: +49 251 83 31= 653 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 03:16:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18093 for ; Wed, 15 Oct 2003 03:16:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ftY-0007Z3-4L for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 03:16:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9F7GVNU029071 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 03:16:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ftW-0007Yn-4f for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 03:16:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18056 for ; Wed, 15 Oct 2003 03:16:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9ftT-0000Kp-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 03:16:27 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9ftT-0000Km-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 03:16:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ft6-0007RR-6J; Wed, 15 Oct 2003 03:16:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9fsQ-0007OV-7b for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 03:15:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18027 for ; Wed, 15 Oct 2003 03:15:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9fsN-0000KL-00 for ipv6@ietf.org; Wed, 15 Oct 2003 03:15:19 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1A9fsN-0000K5-00 for ipv6@ietf.org; Wed, 15 Oct 2003 03:15:19 -0400 Subject: RE: IPv6 adoption behavior MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Oct 2003 00:14:50 -0700 Content-class: urn:content-classes:message Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: IPv6 adoption behavior thread-index: AcOS45Be4Vw/FIswT0CUxdbmk6idPgAA9HyQ From: "Michel Py" To: "Christian Strauf \(JOIN\)" , "Fred Baker" Cc: "Mark Smith" , Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Christian Strauf wrote: > it will be difficult to convince sales people that there actually > is something about IPv6 that can be sold as a feature that makes > it better than IPv4 (if we leave aside IPv4 address exhaustion > for the moment). I'm not so sure that's were the problem really is. Salesdroids would sell their mother and their shirt if need be; the issue is that they are typically paid on commission; if IPv6 does not sell they make no money therefore they'll be back quickly selling IPv4. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 05:14:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21510 for ; Wed, 15 Oct 2003 05:14:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9hjO-0007AU-4e for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 05:14:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9F9EAxk027554 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 05:14:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9hjM-0007AL-TI for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 05:14:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21484 for ; Wed, 15 Oct 2003 05:13:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9hjJ-0001cs-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 05:14:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9hjJ-0001cp-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 05:14:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9hjG-00076g-DQ; Wed, 15 Oct 2003 05:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9hiW-00075s-PW for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 05:13:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21479 for ; Wed, 15 Oct 2003 05:13:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9hiT-0001bt-00 for ipv6@ietf.org; Wed, 15 Oct 2003 05:13:13 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1A9hiS-0001bq-00 for ipv6@ietf.org; Wed, 15 Oct 2003 05:13:12 -0400 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9F9Cxed082827; Wed, 15 Oct 2003 11:13:00 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20031014234336.33b20bf5.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> References: <20031014234336.33b20bf5.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org From: Iljitsch van Beijnum Subject: Re: Will IPv4 be formally deprecated when IPv6 is good enough ? Date: Wed, 15 Oct 2003 11:12:59 +0200 To: Mark Smith X-Mailer: Apple Mail (2.604) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 14 okt 2003, at 16:13, Mark Smith wrote: > A little later, it occured to me that maybe what the market might be > missing is a statement from the IETF, IESG and/or IAB, that IPv6 is > now *ready*, and can be deployed in production via the available > transition mechanisms, slowly replacing IPv4 (+ NAT). Maybe the market > is really just waiting for the engineers behind IPv6 to say "it's > basically finished, its now ready for you to use, pending your > applications being ported". But unfortunately, IPv6 _isn't_ ready. See the site local debate. See the flowlabel goings-on. See the multihoming problem. I'm not sure what the status of DHCPv6 is except that I haven't seen it in the wild anywhere yet. And there are no reasonable other ways to dynamically find DNS servers in IPv6. That's all protocol stuff. Hopefully all of this can be fixed in the not too distant future. But there there is another extremely important issue that (in my not so humble opinion) must absolutely be fixed before making any such statement: the DNS. It is currently impossible to resolve DNS names over IPv6 transport, because the roots don't support IPv6 transport, none of the major gTLDs supports IPv6 transport and very few, if any, TLDs support IPv6 glue records for delegated domains. I think we need IPv6 roots and at least one significant gTLD that fully supports IPv6, so that two IPv6-only sites can resolve each other's names and communicate without any IPv4 dependencies. We also need IPv6-only hosts to dynamically find DNS servers (or define some site anycast DNS addresses that can be hardcoded), have addresses that remain present/stable regardless of ISP connectivity. Some good multihoming wouldn't suck either, but since most end-users don't multihome this doesn't have to be a hard requirement. But with this other stuff in place such an announcement would be possible. > * configuration ease - The protocol must permit easy and largely > distributed configuration and operation. Automatic configuration > of > hosts and routers is required. This test fails because of lack of dynamic DNS discovery. > * mobility - The protocol must support mobile hosts, networks and > internetworks. Hm... > That brings to my mind two questions > a) Is IPv4 going to be formally deprecated when IPv6 is good enough? > If so, are the related IPv4 NAT RFCs also going to be deprecated at > that time ? Would it be a smart move to deprecate something that 100% of the systems connected to the internet use? > b) Is IPv6 good enough yet ? Not yet... but we're making progress. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 06:04:15 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23086 for ; Wed, 15 Oct 2003 06:04:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9iVW-0002IV-Sj for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 06:03:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FA3siW008824 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 06:03:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9iVW-0002IF-Np for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 06:03:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23059 for ; Wed, 15 Oct 2003 06:03:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9iVS-0002Dx-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 06:03:50 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9iVS-0002Du-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 06:03:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9iUg-00027w-K5; Wed, 15 Oct 2003 06:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9iUc-00027e-1J for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 06:02:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23052 for ; Wed, 15 Oct 2003 06:02:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9iUY-0002DW-00 for ipv6@ietf.org; Wed, 15 Oct 2003 06:02:54 -0400 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1A9iUX-0002DT-00 for ipv6@ietf.org; Wed, 15 Oct 2003 06:02:53 -0400 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 17658830F; Wed, 15 Oct 2003 12:02:48 +0200 (CEST) From: "Jeroen Massar" To: "'Iljitsch van Beijnum'" Cc: Subject: RE: Will IPv4 be formally deprecated when IPv6 is good enough ? Date: Wed, 15 Oct 2003 12:02:50 +0200 Organization: Unfix Message-ID: <00b101c39303$7e3f04b0$210d640a@unfix.org> 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.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Iljitsch van Beijnum wrote: > On 14 okt 2003, at 16:13, Mark Smith wrote: > > > A little later, it occured to me that maybe what the market might be > > missing is a statement from the IETF, IESG and/or IAB, that IPv6 is > > now *ready*, and can be deployed in production via the available > > transition mechanisms, slowly replacing IPv4 (+ NAT). Maybe the market > > is really just waiting for the engineers behind IPv6 to say "it's > > basically finished, its now ready for you to use, pending your > > applications being ported". > > But unfortunately, IPv6 _isn't_ ready. See the site local debate. See > the flowlabel goings-on. See the multihoming problem. I'm not > sure what the status of DHCPv6 is except that I haven't seen it in the wild > anywhere yet. There is at least a Linux implementation in the wild: http://sourceforge.net/projects/dhcpv6 And there is a quite-empty page at http://www.dhcpv6.org > And there are no reasonable other ways to dynamically > find DNS servers in IPv6. I would really like to see a 'default' IP address for DNS. Anycast comes to mind here btw... > That's all protocol stuff. Hopefully all of > this can be fixed in the not too distant future. But there there is > another extremely important issue that (in my not so humble opinion) > must absolutely be fixed before making any such statement: > the DNS. It > is currently impossible to resolve DNS names over IPv6 transport, > because the roots don't support IPv6 transport, none of the > major gTLDs supports IPv6 transport and very few, if any, TLDs > support IPv6 glue records for delegated domains. Apparently there is work being done on this, but it is not very public. We have www.rs.net providing this for some time, but unfortunatly it has some issues: it doesn't allow 'access' to non-IPv6 capable domains and there isn't a european part of that deployment; yet, I understood. > Some good multihoming wouldn't suck either, but since most end-users don't > multihome this doesn't have to be a hard requirement I would really like to see this, but indeed it isn't a showstopper. It is a requirement for some "hosters" though, but as can be seen from the TLA allocation lists even 'smaller' ISP's get a TLA so that should not be a problem either. Basically if one can say they have 200 clients they have a done deal. Thus the only requirement for multihoming is for endusers, even if those are very big organisations. As IPv6 deployment isn't that far (yet) they probably can't find two uplinks at the moment anyways. > > b) Is IPv6 good enough yet ? > > Not yet... but we're making progress. Seeing that usage and traffic at tunnelbrokers is growing I think it is really catching on. There are two issues though that are mostly a chicken and egg problem: - Hosters don't support it because clients don't have it -> money - Clients can't use it because Hosters don't support it. Client access and for some also hosting is taken care of by using tunnelbrokers and other transition mechanisms. ISP's should start enabling IPv6 on their native networks where possible and start providing servers with IPv6 connectivity. Then it is at least possible for clients to use it. RIPE got a big 'awww' when they enabled their whois service to support IPv6 as to the number of requests that suddenly started to come in over IPv6 :) So kick your ISP, access and hosting, to get doing IPv6 and if the access to that ISP can't provide native IPv6 ask them to set up a tunnelbroker system, 6to4 relay etc for solving that problem. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP40bRCmqKFIzPnwjEQJ+CgCePg8NuaQVdeAwfJTeYsJWmszrmpcAnRrx Pp3fcBn6Z8+/OhXdojHhlMVO =t+x3 -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 06:11:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23288 for ; Wed, 15 Oct 2003 06:11:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9icZ-0003FJ-Gb for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 06:11:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FABB3s012471 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 06:11:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9icX-0003F4-UM for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 06:11:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23240 for ; Wed, 15 Oct 2003 06:11:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9icU-0002Hl-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 06:11:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9icT-0002Hi-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 06:11:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9icR-0003BN-Le; Wed, 15 Oct 2003 06:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9icA-0003AS-Jc for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 06:10:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23230 for ; Wed, 15 Oct 2003 06:10:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9ic6-0002HR-00 for ipv6@ietf.org; Wed, 15 Oct 2003 06:10:42 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1A9ic5-0002HO-00 for ipv6@ietf.org; Wed, 15 Oct 2003 06:10:42 -0400 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9FAAded083479; Wed, 15 Oct 2003 12:10:39 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20031014153258.GA39179@sunet.se> References: <20031014234336.33b20bf5.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> <20031014153258.GA39179@sunet.se> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org From: Iljitsch van Beijnum Subject: Re: Will IPv4 be formally deprecated when IPv6 is good enough ? Date: Wed, 15 Oct 2003 12:10:39 +0200 To: Mans Nilsson X-Mailer: Apple Mail (2.604) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 14 okt 2003, at 17:32, Mans Nilsson wrote: >> b) Is IPv6 good enough yet ? > I think so. There are valid concerns on two things; multihoming and > address allocation procedures. There seems to be strong forces among > the > researchers and vendors advocting that we halt and wait for the > Grail of multihoming while we at the same time work very hard in > preventing > people from getting allocations, to preserve address space and keep > the routing table size down. A very good property of IPv6 is that we get to avoid some of the mistakes that were made with IPv4. One of those mistakes was giving out addresses in ways that didn't scale. History teaches us that once something like this happens the cats don't want to be herded back into the bag, to abuse some metaphors here. > I think the address allocation problem is based on v4 habits. v6 > is abundant. We need it to be available. Nothing will happen until > people can get real allocations with relative ease, not so easy > that nuisance allocations will occur, but almost. Give every AS > number holder a /32 or something, and watch deployment speed up. There are now less than 35000 free AS numbers. If such a policy would be adopted there would be a huge land rush, depleting the AS number supply and forever polluting the IPv6 routing table with 64000 or so routes, most of which don't need to be there. The fact that this also uses up 0.0016 percent of the IPv6 address space isn't a significant issue, of course. > "Small ASes (those who originate only a few prefixes into > the global routing system) do not contribute more than their > fair share of either route entries or churn to the global > routing system." > Thus, if most ASen were able to contain all their hosts within one > single /32 per AS, we would see limited routing table growth for > some years, during which there would be time to develop more > sophisticated routing paradigms, if operational experience dictated > such a need was indeed present. In IPv4 today multihoming is throttled by lack of routable address space. Without a /24 you don't get to multihome, and with a /24 - /21 you're never sure if you're going to be filtered. In IPv6 those would all be /48s that everyone can get so it's likely that growth in multihoming is going to be higher than what we've seen before. Also note that just keeping it below the level of Moore's Law (60% per year) isn't enough as routing table processing scales worse than linear at O = n.log(n) Iljitsch van Beijnum -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 06:25:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23655 for ; Wed, 15 Oct 2003 06:25:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9iq7-00047c-Rm for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 06:25:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FAPBn5015838 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 06:25:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9iq7-00047N-Mk for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 06:25:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23627 for ; Wed, 15 Oct 2003 06:25:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9iq3-0002RY-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 06:25:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9iq3-0002RV-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 06:25:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ipy-00043H-MU; Wed, 15 Oct 2003 06:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ip1-00042S-HL for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 06:24:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23591 for ; Wed, 15 Oct 2003 06:23:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9iox-0002Qj-00 for ipv6@ietf.org; Wed, 15 Oct 2003 06:23:59 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1A9iow-0002Qg-00 for ipv6@ietf.org; Wed, 15 Oct 2003 06:23:59 -0400 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9FANjed083630; Wed, 15 Oct 2003 12:23:45 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <6.0.0.22.2.20031014102300.044542d8@mira-sjc5-b.cisco.com> References: <6.0.0.22.2.20031014102300.044542d8@mira-sjc5-b.cisco.com> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "" From: Iljitsch van Beijnum Subject: Re: IPv6 adoption behavior Date: Wed, 15 Oct 2003 12:23:45 +0200 To: Fred Baker X-Mailer: Apple Mail (2.604) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 14 okt 2003, at 19:52, Fred Baker wrote: > IPv4 address exhaustion will never occur. Yes, it would be interesting to see the justification needed in order to be assigned the last remaining IPv4 address. :-) And obviously at some point people are going to stop throwing around subnets but tunnel individual IPv4 addresses (possibly over IPv6) so each and every address can be made useful. [...] > The question(s) that raises are "will > ever occur, and if so, when?" > My crystal ball is as cloudy as anyone's. But I would expect that it > is all a matter of economics. And we all know economics is just better paid psychology. At some point people are going to act on their expectations of what others are going to do. Look at the DoD move: they are now requiring v6 because they expect the market to pick it up and they don't want to be left behind. The market sees the DoD requires it so they start to pick up IPv6 too... -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 07:40:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25524 for ; Wed, 15 Oct 2003 07:40:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9k0h-0008Dr-1p for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 07:40:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FBeAR8031601 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 07:40:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9k0f-0008Da-Cs for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 07:40:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25496 for ; Wed, 15 Oct 2003 07:40:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9k0d-0003Dt-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 07:40:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9k0c-0003Dq-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 07:40:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9jza-00083Z-LX; Wed, 15 Oct 2003 07:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9jzH-00082q-TU for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 07:38:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25478 for ; Wed, 15 Oct 2003 07:38:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9jzH-0003DO-00 for ipv6@ietf.org; Wed, 15 Oct 2003 07:38:43 -0400 Received: from radiosixten.pilsnet.sunet.se ([192.36.125.116] helo=slimsixten.besserwisser.org ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A9jzG-0003DL-00 for ipv6@ietf.org; Wed, 15 Oct 2003 07:38:42 -0400 Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.6) with ESMTP id h9FBcrYn004101; Wed, 15 Oct 2003 13:38:54 +0200 (CEST) Date: Wed, 15 Oct 2003 13:38:52 +0200 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: Iljitsch van Beijnum cc: "ipv6@ietf.org" Subject: Re: Will IPv4 be formally deprecated when IPv6 is good enough ? Message-ID: <707920000.1066217932@localhost.besserwisser.org> In-Reply-To: References: <20031014234336.33b20bf5.ipv6@c753173126e0bc8b057a22829880cf26.no sense.org> <20031014153258.GA39179@sunet.se> X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========2248443427==========" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --==========2248443427========== Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Wednesday, October 15, 2003 12:10:39 +0200 Iljitsch van Beijnum wrote: > A very good property of IPv6 is that we get to avoid some of the mistakes > that were made with IPv4. One of those mistakes was giving out addresses > in ways that didn't scale. History teaches us that once something like > this happens the cats don't want to be herded back into the bag, to abuse > some metaphors here. Agree. But: The main problem is that people and organisations in the sunrise phase were given too small allocations, leading to disjunct allocations and a mess in the routing table. If we give small organisations a /32 they won't need another prefix for the forseeable future. This "wasteful" policy was not possible in v4, but now it is. So, I concur that there are things to be learnt from v4.=20 > There are now less than 35000 free AS numbers. If such a policy would be > adopted there would be a huge land rush, depleting the AS number supply > and forever polluting the IPv6 routing table with 64000 or so routes, > most of which don't need to be there. The fact that this also uses up > 0.0016 percent of the IPv6 address space isn't a significant issue, of > course. The fix for this is 32-bit AS numbers. Those 35000 ASen will suffice while we look at multihoming problems and routing table growth. Providing we get people to use v6 instead of talking about it here -- we can't know unless we test this, and the experience gained is worth some of the risk.=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========2248443427========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE/jTHN02/pMZDM1cURAvF/AKCmzelYHBVqNW+Cdb8Ej8MtghCaxgCfb7eQ O2yF0SfWntsC/tGcrz1wioE= =ZNP3 -----END PGP SIGNATURE----- --==========2248443427==========-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 07:58:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26016 for ; Wed, 15 Oct 2003 07:58:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kHZ-0000sq-Mg for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 07:57:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FBvbv9003389 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 07:57:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kHZ-0000sa-3J for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 07:57:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25940 for ; Wed, 15 Oct 2003 07:57:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9kHY-0003P0-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 07:57:36 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9kHX-0003Op-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 07:57:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kGz-0000bJ-I9; Wed, 15 Oct 2003 07:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kGe-0000aA-0U for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 07:56:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25894 for ; Wed, 15 Oct 2003 07:56:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9kGd-0003Nl-00 for ipv6@ietf.org; Wed, 15 Oct 2003 07:56:39 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9kGc-0003NY-00 for ipv6@ietf.org; Wed, 15 Oct 2003 07:56:38 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9FBtw520734; Wed, 15 Oct 2003 14:55:59 +0300 Date: Wed, 15 Oct 2003 14:55:58 +0300 (EEST) From: Pekka Savola To: =?ISO-8859-1?Q?M=E5ns_Nilsson?= cc: Iljitsch van Beijnum , "ipv6@ietf.org" Subject: Re: Will IPv4 be formally deprecated when IPv6 is good enough ? In-Reply-To: <707920000.1066217932@localhost.besserwisser.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by netcore.fi id h9FBtw520734 Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On Wed, 15 Oct 2003, M=E5ns Nilsson wrote: [...] > > There are now less than 35000 free AS numbers. If such a policy would= be > > adopted there would be a huge land rush, depleting the AS number supp= ly > > and forever polluting the IPv6 routing table with 64000 or so routes, > > most of which don't need to be there. The fact that this also uses up > > 0.0016 percent of the IPv6 address space isn't a significant issue, o= f > > course. >=20 > The fix for this is 32-bit AS numbers. Those 35000 ASen will suffice wh= ile > we look at multihoming problems and routing table growth. Providing we = get > people to use v6 instead of talking about it here -- we can't know unle= ss > we test this, and the experience gained is worth some of the risk.=20 Well, my personal take is that if we need 32-bit AS numbers, we have=20 failed. Failed how? Failed to produce a multihoming solution for smaller enterprises which would not need an AS number otherwise, but whose about only (clear) optio= n is to go and get an AS number for their site multihoming purposes. --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 08:05:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26249 for ; Wed, 15 Oct 2003 08:05:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kOv-0001Lx-SV for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 08:05:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FC5DdT005195 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 08:05:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kOv-0001Lc-L8 for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 08:05:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26212 for ; Wed, 15 Oct 2003 08:05:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9kOu-0003Uj-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 08:05:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9kOt-0003Ug-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 08:05:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kOk-0001Hn-Lh; Wed, 15 Oct 2003 08:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kOQ-0001HC-Dt for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 08:04:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26187 for ; Wed, 15 Oct 2003 08:04:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9kOP-0003UF-00 for ipv6@ietf.org; Wed, 15 Oct 2003 08:04:41 -0400 Received: from radiosixten.pilsnet.sunet.se ([192.36.125.116] helo=slimsixten.besserwisser.org ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A9kOO-0003UC-00 for ipv6@ietf.org; Wed, 15 Oct 2003 08:04:40 -0400 Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.6) with ESMTP id h9FC4sYn027418; Wed, 15 Oct 2003 14:04:56 +0200 (CEST) Date: Wed, 15 Oct 2003 14:04:53 +0200 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: Pekka Savola cc: Iljitsch van Beijnum , "ipv6@ietf.org" Subject: Re: Will IPv4 be formally deprecated when IPv6 is good enough ? Message-ID: <765050000.1066219493@localhost.besserwisser.org> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========2068665737==========" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --==========2068665737========== Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Wednesday, October 15, 2003 14:55:58 +0300 Pekka Savola wrote: > Failed to produce a multihoming solution for smaller enterprises which > would not need an AS number otherwise, but whose about only (clear) = option > is to go and get an AS number for their site multihoming purposes. I agree. This must be fixed.=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========2068665737========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE/jTfm02/pMZDM1cURAo70AJwMF7ejTsCExo2W+E678nPPS98YwwCeOFq+ DsWy0V3GFdq9wGmo8bjpgqY= =WLbX -----END PGP SIGNATURE----- --==========2068665737==========-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 08:38:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27360 for ; Wed, 15 Oct 2003 08:38:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kuQ-0003Cx-CN for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 08:37:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FCbkZR012317 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 08:37:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kuP-0003CS-Kw for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 08:37:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27295 for ; Wed, 15 Oct 2003 08:37:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9kuO-0003uL-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 08:37:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9kuN-0003uI-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 08:37:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ktj-0002po-56; Wed, 15 Oct 2003 08:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ktX-0002oq-5y for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 08:36:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27249 for ; Wed, 15 Oct 2003 08:36:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9ktV-0003t7-00 for ipv6@ietf.org; Wed, 15 Oct 2003 08:36:49 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1A9ktU-0003sd-00 for ipv6@ietf.org; Wed, 15 Oct 2003 08:36:49 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HMS00G04TOG6E@mailout2.samsung.com> for ipv6@ietf.org; Wed, 15 Oct 2003 21:36:16 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HMS00DIZTOGQG@mailout2.samsung.com> for ipv6@ietf.org; Wed, 15 Oct 2003 21:36:16 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HMS00BA2TOFZ7@mmp1.samsung.com> for ipv6@ietf.org; Wed, 15 Oct 2003 21:36:16 +0900 (KST) Date: Wed, 15 Oct 2003 21:36:30 +0900 From: Soohong Daniel Park Subject: RE: Will IPv4 be formally deprecated when IPv6 is good enough ? In-reply-to: <00b101c39303$7e3f04b0$210d640a@unfix.org> To: "'Jeroen Massar'" , "'Iljitsch van Beijnum'" Cc: ipv6@ietf.org Message-id: <003301c39318$f5d74590$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > Client access and for some also hosting is taken care of by > using tunnelbrokers and other transition mechanisms. ISP's > should start enabling IPv6 on their native networks where > possible and start providing servers with IPv6 connectivity. > Then it is at least possible for clients to use it. > RIPE got a big 'awww' when they enabled their whois service > to support IPv6 as to the number of requests that suddenly > started to come in over IPv6 :) > > So kick your ISP, access and hosting, to get doing IPv6 and > if the access to that ISP can't provide native IPv6 ask them > to set up a tunnelbroker system, 6to4 relay etc for solving > that problem. I guess it is one of v6ops role ISP design team is trying to propose a valuable thing for us.... Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 09:02:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28304 for ; Wed, 15 Oct 2003 09:02:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9lHp-0004Rn-Db for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 09:01:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FD1vlg017089 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 09:01:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9lHp-0004RY-0i for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 09:01:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28276 for ; Wed, 15 Oct 2003 09:01:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9lHn-00046N-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 09:01:55 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9lHm-00046K-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 09:01:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9lGw-0004K4-Hy; Wed, 15 Oct 2003 09:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9lGl-0004JQ-EY for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 09:00:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28243 for ; Wed, 15 Oct 2003 09:00:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9lGj-00045c-00 for ipv6@ietf.org; Wed, 15 Oct 2003 09:00:49 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1A9lGj-00045Z-00 for ipv6@ietf.org; Wed, 15 Oct 2003 09:00:49 -0400 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id h9FD0WJ18559; Wed, 15 Oct 2003 06:00:32 -0700 (PDT) From: Bill Manning Message-Id: <200310151300.h9FD0WJ18559@boreas.isi.edu> Subject: Re: stealth v6 DNS In-Reply-To: <00b101c39303$7e3f04b0$210d640a@unfix.org> from Jeroen Massar at "Oct 15, 3 12:02:50 pm" To: jeroen@unfix.org (Jeroen Massar) Date: Wed, 15 Oct 2003 06:00:32 -0700 (PDT) Cc: iljitsch@muada.com, ipv6@ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit % > is currently impossible to resolve DNS names over IPv6 transport, % > because the roots don't support IPv6 transport, none of the % > major gTLDs supports IPv6 transport and very few, if any, TLDs % > support IPv6 glue records for delegated domains. % % Apparently there is work being done on this, but it is not very public. % We have www.rs.net providing this for some time, but unfortunatly % it has some issues: it doesn't allow 'access' to non-IPv6 capable % domains and there isn't a european part of that deployment; yet, I understood. last I checked, sweden was nearly european... :) and rs.net has full access to IPv4 only domains as well. w/in the rs.net testbed all the roots are native IPv6 enabled and there are ~12 TLDs w/ fully IPv6 native servers. all of those TLDs support IPv6 registration for domains. its not quite as bad as you portray, in the testbed. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 09:21:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28704 for ; Wed, 15 Oct 2003 09:21:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9laf-0005Z4-Mw for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 09:21:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FDLPrd021384 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 09:21:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9laf-0005Yp-FG for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 09:21:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28678 for ; Wed, 15 Oct 2003 09:21:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9lad-0004F7-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 09:21:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9lad-0004F4-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 09:21:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9laH-0005RJ-TD; Wed, 15 Oct 2003 09:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9lZX-0005OT-B7 for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 09:20:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28664 for ; Wed, 15 Oct 2003 09:20:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9lZV-0004Et-00 for ipv6@ietf.org; Wed, 15 Oct 2003 09:20:13 -0400 Received: from maya20.nic.fr ([192.134.4.152]) by ietf-mx with esmtp (Exim 4.12) id 1A9lZU-0004Eq-00 for ipv6@ietf.org; Wed, 15 Oct 2003 09:20:13 -0400 Received: from kerkenna.nic.fr (kerkenna.nic.fr [192.134.4.98]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id h9FDKAQW1357176; Wed, 15 Oct 2003 15:20:10 +0200 (CEST) Received: (from souissi@localhost) by kerkenna.nic.fr (8.11.6/8.9.3) id h9FDKAi06145; Wed, 15 Oct 2003 15:20:10 +0200 Date: Wed, 15 Oct 2003 15:20:10 +0200 From: Mohsen Souissi To: Jeroen Massar Cc: "'Iljitsch van Beijnum'" , ipv6@ietf.org Subject: Re: Will IPv4 be formally deprecated when IPv6 is good enough ? Message-ID: <20031015152010.T1587@kerkenna.nic.fr> References: <00b101c39303$7e3f04b0$210d640a@unfix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <00b101c39303$7e3f04b0$210d640a@unfix.org>; from jeroen@unfix.org on Wed, Oct 15, 2003 at 12:02:50PM +0200 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On 15 Oct, Jeroen Massar wrote: [...] | | > That's all protocol stuff. Hopefully all of | > this can be fixed in the not too distant future. But there there is | > another extremely important issue that (in my not so humble opinion) | > must absolutely be fixed before making any such statement: | > the DNS. It | > is currently impossible to resolve DNS names over IPv6 transport, | > because the roots don't support IPv6 transport, none of the | > major gTLDs supports IPv6 transport and very few, if any, TLDs | > support IPv6 glue records for delegated domains. | | Apparently there is work being done on this, but it is not very public. ==> AFNIC (French Registry) has been running an official IPv6-capable name server (ns3.nic.fr) for fr zone (also secondary for a dozzen of other TLDs) since November 2001. AFNIC has been officially making AAA-glue-aware-domain-name-delegations since 1st October 2003 (see the Press-Release http://www.afnic.fr/nouvelles/2003/press-release-afnic-ipv6.pdf, announcement relayed by the IPv6 Task Force mailing-list). More than 70 fr sub-zones are now served by IPv6-capable (IPv6 transport) name servers. | We have www.rs.net providing this for some time, but unfortunatly | it has some issues: it doesn't allow 'access' to non-IPv6 capable | domains and there isn't a european part of that deployment; yet, I | understood. ==> Sounds ver strange... FR zone (it is a European for instance) has been connected to rs.net (formerly OTDR) for more than one year now. Both ns[12].dnssec.nic.fr (which are authoritative for FR zone in rs.net testbed) support both IPv4 and IPv6 transport... -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 09:37:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29143 for ; Wed, 15 Oct 2003 09:37:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9lq1-0006gl-6K for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 09:37:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FDbGj9025710 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 09:37:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9lq0-0006ga-93 for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 09:37:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29118 for ; Wed, 15 Oct 2003 09:37:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9lpy-0004Lm-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 09:37:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9lpy-0004Lj-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 09:37:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9lpm-0006XB-P0; Wed, 15 Oct 2003 09:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9lpO-0006W8-F9 for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 09:36:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29101 for ; Wed, 15 Oct 2003 09:36:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9lpM-0004LT-00 for ipv6@ietf.org; Wed, 15 Oct 2003 09:36:36 -0400 Received: from smtp.dpmms.cam.ac.uk ([131.111.24.3] ident=[exim]) by ietf-mx with esmtp (Exim 4.12) id 1A9lpL-0004LQ-00 for ipv6@ietf.org; Wed, 15 Oct 2003 09:36:36 -0400 Received: from [131.111.24.28] (helo=can.dpmms.cam.ac.uk ident=exim) by smtp.dpmms.cam.ac.uk with esmtp (Exim 4.22) id 1A9lpD-00075i-RA; Wed, 15 Oct 2003 14:36:27 +0100 Received: from john (helo=localhost) by can.dpmms.cam.ac.uk with local-smtp (Exim 3.01 #5) id 1A9lp7-00044R-00; Wed, 15 Oct 2003 14:36:21 +0100 Date: Wed, 15 Oct 2003 14:36:20 +0100 (BST) From: John Gregson To: Michel Py cc: Mark Smith , ipv6@ietf.org Subject: RE: Will IPv4 be formally deprecated when IPv6 is good enough ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-DPMMS-Scan-Signature: e97002d4de897a44edfbf9b631244d12 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Dear Mr Py, Sorry, could you run that past me one more time ..............? J On Tue, 14 Oct 2003, Michel Py wrote: > Mark, > > > Mark Smith wrote: > > a) Is IPv4 going to be formally deprecated when IPv6 is good > > enough? If so, are the related IPv4 NAT RFCs also going to be > > deprecated at that time ? > > IMHO it's not a matter of being good enough, it's a matter of how many > IPv4 hosts are still up. The IETF deprecating IPv4 would not achieve a > lot; there still are people that use an Apple II and even some that are > writing software and design hardware for it. There will be millions of > diehard IPv4 users for a long while. It's a matter when vendors become > to remove IPv4 from stacks, stop supporting IPv4, and when operators > begin to provide IPv6-only service. In my wildest dreams, 10 years at > least; possibly 20 depending on how good the projections in terms of > IPv4 exhaustion are. > > > > b) Is IPv6 good enough yet? > > Not for most. As long as there is no killer app and as long as IPv4 > addresses are available, the investments to move to IPv6 are often not > worth what it brings. > > One of the troubles is that v6 does not even do what v4 does: No private > addresses. No PI addresses. No multihoming. > > The other trouble is that there is no way to do without IPv4 as of > today. In the enterprise, if someone that implements IPv6 today could > plan on IPv4 removal within two or three years, that would be > considered, but operating dual-stack for 10 or 20 years when IPv4 > provides all necessary functions is a waste of money. Keep in mind: > peer-to-peer applications from each desktop to every possible host on > the Internet is not the highest priority of enterprises; it actually is > heavily filtered and firewalled both ingress and egress. As far as the > consumer goes, most on-line gaming and p2p now works across NAT and so > does SIP I hear (with STUN). The only way the consumer is going to > accept IPv6 is when it does not know it's there, which we are not > anywhere close to. > > Michel. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 10:27:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02032 for ; Wed, 15 Oct 2003 10:27:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9mcC-0001Qu-EB for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 10:27:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FER4Yv005509 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 10:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9mcB-0001Qm-Vz for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 10:27:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01958 for ; Wed, 15 Oct 2003 10:26:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9mc9-0004yc-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 10:27:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9mc9-0004yZ-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 10:27:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9mbC-0001G0-J6; Wed, 15 Oct 2003 10:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9maS-0001Ex-5C for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 10:25:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01814 for ; Wed, 15 Oct 2003 10:25:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9maP-0004xH-00 for ipv6@ietf.org; Wed, 15 Oct 2003 10:25:13 -0400 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by ietf-mx with esmtp (Exim 4.12) id 1A9maP-0004xE-00 for ipv6@ietf.org; Wed, 15 Oct 2003 10:25:13 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 8886243A0; Wed, 15 Oct 2003 10:25:11 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 15 Oct 2003 10:25:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Will IPv4 be formally deprecated when IPv6 is good enough ? Date: Wed, 15 Oct 2003 10:25:09 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA124@tayexc13.americas.cpqcorp.net> Thread-Topic: Will IPv4 be formally deprecated when IPv6 is good enough ? Thread-Index: AcOSaTFnM4MktdtFTFayaMamrRPYCwAvj8ug From: "Bound, Jim" To: "Mans Nilsson" , "Mark Smith" Cc: X-OriginalArrivalTime: 15 Oct 2003 14:25:09.0944 (UTC) FILETIME=[23765B80:01C39328] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Question to Chairs: This appears to be a marketing discussion for IPv6 deployment? I = personally think it is useful. But do the chairs want this thread to = continue. Reason, if it is to continue then additional input to = response below would be actual deployment in process that is not waiting = on the multihome solution specifically Military and Telco operations in = the market and then there is the Moonv6 US Network Pilot in process = where 25 vendors are testing products as I type this email. = www.moonv6.com Should this thread continue with the support of the Chairs. My vote is = yes but then it will add a thread that increases mail that does not work = on our engineering problems at hand? But if you say it should stop I am = fine with that too. Just trying to understand what mail flow you want = to support here and for us to be "consistent" with that rule for the WG. Thanks /jim > -----Original Message----- > From: Mans Nilsson [mailto:mansaxel@sunet.se]=20 > Sent: Tuesday, October 14, 2003 11:33 AM > To: Mark Smith > Cc: ipv6@ietf.org > Subject: Re: Will IPv4 be formally deprecated when IPv6 is=20 > good enough ? >=20 >=20 > Subject: Will IPv4 be formally deprecated when IPv6 is good=20 > enough ? Date: Tue, Oct 14, 2003 at 11:43:36PM +0930 Quoting=20 > Mark Smith (ipv6@c753173126e0bc8b057a22829880cf26.nosense.org): > > That brings to my mind two questions > >=20 > > a) Is IPv4 going to be formally deprecated when IPv6 is=20 > good enough?=20 > > If so, are the related IPv4 NAT RFCs also going to be deprecated at=20 > > that time ? >=20 > Do not think so. Maybe it is my limited mind, but I find it=20 > hard not to keep=20 > v4 on some boxes.=20 > =20 > > b) Is IPv6 good enough yet ? >=20 > I think so. There are valid concerns on two things;=20 > multihoming and address allocation procedures. There seems to=20 > be strong forces among the=20 > researchers and vendors advocting that we halt and wait for=20 > the Grail of multihoming while we at the same time work very=20 > hard in preventing=20 > people from getting allocations, to preserve address space=20 > and keep the routing table size down. >=20 > I think the address allocation problem is based on v4 habits.=20 > v6 is abundant. We need it to be available. Nothing will=20 > happen until people can get real allocations with relative=20 > ease, not so easy that nuisance allocations will occur, but=20 > almost. Give every AS number holder a /32 or something, and=20 > watch deployment speed up. >=20 > With multihoming, strongly related to above, I suggest people=20 > cease waiting for the Grail and instead adopt the v4 model,=20 > aided by the=20 > limited growth we'd see if people did not have to patch their=20 > nets together using disjunct prefixes. I believe routing=20 > table growth would be much slower, and there are suggestions=20 > I find supportive of this in some analyses of routing table = characteristics, for example in > = > : >=20 > "Small=20 > ASes (those who originate only a few prefixes=20 > into > the global routing system) do not contribute more than their > fair share of either route entries or churn to the global > routing system."=20 >=20 > Thus, if most ASen were able to contain all their hosts=20 > within one single /32 per AS, we would see limited routing=20 > table growth for some years, during which there would be time=20 > to develop more sophisticated routing paradigms, if=20 > operational experience dictated such a need was indeed present. >=20 > The key words here are "operational experience". We need to=20 > get people=20 > start using v6 for everyday things.=20 >=20 > --=20 > M=E5ns Nilsson Systems Specialist > +46 70 681 7204 KTHNOC > MN1334-RIPE >=20 > This TOPS OFF my partygoing experience! Someone I DON'T LIKE=20 > is talking to me about a HEART-WARMING European film ... >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 10:31:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02297 for ; Wed, 15 Oct 2003 10:31:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9mgD-0001sS-Q0 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 10:31:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FEVDQC007217 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 10:31:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9mgC-0001qR-7x for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 10:31:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02267 for ; Wed, 15 Oct 2003 10:31:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9mg9-000534-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 10:31:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9mg9-000531-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 10:31:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9mg5-0001j5-By; Wed, 15 Oct 2003 10:31:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9mfN-0001gE-W0 for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 10:30:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02228 for ; Wed, 15 Oct 2003 10:30:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9mfL-00052a-00 for ipv6@ietf.org; Wed, 15 Oct 2003 10:30:19 -0400 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by ietf-mx with esmtp (Exim 4.12) id 1A9mfK-00052X-00 for ipv6@ietf.org; Wed, 15 Oct 2003 10:30:18 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id A438192EA; Wed, 15 Oct 2003 10:30:16 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 15 Oct 2003 10:30:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 adoption behavior Date: Wed, 15 Oct 2003 10:30:15 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B049D2203@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 adoption behavior Thread-Index: AcOS47m9iFyV/P8jT5yoRTCH+QCpVwARQeZQ From: "Bound, Jim" To: "Christian Strauf (JOIN)" , "Fred Baker" Cc: "Michel Py" , "Mark Smith" , X-OriginalArrivalTime: 15 Oct 2003 14:30:15.0912 (UTC) FILETIME=[D9D55E80:01C39328] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable It is not an IETF task or in the charter and it is being done elsewhere. = This is not even a technical discussion IMO. /jim > -----Original Message----- > From: Christian Strauf (JOIN) [mailto:ipng@uni-muenster.de]=20 > Sent: Wednesday, October 15, 2003 2:14 AM > To: Fred Baker > Cc: Michel Py; Mark Smith; ipv6@ietf.org > Subject: Re: IPv6 adoption behavior >=20 >=20 > > My crystal ball is as cloudy as anyone's. But I would=20 > expect that it=20 > > is all > > a matter of economics.=20 > I very much agree with you on this point. The problem is that=20 > right now it's too hard to sell IPv6 (in the literal sense of=20 > the word). I believe that one of the reasons for this is that=20 > some features that are theoretically distinctly easier to=20 > realise with IPv6, e.g. easier end-to-end security or=20 > de-NAT-ification because of bigger address space, need a lot=20 > of improvement and development to be deployable in a=20 > commercial surrounding. E.g., unless there are (simplified=20 > speaking) stable and good interoperable IPsec implementations=20 > for improved end-to-end security and a good number of=20 > firewalls with stateful filtering to really replace current=20 > v4 solutions that employ NAT, it will be difficult to=20 > convince sales people that there actually is something about=20 > IPv6 that can be sold as a feature that makes it better than=20 > IPv4 (if we leave aside IPv4 address exhaustion for the moment). >=20 > It would make sense to look into which implementations need=20 > to be programmed first to create a market for IPv6 and to=20 > write proposals on what kind of implementations that might=20 > be. However, I believe that this is not the IETF's task, or is it? >=20 > Cheers, > Christian >=20 > --=20 > JOIN - IP Version 6 in the WiN Christian Strauf > A DFN project Westf=E4lische=20 > Wilhelms-Universit=E4t M=FCnster > http://www.join.uni-muenster.de Zentrum f=FCr Informationsverarbeitung > Team: join@uni-muenster.de R=F6ntgenstrasse 9-13 > Priv: strauf@uni-muenster.de D-48149 M=FCnster / Germany > GPG-/PGP-Key-ID: 1DFAAA9A Fon: +49 251 83 31639, Fax:=20 > +49 251 83 31653 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 11:28:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04722 for ; Wed, 15 Oct 2003 11:28:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nZB-0005Gr-BE for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 11:28:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FFS1a1020260 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 11:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nZA-0005Gh-R6 for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 11:28:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04595 for ; Wed, 15 Oct 2003 11:27:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9nZ9-0005tN-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 11:27:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9nZ9-0005tJ-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 11:27:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nYE-0004xh-GQ; Wed, 15 Oct 2003 11:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nY1-0004wx-CF for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 11:26:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04489 for ; Wed, 15 Oct 2003 11:26:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9nY0-0005rc-00 for ipv6@ietf.org; Wed, 15 Oct 2003 11:26:48 -0400 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1A9nXz-0005rU-00 for ipv6@ietf.org; Wed, 15 Oct 2003 11:26:47 -0400 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 894C4830F; Wed, 15 Oct 2003 17:26:42 +0200 (CEST) From: "Jeroen Massar" To: "'Mohsen Souissi'" , "'Soohong Daniel Park'" , "=?iso-8859-1?Q?'M=E5ns_Nilsson'?=" , "'Bound, Jim'" Cc: Subject: RE: Will IPv4 be formally deprecated when IPv6 is good enough ? Date: Wed, 15 Oct 2003 17:26:40 +0200 Organization: Unfix Message-ID: <006d01c39330$bb724f90$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20031015152010.T1587@kerkenna.nic.fr> Importance: Normal Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- [aggregated mail :)] Mohsen Souissi [mailto:Mohsen.Souissi@nic.fr] wrote: > On 15 Oct, Jeroen Massar wrote: > | Apparently there is work being done on this, but it is not very = public. >=20 > =3D=3D> AFNIC (French Registry) has been running an official = IPv6-capable > name server (ns3.nic.fr) Yup, indeed, sorry I forgot, you have been running it and shouting about for some time already :) But did they put your AAAA as glue in the root already? $ dig @e.root-servers.net ns3.nic.fr any ;; ANSWER SECTION: ns3.nic.fr. 172800 IN A 192.134.0.49 There are quite a lot of deployments who run IPv6 transport capable dns servers, but as long as they are not bound into the root it has little to no sense. > | We have www.rs.net providing this for some time, but unfortunatly > | it has some issues: it doesn't allow 'access' to non-IPv6 capable > | domains and there isn't a european part of that deployment; yet, I > | understood. >=20 > =3D=3D> Sounds ver strange... FR zone (it is a European for instance) = has > been connected to rs.net (formerly OTDR) for more than one year > now. Both ns[12].dnssec.nic.fr (which are authoritative for FR zone in > rs.net testbed) support both IPv4 and IPv6 transport... Indeed, for .fr but not for the root :( What I meant to say that if you use the "IPv6 root" and try to resolve a domain that only has IPv4 DNS servers, eg .com, currently it works = again: com. 518400 IN NS COM-A.ip4.int. COM-A.ip4.int. 518400 IN AAAA But it is flaky and doesn't always work unfortunatly. The not-work part also has to do with the fact that all these servers reside in the US and not in Europe. I understood that Daniel Karrenberg was working on that part though... Soohong Daniel Park wrote: > Jeroen Massar wrote: > > So kick your ISP, access and hosting, to get doing IPv6 and > > if the access to that ISP can't provide native IPv6 ask them > > to set up a tunnelbroker system, 6to4 relay etc for solving > > that problem. >=20 > I guess it is one of v6ops role > ISP design team is trying to propose a valuable thing for us.... We haven't created SixXS for nothing, if an ISP needs a service as said like above they can come to us and we will, in cooperation with them set it up. It is a whitelabel tunnelbroker system, no strings attached, nothing to pay, totally independent, open and certainly not restricted to europe. Jim Bound wrote: > Reason, if it is to continue then additional input to response > below would be actual deployment in process that is not waiting > on the multihome solution specifically Military and Telco > operations in the market and then there is the Moonv6 US Network > Pilot in process where 25 vendors are testing products as I type > this email. www.moonv6.com Neat to see such a project, a shame that I, and possibly others didn't know about it. Speaking of which, isn't there a single mailinglist/informationsource for finding such projects except for googling around ofcourse or checking hs247.com but that doesn't list it either... M=E5ns Nilsson wrote: > The fix for this is 32-bit AS numbers. Those 35000 ASen will > suffice while we look at multihoming problems and routing table > growth. IPv4 is 32bits, are we going to do IPv4 between the ASN's then to keep the routing between ASN's up to scale? 32bit ASN's will also cause a lot of changes in amongst others BGP and internals of routers. IMHO I don't think that is the way to go. The way to go is find a good solution now, there is enough time. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP41nMCmqKFIzPnwjEQL/mQCfaID56o60Hj3llkHpap4IFIXaLG8An2Xg YKMZFgtI/iB3eIdSAr3sjj2i =3Ds1vg -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 11:35:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05087 for ; Wed, 15 Oct 2003 11:35:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ngA-0005wX-6P for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 11:35:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FFZEed022842 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 11:35:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ng9-0005wL-VK for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 11:35:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05053 for ; Wed, 15 Oct 2003 11:35:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9ng8-00063T-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 11:35:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9ng8-00063Q-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 11:35:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nfy-0005nZ-C7; Wed, 15 Oct 2003 11:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nfS-0005mr-6u for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 11:34:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05020 for ; Wed, 15 Oct 2003 11:34:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9nfR-00062L-00 for ipv6@ietf.org; Wed, 15 Oct 2003 11:34:29 -0400 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1A9nfQ-00062H-00 for ipv6@ietf.org; Wed, 15 Oct 2003 11:34:28 -0400 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id E53228311; Wed, 15 Oct 2003 17:34:26 +0200 (CEST) From: "Jeroen Massar" To: "'Bill Manning'" Cc: Subject: RE: stealth v6 DNS Date: Wed, 15 Oct 2003 17:34:26 +0200 Organization: Unfix Message-ID: <007201c39331$d1865c30$210d640a@unfix.org> 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.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200310151300.h9FD0WJ18559@boreas.isi.edu> Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Bill Manning wrote: > % > is currently impossible to resolve DNS names over IPv6 transport, > % > because the roots don't support IPv6 transport, none of the > % > major gTLDs supports IPv6 transport and very few, if any, TLDs > % > support IPv6 glue records for delegated domains. > % > % Apparently there is work being done on this, but it is not very public. > % We have www.rs.net providing this for some time, but unfortunatly > % it has some issues: it doesn't allow 'access' to non-IPv6 capable > % domains and there isn't a european part of that deployment; yet, I understood. > > last I checked, sweden was nearly european... :) Ah so the machine is active, but unfortunatly the routing is still suboptimal with all routes to the NS's going over the US. If wanted, I still am willing to sport a Root DNS in holland for this project, natively connected and such. 300ms on average is not nice performance IMHO. And it can be much better. > and rs.net has full access to IPv4 only domains as well. Yes, I just checked it again and indeed it is working. When that was introduced it was kinda flaky and I got bitten with some mailbounces due to unknown source domains *whistle* But that is one of the reasons that it is a testbed > w/in the rs.net testbed all the roots are native IPv6 enabled > and there are ~12 TLDs w/ fully IPv6 native servers. > all of those TLDs support IPv6 registration for domains. > > its not quite as bad as you portray, in the testbed. That was a momententary snapshot ofcourse and fortunatly we are in a moving world that has changed positively :) Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP41pAimqKFIzPnwjEQKZ7QCbBw8iLg2YVdNVIdm97o791ifEucgAmgPR venNWUQfsVZ6Z4mwV71UDqSD =oXkX -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 11:37:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05192 for ; Wed, 15 Oct 2003 11:37:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nhz-0006LS-59 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 11:37:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FFb7XE024384 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 11:37:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nhy-0006L9-RO for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 11:37:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05164 for ; Wed, 15 Oct 2003 11:36:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9nhx-00065l-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 11:37:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9nhx-00065i-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 11:37:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nht-0006BP-Fg; Wed, 15 Oct 2003 11:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ngy-00069u-Ax for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 11:36:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05117 for ; Wed, 15 Oct 2003 11:35:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9ngx-00064w-00 for ipv6@ietf.org; Wed, 15 Oct 2003 11:36:03 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1A9ngv-00063t-00 for ipv6@ietf.org; Wed, 15 Oct 2003 11:36:02 -0400 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h9FFZTV13563; Wed, 15 Oct 2003 08:35:29 -0700 Received: from innovationslab.net ([63.109.132.2]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h9FFbAtX030187 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 15 Oct 2003 08:37:15 -0700 Message-ID: <3F8D6916.50408@innovationslab.net> Date: Wed, 15 Oct 2003 11:34:46 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bound, Jim" CC: Mans Nilsson , Mark Smith , ipv6@ietf.org Subject: Re: Will IPv4 be formally deprecated when IPv6 is good enough ? References: <9C422444DE99BC46B3AD3C6EAFC9711B047CA124@tayexc13.americas.cpqcorp.net> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B047CA124@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by uillean.fuaim.com id h9FFZTV13563 Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable In my opinion, I don't see a problem with this thread. I believe it is useful to see how v6 is being deployed or reasons why it is not being deployed. So, as long as it remains civil and doesn't degrade into a re-hash of past arguments, I don't see a problem with it continuing. Regards, Brian Bound, Jim wrote: > Question to Chairs: >=20 > This appears to be a marketing discussion for IPv6 deployment? I perso= nally think it is useful. But do the chairs want this thread to continue= . Reason, if it is to continue then additional input to response below w= ould be actual deployment in process that is not waiting on the multihome= solution specifically Military and Telco operations in the market and th= en there is the Moonv6 US Network Pilot in process where 25 vendors are t= esting products as I type this email. www.moonv6.com >=20 > Should this thread continue with the support of the Chairs. My vote is= yes but then it will add a thread that increases mail that does not work= on our engineering problems at hand? But if you say it should stop I am= fine with that too. Just trying to understand what mail flow you want t= o support here and for us to be "consistent" with that rule for the WG. >=20 > Thanks > /jim >=20 >=20 >>-----Original Message----- >>From: Mans Nilsson [mailto:mansaxel@sunet.se]=20 >>Sent: Tuesday, October 14, 2003 11:33 AM >>To: Mark Smith >>Cc: ipv6@ietf.org >>Subject: Re: Will IPv4 be formally deprecated when IPv6 is=20 >>good enough ? >> >> >>Subject: Will IPv4 be formally deprecated when IPv6 is good=20 >>enough ? Date: Tue, Oct 14, 2003 at 11:43:36PM +0930 Quoting=20 >>Mark Smith (ipv6@c753173126e0bc8b057a22829880cf26.nosense.org): >> >>>That brings to my mind two questions >>> >>>a) Is IPv4 going to be formally deprecated when IPv6 is=20 >> >>good enough?=20 >> >>>If so, are the related IPv4 NAT RFCs also going to be deprecated at=20 >>>that time ? >> >>Do not think so. Maybe it is my limited mind, but I find it=20 >>hard not to keep=20 >>v4 on some boxes.=20 >>=20 >> >>>b) Is IPv6 good enough yet ? >> >>I think so. There are valid concerns on two things;=20 >>multihoming and address allocation procedures. There seems to=20 >>be strong forces among the=20 >>researchers and vendors advocting that we halt and wait for=20 >>the Grail of multihoming while we at the same time work very=20 >>hard in preventing=20 >>people from getting allocations, to preserve address space=20 >>and keep the routing table size down. >> >>I think the address allocation problem is based on v4 habits.=20 >>v6 is abundant. We need it to be available. Nothing will=20 >>happen until people can get real allocations with relative=20 >>ease, not so easy that nuisance allocations will occur, but=20 >>almost. Give every AS number holder a /32 or something, and=20 >>watch deployment speed up. >> >>With multihoming, strongly related to above, I suggest people=20 >>cease waiting for the Grail and instead adopt the v4 model,=20 >>aided by the=20 >>limited growth we'd see if people did not have to patch their=20 >>nets together using disjunct prefixes. I believe routing=20 >>table growth would be much slower, and there are suggestions=20 >>I find supportive of this in some analyses of routing table characteris= tics, for example in > > = : >> >> "Small=20 >>ASes (those who originate only a few prefixes=20 >>into >> the global routing system) do not contribute more than their >> fair share of either route entries or churn to the global >> routing system."=20 >> >>Thus, if most ASen were able to contain all their hosts=20 >>within one single /32 per AS, we would see limited routing=20 >>table growth for some years, during which there would be time=20 >>to develop more sophisticated routing paradigms, if=20 >>operational experience dictated such a need was indeed present. >> >>The key words here are "operational experience". We need to=20 >>get people=20 >>start using v6 for everyday things.=20 >> >>--=20 >>M=E5ns Nilsson Systems Specialist >>+46 70 681 7204 KTHNOC >> MN1334-RIPE >> >>This TOPS OFF my partygoing experience! Someone I DON'T LIKE=20 >>is talking to me about a HEART-WARMING European film ... >> >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 11:52:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05824 for ; Wed, 15 Oct 2003 11:52:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nwc-0007l0-8q for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 11:52:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FFqEh1029817 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 11:52:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nwc-0007kq-2i for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 11:52:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05770 for ; Wed, 15 Oct 2003 11:52:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9nwa-0006Ip-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 11:52:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9nwa-0006Im-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 11:52:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nwQ-0007fG-0d; Wed, 15 Oct 2003 11:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nvx-0007ew-Ai for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 11:51:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05761 for ; Wed, 15 Oct 2003 11:51:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9nvw-0006Ic-00 for ipv6@ietf.org; Wed, 15 Oct 2003 11:51:32 -0400 Received: from dhcp4.se.kurtis.pp.se ([195.43.225.73] helo=laptop2.kurtis.autonomica.se) by ietf-mx with esmtp (Exim 4.12) id 1A9nvv-0006IZ-00 for ipv6@ietf.org; Wed, 15 Oct 2003 11:51:31 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h9FFpOwr003101; Wed, 15 Oct 2003 17:51:24 +0200 (CEST) Date: Wed, 15 Oct 2003 17:51:20 +0200 Subject: Re: stealth v6 DNS Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Bill Manning'" , To: "Jeroen Massar" From: Kurt Erik Lindqvist In-Reply-To: <007201c39331$d1865c30$210d640a@unfix.org> Message-Id: <6BADE92D-FF27-11D7-8B4F-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On onsdag, okt 15, 2003, at 17:34 Europe/Stockholm, Jeroen Massar wrote: >> >> % Apparently there is work being done on this, but it is not very >> public. >> % We have www.rs.net providing this for some time, but unfortunatly >> % it has some issues: it doesn't allow 'access' to non-IPv6 capable >> % domains and there isn't a european part of that deployment; yet, I >> understood. >> >> last I checked, sweden was nearly european... :) > > Ah so the machine is active, but unfortunatly the routing is > still suboptimal with all routes to the NS's going over the US. > If wanted, I still am willing to sport a Root DNS in holland > for this project, natively connected and such. 300ms on average > is not nice performance IMHO. And it can be much better. > We are working on that. - - kurtsi - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP41s+qarNKXTPFCVEQJ/GQCg1NcyXCQvQvlXp5AB7uzUMr3xI7sAoNSN N0E2byuxC+wj80nEnYtuF54d =Rkx4 -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 12:06:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06708 for ; Wed, 15 Oct 2003 12:06:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9oAJ-0000bU-Gh for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 12:06:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FG6NrO002314 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 12:06:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9oAJ-0000bB-7G for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 12:06:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06674 for ; Wed, 15 Oct 2003 12:06:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9oAF-0006bL-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 12:06:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9oAE-0006bI-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 12:06:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9o9y-0000S3-4v; Wed, 15 Oct 2003 12:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9o9G-0000Qu-Ag for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 12:05:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06607 for ; Wed, 15 Oct 2003 12:05:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9o9E-0006aC-00 for ipv6@ietf.org; Wed, 15 Oct 2003 12:05:16 -0400 Received: from maya40.nic.fr ([192.134.4.151]) by ietf-mx with esmtp (Exim 4.12) id 1A9o9D-0006a4-00 for ipv6@ietf.org; Wed, 15 Oct 2003 12:05:16 -0400 Received: from kerkenna.nic.fr (kerkenna.nic.fr [192.134.4.98]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id h9FG5Ahj866979; Wed, 15 Oct 2003 18:05:10 +0200 (CEST) Received: (from souissi@localhost) by kerkenna.nic.fr (8.11.6/8.9.3) id h9FG5As14764; Wed, 15 Oct 2003 18:05:10 +0200 Date: Wed, 15 Oct 2003 18:05:10 +0200 From: Mohsen Souissi To: Jeroen Massar Cc: ipv6@ietf.org Subject: Re: Will IPv4 be formally deprecated when IPv6 is good enough ? Message-ID: <20031015180510.I15800@kerkenna.nic.fr> References: <20031015152010.T1587@kerkenna.nic.fr> <006d01c39330$bb724f90$210d640a@unfix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <006d01c39330$bb724f90$210d640a@unfix.org>; from jeroen@unfix.org on Wed, Oct 15, 2003 at 05:26:40PM +0200 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by maya40.nic.fr id h9FG5Ahj866979 Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On 15 Oct, Jeroen Massar wrote: | -----BEGIN PGP SIGNED MESSAGE----- |=20 | [aggregated mail :)] |=20 | Mohsen Souissi [mailto:Mohsen.Souissi@nic.fr] wrote: |=20 | > On 15 Oct, Jeroen Massar wrote: | |=20 | > | Apparently there is work being done on this, but it is not very pub= lic. | >=20 | > =3D=3D> AFNIC (French Registry) has been running an official IPv6-cap= able | > name server (ns3.nic.fr) |=20 | Yup, indeed, sorry I forgot, you have been running it and shouting | about for some time already :) =3D=3D> I'm glad you heard that... ;-) | But did they put your AAAA as glue in the root already? =3D=3D> Unfortunately not yet :-(=20 |=20 | $ dig @e.root-servers.net ns3.nic.fr any | ;; ANSWER SECTION: | ns3.nic.fr. 172800 IN A 192.134.0.49 |=20 | There are quite a lot of deployments who run IPv6 transport | capable dns servers, but as long as they are not bound into | the root it has little to no sense. =3D=3D> I unfortunately agree with you :-(=20 The fact that no TLD's IPv6 glue is registered in the root zone is rather a layer-9 issue that a layer-7 one. As far as FR zone is concerned, we have officially applied for AAAA glue registration that in Feb 2003. Technical proofs was then given to IANA that there were no risk in adding AAAA glue in the root zone for FR zone (based on Draft Vixie & Kato http://www.ietf.org/internet-drafts/draft-ietf-dnsop-respsize-00.txt) Although that fact has been acknowledged by IANA and DNS experts, we are still waiting... We hope this issue will be solved very soon and I believe that IPv6 networking will be then much more credible (we will see real amounts of IPv6 traffic)... Cheers, Mohsen. |=20 | > | We have www.rs.net providing this for some time, but unfortunatly | > | it has some issues: it doesn't allow 'access' to non-IPv6 capable | > | domains and there isn't a european part of that deployment; yet, I | > | understood. | >=20 | > =3D=3D> Sounds ver strange... FR zone (it is a European for instance)= has | > been connected to rs.net (formerly OTDR) for more than one year | > now. Both ns[12].dnssec.nic.fr (which are authoritative for FR zone i= n | > rs.net testbed) support both IPv4 and IPv6 transport... |=20 | Indeed, for .fr but not for the root :( | What I meant to say that if you use the "IPv6 root" and try to resolve | a domain that only has IPv4 DNS servers, eg .com, currently it works ag= ain: |=20 | com. 518400 IN NS COM-A.ip4.int. | COM-A.ip4.int. 518400 IN AAAA |=20 | But it is flaky and doesn't always work unfortunatly. | The not-work part also has to do with the fact that all these | servers reside in the US and not in Europe. I understood that | Daniel Karrenberg was working on that part though... |=20 | Soohong Daniel Park wrote: | > Jeroen Massar wrote: | > > So kick your ISP, access and hosting, to get doing IPv6 and | > > if the access to that ISP can't provide native IPv6 ask them | > > to set up a tunnelbroker system, 6to4 relay etc for solving | > > that problem. | >=20 | > I guess it is one of v6ops role | > ISP design team is trying to propose a valuable thing for us.... |=20 | | We haven't created SixXS for nothing, if an ISP needs a service | as said like above they can come to us and we will, in cooperation | with them set it up. It is a whitelabel tunnelbroker system, no | strings attached, nothing to pay, totally independent, open and | certainly not restricted to europe. |=20 | Jim Bound wrote: | > Reason, if it is to continue then additional input to response | > below would be actual deployment in process that is not waiting | > on the multihome solution specifically Military and Telco | > operations in the market and then there is the Moonv6 US Network | > Pilot in process where 25 vendors are testing products as I type | > this email. www.moonv6.com |=20 | Neat to see such a project, a shame that I, and possibly others | didn't know about it. Speaking of which, isn't there a single | mailinglist/informationsource for finding such projects except | for googling around ofcourse or checking hs247.com but that | doesn't list it either... |=20 | M=E5ns Nilsson wrote: | > The fix for this is 32-bit AS numbers. Those 35000 ASen will | > suffice while we look at multihoming problems and routing table | > growth. |=20 | IPv4 is 32bits, are we going to do IPv4 between the ASN's then | to keep the routing between ASN's up to scale? 32bit ASN's will | also cause a lot of changes in amongst others BGP and internals | of routers. IMHO I don't think that is the way to go. The way | to go is find a good solution now, there is enough time. |=20 | Greets, | Jeroen |=20 | -----BEGIN PGP SIGNATURE----- | Version: Unfix PGP for Outlook Alpha 13 Int. | Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ |=20 | iQA/AwUBP41nMCmqKFIzPnwjEQL/mQCfaID56o60Hj3llkHpap4IFIXaLG8An2Xg | YKMZFgtI/iB3eIdSAr3sjj2i | =3Ds1vg | -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 12:40:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08401 for ; Wed, 15 Oct 2003 12:40:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ogd-00036U-4N for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 12:39:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FGdl5Z011923 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 12:39:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ogc-00036E-VE for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 12:39:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08367 for ; Wed, 15 Oct 2003 12:39:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9ogb-0007BR-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 12:39:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9oga-0007BO-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 12:39:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9oft-000307-Rb; Wed, 15 Oct 2003 12:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ofS-0002zc-8H for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 12:38:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08318 for ; Wed, 15 Oct 2003 12:38:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9ofQ-0007AW-00 for ipv6@ietf.org; Wed, 15 Oct 2003 12:38:32 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1A9ofP-0007AS-00 for ipv6@ietf.org; Wed, 15 Oct 2003 12:38:32 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9FGcQ4t011199 for ; Wed, 15 Oct 2003 09:38:27 -0700 (PDT) Received: from NAEXFE03.na.qualcomm.com (naexfe03.qualcomm.com [172.30.32.23]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9FGcOFA021693 for ; Wed, 15 Oct 2003 09:38:24 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXFE03.na.qualcomm.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Oct 2003 09:38:24 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6470.0 Subject: Unicast and multicast site-local addresses Date: Wed, 15 Oct 2003 09:38:23 -0700 Message-ID: <17D8F6DF3ED94D40BD607380866D9B7F33D19F@NAEX01.na.qualcomm.com> Thread-Topic: Unicast and multicast site-local addresses Thread-Index: AcOTOsBqeS8Y7WqTQ5OaN65ccJzUzg== From: "Barany, Pete" To: X-OriginalArrivalTime: 15 Oct 2003 16:38:24.0573 (UTC) FILETIME=[C0A1EED0:01C3933A] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Question: How does the deprecation of site-local unicast addresses (as defined in RFC 3513 Section 2.5.6) impact/affect site-local multicast addresses (as defined in RFC 3513 Section 2.7)? For example, setting the 4-bit "scop" field to a value =3D 5 limits the scope of a multicast = group to "site-local scope". One usage defined by DHCPv6 is for a Relay Agent to send a RELAY-FORW message to All_DHCP_Servers site-local scope multicast address (FF05::1:3) if it is not pre-configured with the IPv6 address(es) of DHCPv6 server(s). Regards, Pete -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 12:47:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08688 for ; Wed, 15 Oct 2003 12:47:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9onk-0003ZI-69 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 12:47:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FGl84j013710 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 12:47:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9onk-0003Z3-0V for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 12:47:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08657 for ; Wed, 15 Oct 2003 12:46:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9oni-0007HH-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 12:47:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9onh-0007HE-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 12:47:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9one-0003VO-7H; Wed, 15 Oct 2003 12:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9onW-0003V5-NM for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 12:46:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08652 for ; Wed, 15 Oct 2003 12:46:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9onU-0007H6-00 for ipv6@ietf.org; Wed, 15 Oct 2003 12:46:52 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1A9onU-0007GZ-00 for ipv6@ietf.org; Wed, 15 Oct 2003 12:46:52 -0400 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h9FGkKV13983; Wed, 15 Oct 2003 09:46:20 -0700 Received: from innovationslab.net ([63.109.132.2]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h9FGm3tX030492 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 15 Oct 2003 09:48:08 -0700 Message-ID: <3F8D79B2.5040203@innovationslab.net> Date: Wed, 15 Oct 2003 12:45:38 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Barany, Pete" CC: ipv6@ietf.org Subject: Re: Unicast and multicast site-local addresses References: <17D8F6DF3ED94D40BD607380866D9B7F33D19F@NAEX01.na.qualcomm.com> In-Reply-To: <17D8F6DF3ED94D40BD607380866D9B7F33D19F@NAEX01.na.qualcomm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Pete, The deprecation document only applies to site-local unicast addresses. I pointed out in SF that we still have to deal with the scoped multicast addresses. That is one of the goals of the modified Scoped Addressing Architecture document. There has been some discussion on the ipv6 list and several of the multicast lists about the behavior that is needed with regards to multicast forwarding/routing. Hopefully, all of those issues have or will be addressed in the scoped addr architecture doc. Brian Barany, Pete wrote: > Hi, > > Question: How does the deprecation of site-local unicast addresses (as > defined in RFC 3513 Section 2.5.6) impact/affect site-local multicast > addresses (as defined in RFC 3513 Section 2.7)? For example, setting the > 4-bit "scop" field to a value = 5 limits the scope of a multicast group > to "site-local scope". One usage defined by DHCPv6 is for a Relay Agent > to send a RELAY-FORW message to All_DHCP_Servers site-local scope > multicast address (FF05::1:3) if it is not pre-configured with the IPv6 > address(es) of DHCPv6 server(s). > > Regards, > > Pete > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 15 21:13:15 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01842 for ; Wed, 15 Oct 2003 21:13:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9wh8-0003U3-Ix for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 21:12:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9G1Coua013387 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 21:12:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9wh8-0003Tq-Do for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 21:12:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01813 for ; Wed, 15 Oct 2003 21:12:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9wh5-0006AJ-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 21:12:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9wh5-0006AG-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 21:12:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9wgM-0003MJ-Ee; Wed, 15 Oct 2003 21:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9wfO-0003IQ-Ne for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 21:11:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01763; Wed, 15 Oct 2003 21:10:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9wfL-00069O-00; Wed, 15 Oct 2003 21:11:00 -0400 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1A9wfL-000699-00; Wed, 15 Oct 2003 21:10:59 -0400 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 15 Oct 2003 18:11:16 -0700 Received: from 157.54.8.155 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 15 Oct 2003 18:10:29 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Oct 2003 18:10:29 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 15 Oct 2003 18:10:28 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 15 Oct 2003 18:10:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: I-D ACTION:draft-thaler-inet-tunnel-mib-00.txt Date: Wed, 15 Oct 2003 18:10:27 -0700 Message-ID: Thread-Topic: FW: I-D ACTION:draft-thaler-inet-tunnel-mib-00.txt thread-index: AcOTgkkiKz8LLHKNRBu5B6Bhh1pt5w== From: "Dave Thaler" To: , , X-OriginalArrivalTime: 16 Oct 2003 01:10:27.0860 (UTC) FILETIME=[49237D40:01C39382] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Forwarding this announcement to the most relevant WG's... RFC 2667, entitled "IP Tunnel MIB", only supported=20 point-to-point tunnels over IPv4. This draft updates=20 RFC 2667 to also support tunnels over IPv6, as well as=20 tunnels which aren't just point-to-point (e.g. 6to4). It also clarifies the use of the ifRcvAddressTable for all tunnels. It uses the InetAddress types like the other MIBs that have been done by the IPv6MIB Design Team. -Dave * To: IETF-Announce: ;=20 * Subject: I-D ACTION:draft-thaler-inet-tunnel-mib-00.txt=20 * From: Internet-Drafts@ietf.org=20 * Date: Tue, 14 Oct 2003 15:35:25 -0400=20 * Reply-to: Internet-Drafts@ietf.org=20 * Sender: owner-ietf-announce@ietf.org=20 ________________________________________ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Tunnel MIB Author(s) : D. Thaler Filename : draft-thaler-inet-tunnel-mib-00.txt Pages : 26 Date : 2003-10-14 =09 This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 and IPv6 networks. Extension MIBs may be designed for managing protocol-specific objects. Likewise, extension MIBs may be designed for managing security-specific objects. This MIB does not support tunnels over non-IP networks. Management of such tunnels may be supported by other MIBs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-thaler-inet-tunnel-mib-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-thaler-inet-tunnel-mib-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-thaler-inet-tunnel-mib-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. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 16 01:24:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07667 for ; Thu, 16 Oct 2003 01:24:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA0ce-0004bf-3r for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 01:24:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9G5OSt6017701 for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 01:24:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA0cd-0004bQ-L1 for ipv6-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 01:24:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07618 for ; Thu, 16 Oct 2003 01:24:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA0ca-0000Uj-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 01:24:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AA0cZ-0000Ug-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 01:24:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA0cD-0004Us-P9; Thu, 16 Oct 2003 01:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA0bb-0004UH-UW for ipv6@optimus.ietf.org; Thu, 16 Oct 2003 01:23:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07601 for ; Thu, 16 Oct 2003 01:23:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA0bY-0000UC-00 for ipv6@ietf.org; Thu, 16 Oct 2003 01:23:20 -0400 Received: from evrtwa1-ar8-4-40-179-145.evrtwa1.dsl-verizon.net ([4.40.179.145] helo=tndh.net) by ietf-mx with esmtp (Exim 4.12) id 1AA0bY-0000U9-00 for ipv6@ietf.org; Thu, 16 Oct 2003 01:23:20 -0400 Received: from eaglet (127.0.0.1:3495) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Wed, 15 Oct 2003 22:23:23 -0700 From: "Tony Hain" To: "Dan Lanciani" , Subject: RE: IPv6 adoption behavior Date: Wed, 15 Oct 2003 22:23:20 -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.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <200310150254.WAA06546@ss10.danlan.com> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dan Lanciani wrote: > Keith Moore wrote: > ... > |NAT isolates customer networks from upstream address policies > only by severely > |limiting their functionality. > > ... do you really think it is reasonable to > demand that everyone give up what they need to have what you think they > should want? A quick look at the archives for this list will show that he does (along with several others). That said, there are multiple parts to the isolation issue, and even though most NAT implementations combine them, the discussion will be more constructive to keep them separate. The internal app address stability issue is what the whole SL discussion is about, so refer to those threads for details. The access control feature is something any router can implement, so mangling the header is not the requirement for isolation. Concerns about tracability are dealt with by RFC 3041 addresses. That leaves address stability for external application use, in both a 'provider might change it' and multi-homing case. While a 'well written (tm)' app would not be aware of the mundane details of transport addresses, there are very few of those in the wild. Usually due to a belief that the app programmer can do a better job than the stack & remote infrastructure. I agree with you that getting apps to deal with addresses that might change under them is a bigger task than scoping, or even the effort to port to IPv6 in the first place. That by itself does not necessarily lead us to IPv6-NAT, but if IPv6-NAT looks like the lowest cost route to acheive address stability, it will happen. Said another way, removing one of the required attributes of stable addresses makes IPv6-NAT more likely, not less. The sad part is we have the tools to provide a lower cost & higher feature path for all but the multi-homed case (and a couple of proposals to deal with that as well), but can't get past the irrational fear of & trusting dependence on NAT. Until we get some applications to lead a few sample network deployments that show all of the isolation issues are dealt with in ways that don't require an IPv6-NAT, we will be stuck in an endless debate. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 16 02:17:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20805 for ; Thu, 16 Oct 2003 02:17:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA1S0-0008H5-5o for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 02:17:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9G6HWRm031808 for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 02:17:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA1Rz-0008Gx-I6 for ipv6-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 02:17:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20751 for ; Thu, 16 Oct 2003 02:17:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA1Rv-0000sZ-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 02:17:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AA1Rv-0000sW-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 02:17:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA1RX-00085w-8U; Thu, 16 Oct 2003 02:17:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA1Qm-00081a-3S for ipv6@optimus.ietf.org; Thu, 16 Oct 2003 02:16:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20631 for ; Thu, 16 Oct 2003 02:16:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA1Qi-0000s9-00 for ipv6@ietf.org; Thu, 16 Oct 2003 02:16:12 -0400 Received: from batch16.uni-muenster.de ([128.176.188.114]) by ietf-mx with esmtp (Exim 4.12) id 1AA1Qh-0000s3-00 for ipv6@ietf.org; Thu, 16 Oct 2003 02:16:11 -0400 Received: from zivlnx01.uni-muenster.de (ZIVLNX01.UNI-MUENSTER.DE [128.176.188.24]) by batch16.uni-muenster.de (Postfix) with ESMTP id 7F76711037; Thu, 16 Oct 2003 08:15:29 +0200 (MES) Received: from localhost (localhost.uni-muenster.de [127.0.0.1]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id 6BA5531301; Thu, 16 Oct 2003 08:16:07 +0200 (CEST) Received: from kummerog.uni-muenster.de (KUMMEROG.UNI-MUENSTER.DE [128.176.184.156]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id A0743312E4; Thu, 16 Oct 2003 08:16:06 +0200 (CEST) Subject: Re: IPv6 adoption behavior From: "Christian Strauf (JOIN)" To: Dan Lanciani Cc: ipv6@ietf.org In-Reply-To: <200310150254.WAA06546@ss10.danlan.com> References: <200310150254.WAA06546@ss10.danlan.com> Content-Type: text/plain; charset=iso-8859-15 Organization: JOIN-Team, WWU-Muenster Message-Id: <1066284966.21014.50.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 16 Oct 2003 08:16:06 +0200 X-Virus-Scanned: by AMaViS 0.3.12pre7 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA20632 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Clearly many users care a lot about the isolation and little about the > functionality that you believe is being limited. Rather than trying to > convince them that they are wrong for wanting to keep their networks > running, how about proposing a way to achieve that isolation without > limiting the functionality that you want to preserve? If we cannot > implement such a solution (and I doubt that we can since it changes the > economics of address rentals), do you really think it is reasonable to > demand that everyone give up what they need to have what you think they > should want? I don't think that it is about giving up what you need. With a combined v4/v6-capable firewall- and v4-NAT box you could easily achieve the same level of isolation of a subnet but without the restrictions for IPv6 hosts that are forced on v4-hosts by v4-NAT. (In this case: if you want to be dual-stacked you keep v4 NAT and use v6 with appropriate firewall rules.) So this should not be much of a problem. However, I absolutely agree with what you said about IPv6 address changes. I guess it is all about taking the choice of the addresses away from the applications in some way or the other (e.g. by stuffing it into the IP-stack of the system). One could also stay on the application level and create a reliable and portable standard library that handles the address issue transparently for the more abstract app that uses it. This would clearly help application developers a lot. There exist a few such apps and libs that already try to deal with this problem. Of course there will always be some cases where an explicit choice of the transport address may be useful but this does not speak against an application independent solution to this problem. Christian P.S.: The "choice of address" issue is obviously a similar issue in dual-stack environments. Right now, most v4/v6-capable applications are almost unpredictable when it comes to choosing a v4 or v6 address and falling back to one or the other (if that is an option) because it's up to the developer's taste how to do it. --=20 JOIN - IP Version 6 in the WiN Christian Strauf A DFN project Westf=E4lische Wilhelms-Universit=E4t M=FC= nster http://www.join.uni-muenster.de Zentrum f=FCr Informationsverarbeitung Team: join@uni-muenster.de R=F6ntgenstrasse 9-13 Priv: strauf@uni-muenster.de D-48149 M=FCnster / Germany GPG-/PGP-Key-ID: 1DFAAA9A Fon: +49 251 83 31639, Fax: +49 251 83 31= 653 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 16 02:56:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21992 for ; Thu, 16 Oct 2003 02:56:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA23n-0002C1-GP for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 02:56:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9G6uZcg008427 for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 02:56:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA23m-0002Bq-PL for ipv6-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 02:56:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21954 for ; Thu, 16 Oct 2003 02:56:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA23i-0001EH-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 02:56:30 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AA23i-0001EE-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 02:56:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA23G-00024u-TF; Thu, 16 Oct 2003 02:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA22x-00024J-Kd for ipv6@optimus.ietf.org; Thu, 16 Oct 2003 02:55:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21944 for ; Thu, 16 Oct 2003 02:55:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA22t-0001Dn-00 for ipv6@ietf.org; Thu, 16 Oct 2003 02:55:39 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1AA22s-0001Dk-00 for ipv6@ietf.org; Thu, 16 Oct 2003 02:55:38 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h9G6tcFH018381 for ; Wed, 15 Oct 2003 23:55:38 -0700 (MST) Received: from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h9G6taZg016608 for ; Thu, 16 Oct 2003 01:55:37 -0500 Received: from motorola.com (aewhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.10/8.12.10) with ESMTP id h9G6tZEK006507 for ; Thu, 16 Oct 2003 16:55:36 +1000 (EST) Message-ID: <3F8E40E7.F9BF9934@motorola.com> Date: Thu, 16 Oct 2003 16:55:35 +1000 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: ipv6@ietf.org Subject: Re: Unicast and multicast site-local addresses References: <17D8F6DF3ED94D40BD607380866D9B7F33D19F@NAEX01.na.qualcomm.com> <3F8D79B2.5040203@innovationslab.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm not sure we want to throw out the idea of 'scope'. Even without SL, two scopes are architecturally enshrined in IPv6, link-local (addresses are valid and unique only on-link) and global (addresses are globally unique). You'll notice that I don't say addresses are globally valid. Architectural scope talks about uniqueness. Functional scope talks about where an address is actually useable - the presence of filters and the such mean that there are many situations where an address is unique but wont work. This is a feature, not a flaw. The problem with SL and scope were twofold, and both were about non-uniqueness. A single SL address space is robust, even if nested within a larger global address space, as long as the address selection algorithms have a mechanism for evaluating scope and choosing an appropriate address. However, there is no guarantee of uniqueness between SL spaces, which creates problems on merge. Worse, SL allowed non-unique spaces to overlap and required an additional 'scope identifier' to determine which space an address belonged to. This scope identifier became a piece of addressing information that was no included in the address, with obvious problems. Given that we have a mechanism for solving the uniqueness problem (see note 1), then I think scope is a healthy concept. At least for address selection, its not that hard to encode certain scopes to certain address ranges and have address selection respond accordingly. Dealing with scope in a more general sense (eg I know this address - is it valid in any of my scopes?) is a knottier problem, but that problem exists regardless of whether scopes are defined. Having a mechanism to map an address to a scope makes the above problem easier. Note 1: Link local and the proposed local addressing draft both propose mechanism to cause the addresses generated to be unique, even outside their scope. LL uses the MAC address, while local addressing uses either allocation or randomization. -- Andrew White -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 16 03:33:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23160 for ; Thu, 16 Oct 2003 03:33:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA2dd-0004f1-BR for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 03:33:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9G7Xbdk017909 for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 03:33:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA2dc-0004em-8X for ipv6-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 03:33:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23125 for ; Thu, 16 Oct 2003 03:33:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA2dZ-0001dP-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 03:33:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AA2dZ-0001dM-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 03:33:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA2d5-0004VB-92; Thu, 16 Oct 2003 03:33:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA2ct-0004UH-Iw for ipv6@optimus.ietf.org; Thu, 16 Oct 2003 03:32:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23059 for ; Thu, 16 Oct 2003 03:32:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA2cr-0001ch-00 for ipv6@ietf.org; Thu, 16 Oct 2003 03:32:49 -0400 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1AA2cn-0001cb-00 for ipv6@ietf.org; Thu, 16 Oct 2003 03:32:46 -0400 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id DAA19786; Thu, 16 Oct 2003 03:32:36 -0400 (EDT) Date: Thu, 16 Oct 2003 03:32:36 -0400 (EDT) From: Dan Lanciani Message-Id: <200310160732.DAA19786@ss10.danlan.com> To: ipv6@ietf.org Subject: RE: IPv6 adoption behavior Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , "Tony Hain" wrote: |That said, there are multiple parts to the isolation issue, and even though |most NAT implementations combine them, the discussion will be more |constructive to keep them separate. I used to believe this, but I recently came to the realization that isolation from provider address policy is a single issue. Attempting to pigeonhole each aspect of that isolation (and offer limited solutions) encourages a divide-and-sweep-under-the-rug attack. Unfortunately, even those who are strongly supportive of what they see as an important aspect of policy isolation often ignore aspects that are important to others. N.B. I'm not saying that NAT defines the model for isolation. Most NAT implementations combine most (or even all) of the required address policy isolation with a number of other features. |The internal app address stability issue is what the whole SL discussion is |about, so refer to those threads for details. Umm, yes, I think I participated enough in those threads that I do not need to refer to them again... |The access control feature is something any router can implement, so |mangling the header is not the requirement for isolation. I agree that access control is not a part of address policy isolation. |Concerns about tracability are dealt with by RFC 3041 addresses. I have my doubts about this; it may backfire. If you tell your ISP that you need more privacy it may be happy to oblige by increasing the frequency with which your single valid address changes. Be careful what you wish for. |That leaves address stability for external application use, It also leaves address rental cost, and limitations on number of addresses available regardless of what you may be willing to pay (at least within a class of service). It probably leaves other things that I am forgetting. I think this is a good illustration of the pigeonhole pitfall. If you fail to address any one aspect of isolation and that aspect is important to enough people, a NAT solution will appear to fill the void. That solution will likely include all the "bad" features of NAT as well simply because it's easy and people already understand the model. The core issue appears to be that any comprehensive solution to the isolation problem would disenfranchise the address allocation hierarchy (just as simple PI allocation would), and we aren't prepared to do that. This rules out obvious solutions like source routing (aka identifier/locator separation). It also lobbies against overlay networks and similar work-arounds. Site-locals as originally defined could have been tweaked to remove ambiguity and support a large overlay network (there were plenty of bits) while the replacements we are hearing about (if they come to exist at all) will likely have sufficient punitive semantics to block such use on any interesting scale. In some sense, the elimination of site-locals (and scoping in general) may be a good thing. Remember, the question being discussed was whether IPv6 can provide a substitute for IPv4+NAT. At least this way the answer is unambiguous, and deployers will be able to plan accordingly. |I |agree with you that getting apps to deal with addresses that might change |under them is a bigger task than scoping, or even the effort to port to IPv6 |in the first place. Absolutely. It's a very hard problem to solve. And (although I've asked repeatedly during the site-local debates) I've yet to hear any assurance from the application folks that they are even going to try. I fear that complaints of application failure due to address fluctuations will be met with suggestions to use a different ISP and/or send your ISP more money. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 16 03:47:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23648 for ; Thu, 16 Oct 2003 03:47:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA2qv-0005tL-Gr for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 03:47:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9G7lLKf022640 for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 03:47:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA2qq-0005pw-IC for ipv6-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 03:47:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23618 for ; Thu, 16 Oct 2003 03:47:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA2qn-0001mz-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 03:47:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AA2qm-0001mw-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 03:47:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA2qe-0005kB-5Z; Thu, 16 Oct 2003 03:47:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA2qZ-0005jY-Bj for ipv6@optimus.ietf.org; Thu, 16 Oct 2003 03:46:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23607 for ; Thu, 16 Oct 2003 03:46:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA2qW-0001mg-00 for ipv6@ietf.org; Thu, 16 Oct 2003 03:46:56 -0400 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1AA2qV-0001md-00 for ipv6@ietf.org; Thu, 16 Oct 2003 03:46:56 -0400 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id DAA19878; Thu, 16 Oct 2003 03:46:53 -0400 (EDT) Date: Thu, 16 Oct 2003 03:46:53 -0400 (EDT) From: Dan Lanciani Message-Id: <200310160746.DAA19878@ss10.danlan.com> To: ipv6@ietf.org Subject: Re: IPv6 adoption behavior Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , "Christian Strauf (JOIN)" wrote: |I don't think that it is about giving up what you need. With a combined |v4/v6-capable firewall- and v4-NAT box you could easily achieve the same |level of isolation of a subnet but without the restrictions for IPv6 |hosts that are forced on v4-hosts by v4-NAT. (In this case: if you want |to be dual-stacked you keep v4 NAT and use v6 with appropriate firewall |rules.) So this should not be much of a problem. But (assuming I'm understanding your setup correctly) you have to restrict all the local applications that require address stability to using NAT'ed IPv4 only. The v6 firewall rules don't isolate you from address changes. I guess that's ok, but having to select which version of IP to use depending on whether you want stable local or unstable global access seems at least as complicated as selecting local vs. global addresses for the same reasons. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 16 04:12:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24400 for ; Thu, 16 Oct 2003 04:12:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA3Ey-0007cU-J3 for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 04:12:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9G8CCgk029288 for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 04:12:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA3Ew-0007cB-P6 for ipv6-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 04:12:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24375 for ; Thu, 16 Oct 2003 04:12:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA3Et-00021R-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 04:12:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AA3Et-00021O-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 04:12:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA3Dt-0007QR-2q; Thu, 16 Oct 2003 04:11:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA2y3-0006L9-7B for ipv6@optimus.ietf.org; Thu, 16 Oct 2003 03:54:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23789; Thu, 16 Oct 2003 03:54:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA2y0-0001q1-00; Thu, 16 Oct 2003 03:54:40 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AA2xz-0001py-00; Thu, 16 Oct 2003 03:54:40 -0400 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 1738615210; Thu, 16 Oct 2003 16:54:37 +0900 (JST) Date: Thu, 16 Oct 2003 16:54:35 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Cc: mip6@ietf.org, ietf-send@standards.ericsson.net Subject: RFC2462 update User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hello, (Sorry for the cross-posting. This is because many people who are not in the ipv6 list may want to join the discussion. I'll restrict my further posting to the ipv6 list in order to avoid unnecessary noise.) As asked by the IPv6 wg co-chairs, I'm going to update the "IPv6 Stateless Address Autoconfiguration" document (which is currently RFC2462) as a new I-D. Since we'll soon miss the cut-off date for an initial I-D, my current plan is to make a list of issues raised so far (that include the very recent discussion in the ipv6 list) and submit a 00 draft containing the list. I'll send an initial proposal of the issue list to the ipv6 list in a day or so, get quick comments on the issue list, and then edit and submit the draft. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 16 08:32:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00484 for ; Thu, 16 Oct 2003 08:32:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7IV-0003UA-Ip for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 08:32:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GCW79Q013392 for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 08:32:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7IV-0003Tv-9j for ipv6-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 08:32:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00447 for ; Thu, 16 Oct 2003 08:31:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA7IU-0004Bv-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 08:32:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AA7IT-0004Br-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 08:32:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7HS-0003Ht-8H; Thu, 16 Oct 2003 08:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7GS-0003Ed-3Y for ipv6@optimus.ietf.org; Thu, 16 Oct 2003 08:30:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00349 for ; Thu, 16 Oct 2003 08:29:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA7GQ-00049t-00 for ipv6@ietf.org; Thu, 16 Oct 2003 08:29:59 -0400 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1AA7GQ-00049T-00 for ipv6@ietf.org; Thu, 16 Oct 2003 08:29:58 -0400 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9GCTEo0070168; Thu, 16 Oct 2003 14:29:17 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9GCTERC235166; Thu, 16 Oct 2003 14:29:14 +0200 Received: from zurich.ibm.com (sig-9-145-243-99.de.ibm.com [9.145.243.99]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA21736; Thu, 16 Oct 2003 14:29:13 +0200 Message-ID: <3F8E8EFE.EB7A4F06@zurich.ibm.com> Date: Thu, 16 Oct 2003 14:28:46 +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: Dan Lanciani CC: ipv6@ietf.org Subject: Re: IPv6 adoption behavior References: <200310160732.DAA19786@ss10.danlan.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dan Lanciani wrote: > > "Tony Hain" wrote: > > |That said, there are multiple parts to the isolation issue, and even though > |most NAT implementations combine them, the discussion will be more > |constructive to keep them separate. > > I used to believe this, but I recently came to the realization that isolation > from provider address policy is a single issue. Perhaps, but it is not an issue to which NAT is the only answer. In IPv6 we have enough address space to solve it without NAT. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 16 08:48:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01064 for ; Thu, 16 Oct 2003 08:48:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7Y4-0004To-6d for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 08:48:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GCmCHK017214 for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 08:48:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7Y4-0004TZ-1O for ipv6-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 08:48:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00964 for ; Thu, 16 Oct 2003 08:48:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA7Y2-0004Mt-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 08:48:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AA7Y2-0004Mq-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 08:48:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7Xs-0004Nx-S0; Thu, 16 Oct 2003 08:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7XD-0004Mo-LX for ipv6@optimus.ietf.org; Thu, 16 Oct 2003 08:47:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00936; Thu, 16 Oct 2003 08:47:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA7XC-0004M9-00; Thu, 16 Oct 2003 08:47:18 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AA7XB-0004Le-00; Thu, 16 Oct 2003 08:47:17 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RCK9R>; Thu, 16 Oct 2003 08:46:38 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922DD9@ftmail.lab.flarion.com> From: Soliman Hesham To: ipv6@ietf.org Cc: mip6@ietf.org, ietf-send@standards.ericsson.net Subject: RFC2461 update Date: Thu, 16 Oct 2003 08:46:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-2022-JP" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Folks, Sorry for the cross posting. This is a heads up to let you know that I'm updating the Neighbour Discovery specification, RFC 2461 as requested by the IPv6 WG chairs. The updates are likely to include issues raised in the WGs copied on this email. If you're interested in following this discussion please monitor the IPv6 mailing list. Like Jinmeii, I'll be sending a list of issues that were raised and would appreciate your feedback. The list of issues will come towards the beginning of next week. I'm currently going through the archives. Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 16 16:22:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22115 for ; Thu, 16 Oct 2003 16:22:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAEdG-0000FE-1b for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 16:22:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GKM1oV000924 for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 16:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAEdF-0000En-GN for ipv6-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 16:22:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22063 for ; Thu, 16 Oct 2003 16:21:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAEdD-0001uD-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 16:21:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAEdD-0001uA-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 16:21:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAEbK-0008MW-NC; Thu, 16 Oct 2003 16:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAEaS-0008L6-I0 for ipv6@optimus.ietf.org; Thu, 16 Oct 2003 16:19:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21864 for ; Thu, 16 Oct 2003 16:18:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAEaQ-0001pa-00 for ipv6@ietf.org; Thu, 16 Oct 2003 16:19:06 -0400 Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx with esmtp (Exim 4.12) id 1AAEaP-0001nt-00 for ipv6@ietf.org; Thu, 16 Oct 2003 16:19:05 -0400 Received: from gih505.telstra.net (dhcp12.potaroo.net [203.10.60.12]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h9GKIGRe016423; Fri, 17 Oct 2003 06:18:24 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20031017053350.00b74ad0@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 17 Oct 2003 06:07:42 +1000 To: Brian E Carpenter , Dan Lanciani From: Geoff Huston Subject: Re: IPv6 adoption behavior Cc: ipv6@ietf.org In-Reply-To: <3F8E8EFE.EB7A4F06@zurich.ibm.com> References: <200310160732.DAA19786@ss10.danlan.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , At 02:28 PM 16/10/2003 +0200, Brian E Carpenter wrote: >Dan Lanciani wrote: > > > > "Tony Hain" wrote: > > > > |That said, there are multiple parts to the isolation issue, and even > though > > |most NAT implementations combine them, the discussion will be more > > |constructive to keep them separate. > > > > I used to believe this, but I recently came to the realization that > isolation > > from provider address policy is a single issue. > >Perhaps, but it is not an issue to which NAT is the only answer. In IPv6 >we have >enough address space to solve it without NAT. This is one more round in a circular argument. Yes, there is more than ample address space, but there is a common perception that there is not ample routing space. It seems to me that there are a set of very loosely coordinated efforts in this space, that are all, ultimately, directed at the same issue - attempting to avoid placing fatal pressure of the routing system. On the one hand there is an effort to constrain the supply of discretely routeable elements through: policy constraints on the allocation of provider independent address space, use of "private" address space coupled with public NATs, consideration of various forms of scoped address architecture, and use of tunnelling and encapsulation. At the same time we're attempting to drive an effort to improve the scale of the routing system through a number of research related efforts that attempt, in various ways, to scale routing by looking at the routing domain as a synchronized discovery of topology, policy and address prefix reachability. At the same time we see vendors making continual improvements in router architectures and their components that lift the practical ceiling of routing capability at a scale that appears to continue to track a reasonable approximation of Moore's Law. Coupled with continual improvement in operational environments that have, on the whole, created improvements in the stability of the routing environment. I have the _personal_ impression that we've managed to overdamp the supply of address prefixes such that the current routing system is now situated very comfortably within the current capabilities of the routing system and the underlying active network elements, but at the cost of increasing application complexity in a world of NATs, dual protocol stacks, multi-homing, mobility, and so on. Its not entirely clear to me that this approach scales. My impression is that we've not managed to push the scaleability of routing technology at the same time, so we've fixated, perhaps too far, on applying constraints within the address system and paying the cost through increasing application and service architecture complexity. If we had more confidence in the ability to scale the routing system we could look beyond the relative merits of various forms of application of address system constraints and strike a better balance between carrying the load of further network scaling between the routing and addressing systems. Geoff -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 16 16:38:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23118 for ; Thu, 16 Oct 2003 16:38:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAEsR-0001JZ-1p for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 16:37:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GKbgJr005035 for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 16:37:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAEsP-0001Iy-8l for ipv6-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 16:37:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23073 for ; Thu, 16 Oct 2003 16:37:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAEsN-0002Eg-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 16:37:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAEsM-0002Ed-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 16:37:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAErn-0000z8-5q; Thu, 16 Oct 2003 16:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAEr3-0000wr-Ps for ipv6@optimus.ietf.org; Thu, 16 Oct 2003 16:36:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23047 for ; Thu, 16 Oct 2003 16:36:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAEr1-0002Du-00 for ipv6@ietf.org; Thu, 16 Oct 2003 16:36:15 -0400 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1AAEr0-0002Dr-00 for ipv6@ietf.org; Thu, 16 Oct 2003 16:36:14 -0400 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id QAA25480; Thu, 16 Oct 2003 16:36:10 -0400 (EDT) Date: Thu, 16 Oct 2003 16:36:10 -0400 (EDT) From: Dan Lanciani Message-Id: <200310162036.QAA25480@ss10.danlan.com> To: ipv6@ietf.org Subject: Re: IPv6 adoption behavior Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Brian E Carpenter wrote: |Dan Lanciani wrote: |> |> "Tony Hain" wrote: |> |> |That said, there are multiple parts to the isolation issue, and even though |> |most NAT implementations combine them, the discussion will be more |> |constructive to keep them separate. |> |> I used to believe this, but I recently came to the realization that isolation |> from provider address policy is a single issue. | |Perhaps, but it is not an issue to which NAT is the only answer. I never implied that it was. There are many simple solutions including PI space handled at the routing level, source routing in any of several forms including locator/identifier separation, and overlay networks. Unfortunately, none of those solutions seems to be able to make it past the politics of provider-controlled address allocation. The required technical work to support them never happens or (in the case of overlay networks) technical tweaks are implemented to prevent end users from implementing it themselves. I see two classes on solution: 1) Solutions that require that we make some change to the protocol. These would include the approaches I listed above. If you know of such a solution that isn't DOA (i.e., that is even allowed to be discussed on this list) then please describe it. 2) Solutions that end users can implement without change to the protocol. I had hopes here for overlay networks, but these still require access to address space that is not burdened with punitive semantics like default router rules and DNS prohibitions. Even with such access it would be difficult to establish critical mass and turn the overlay network into the primary network. If you know of a solution that the market can provide without protocol support (other than NAT) I'd love to hear about it. |In IPv6 we have |enough address space to solve it without NAT. Address space was never the problem. Portable/global/routable address space available directly to end users (or rather lack of it) is. You can give the service providers all the address bits in the universe, but that won't solve the problem. People have been claiming for years that IPv6 can deliver the same (or better) functionality as NAT, but more cleanly. Recent comments (including some private email) suggest that this claim carries the unstated assumption that the only functionality provided by NAT (or at least the only functionality that end users should be allowed) is conservation of the total address pool. Assuming folks really believe this, I think the disconnect with the real world is so great as to make progress virtually impossible. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 16 19:57:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00650 for ; Thu, 16 Oct 2003 19:57:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAHyz-0002Oa-Mq for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 19:56:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GNufD0009204 for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 19:56:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAHyz-0002ON-5V for ipv6-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 19:56:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00618 for ; Thu, 16 Oct 2003 19:56:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAHyx-0004JH-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 19:56:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAHyw-0004JE-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 19:56:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAHyM-0002IE-RE; Thu, 16 Oct 2003 19:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAHxR-00028u-RR for ipv6@optimus.ietf.org; Thu, 16 Oct 2003 19:55:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00563 for ; Thu, 16 Oct 2003 19:54:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAHxP-0004I5-00 for ipv6@ietf.org; Thu, 16 Oct 2003 19:55:03 -0400 Received: from evrtwa1-ar8-4-40-179-195.evrtwa1.dsl-verizon.net ([4.40.179.195] helo=tndh.net) by ietf-mx with esmtp (Exim 4.12) id 1AAHxP-0004I2-00 for ipv6@ietf.org; Thu, 16 Oct 2003 19:55:03 -0400 Received: from eaglet (127.0.0.1:3819) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Thu, 16 Oct 2003 16:55:07 -0700 From: "Tony Hain" To: "Dan Lanciani" , Subject: RE: IPv6 adoption behavior Date: Thu, 16 Oct 2003 16:55:02 -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.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <200310160732.DAA19786@ss10.danlan.com> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dan Lanciani wrote: > ... Attempting to pigeonhole > each aspect of that isolation (and offer limited solutions) encourages a > divide-and-sweep-under-the-rug attack. Recent evidence around the IETF supports this claim, but in the real world where NAT is seen as the single solution to all the problems, we need to break them down to show the alternative solutions to each. > Unfortunately, even those who are > strongly supportive of what they see as an important aspect of > policy isolation > often ignore aspects that are important to others. If I missed something it was only for lack of awareness. Please send details off line. > ... > Umm, yes, I think I participated enough in those threads that I > do not need > to refer to them again... Just trying to be complete without rehashing ;) > ... > |Concerns about tracability are dealt with by RFC 3041 addresses. > > I have my doubts about this; it may backfire. If you tell your > ISP that you > need more privacy it may be happy to oblige by increasing the > frequency with > which your single valid address changes. Be careful what you wish for. If a provider is going to offer me a single address, I will insist on a globally routable IPv4 one, then push their service down a layer with the other (irrelevant to the end user) lower layer wrapper technologies. If they do the right thing and provide a prefix, there is no need for them to know about the site privacy policies. My point was targeted more at those that claim nat obscures the origin host, therefore provides some degree of privacy isolation. > > |That leaves address stability for external application use, > > It also leaves address rental cost, and limitations on number of addresses > available regardless of what you may be willing to pay (at least within a > class of service). Current policies are fed by the resource scarcity, which over the short term is artifical, but over the long term is real. We haven't gotten the correct version at the nav6tf web site yet, but a paper there will show that we will need well over 400 additional /8's to get a single address to 20% of the population outside the countries that already have one or more for 20% of theirs. This is for an HD ratio of 90% which is well in excess of the pain threashold documented in RFC3194. Taking that down to current practice of 85% more than triples the number of /8's required to well over 1300. And again, that is only to provide one address to 20% of the population in those countries that don't already have that many. Take scarcity off the table, and it will be difficult to maintain per address costs if there is any competition in the environment. > It probably leaves other things that I am forgetting. I > think this is a good illustration of the pigeonhole pitfall. If you fail > to address any one aspect of isolation and that aspect is > important to enough > people, a NAT solution will appear to fill the void. That > solution will likely > include all the "bad" features of NAT as well simply because it's easy and > people already understand the model. I agree, so we need to be documenting all the cases we can find for why network managers will demand isolation from SP provided addresses. > > The core issue appears to be that any comprehensive solution to > the isolation > problem would disenfranchise the address allocation hierarchy > (just as simple > PI allocation would), and we aren't prepared to do that. I agree that some approaches will disenfranchise some historical institutions, but I don't think that is what is holding us back. There is also an irrational fear of policy intervention (read that as ITU), which would make the PI approaches like mine or the city focused ones tractable to the routing system. > This rules out > obvious solutions like source routing (aka identifier/locator > separation). It > also lobbies against overlay networks and similar work-arounds. > Site-locals > as originally defined could have been tweaked to remove ambiguity > and support > a large overlay network (there were plenty of bits) while the > replacements we > are hearing about (if they come to exist at all) will likely have > sufficient > punitive semantics to block such use on any interesting scale. That is why I have lobbied that we need to be solving both the local use & the PI problems at the same time. They solve different problems, but if we only provide one, it will be abused to solve the other. > > In some sense, the elimination of site-locals (and scoping in general) may > be a good thing. Remember, the question being discussed was whether IPv6 > can provide a substitute for IPv4+NAT. At least this way the answer is > unambiguous, and deployers will be able to plan accordingly. Well just because the IETF buries its collective head in a dark place does not mean network managers will do away with scoping. After all the IETF definition is just a formalization of the hacks they were already doing. > > |I > |agree with you that getting apps to deal with addresses that might change > |under them is a bigger task than scoping, or even the effort to > port to IPv6 > |in the first place. > > Absolutely. It's a very hard problem to solve. And (although I've asked > repeatedly during the site-local debates) I've yet to hear any assurance > from the application folks that they are even going to try. I fear that > complaints of application failure due to address fluctuations will be met > with suggestions to use a different ISP and/or send your ISP more money. I really don't care if the ISP gets more money, as long as those responsible for the lack of alternatives are the ones footing the bill. It is good to have a financially healthy ISP to rely on, just not at my expense ... Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 16 21:50:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02947 for ; Thu, 16 Oct 2003 21:50:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAJkm-00076T-7y for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 21:50:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9H1o8Kh027305 for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 21:50:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAJkl-00076I-Td for ipv6-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 21:50:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02923 for ; Thu, 16 Oct 2003 21:49:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAJki-0005AW-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 21:50:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAJki-0005AT-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 21:50:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAJji-0006ze-6T; Thu, 16 Oct 2003 21:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAJiq-0006z0-Il for ipv6@optimus.ietf.org; Thu, 16 Oct 2003 21:48:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02911 for ; Thu, 16 Oct 2003 21:47:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAJin-0005A6-00 for ipv6@ietf.org; Thu, 16 Oct 2003 21:48:05 -0400 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1AAJil-00059t-00 for ipv6@ietf.org; Thu, 16 Oct 2003 21:48:03 -0400 Received: from tyre (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.9/8.12.1) with SMTP id h9H1lOnV002063; Fri, 17 Oct 2003 10:47:26 +0900 (KST) Message-ID: <015001c39451$a331af30$e82f024b@tyre> From: "JinHyeock Choi" To: "Brian Haberman" , References: <3F8404C6.30609@innovationslab.net> Subject: Comments on RA issues for MD Date: Fri, 17 Oct 2003 10:54:43 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: base64 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RWQgUmVtbWVsbCB3cm90ZToNCj4gSmluSHllb2NrIC0NCj4NCj4gVW5uZWNlc3NhcnkgQlUgaXMg bm90IGEgaHVnZSBwcm9ibGVtLiBTbyB5b3UgZ2V0IGFuIGV4dHJhIEwzIGhhbmRvdmVyLiBMZXQn cyANCg0KVXAgdG8gc29tZSBkZWdyZWUuIFdlIHRlc3RlZCBhIGxpbmsgd2l0aCB0d28gcm91dGVy cyBhZHZlcnRpc2luZyB0d28gZGlmZmVyZW50IA0KcHJlZml4ZXMuIFRoZW4gYW4gTU4ga2VwdCBz ZW5kaW5nIEJVIHdoZW5ldmVyIGEgbmV3IFJBIGFycml2ZXMuIEJ1dCB0aGlzLCBJIHRoaW5rLCAN CndlJ2QgYmV0dGVyIGRpc2N1c3MgYXQgbWlwNiBvciBETkEuIA0KDQo+IGtlZXAgdGhpbmdzIHNp bXBsZS4uLiBJTU8gdGhpcyBzY2VuYXJpbyB5b3UgaGF2ZSBpZGVudGlmaWVkIGlzIG5vdCBhIGdv b2QgDQo+IHJlYXNvbiBmb3IgaW50cm9kdWNpbmcgYSBuZXcgYml0IGluIHRoZSBSQS4gQWxzbywg SSBzdGlsbCBiZWxpZXZlIHRoYXQgdGhlIG5ldyANCg0KVGhvdWdoIGl0J3MgYWJzb2x1dGUgbmVj ZXNzaXR5IGNhbid0IGJlIHByb3ZlZCwgSSB0aGluayBpdCdzIHdvcnRod2hpbGUgdG8gaW52ZXN0 aWdhdGUgDQp0aGUgaWRlYSBvZiB1c2luZyBvbmUgYml0IHRvIDEpIGluZGljYXRlIGNvbXBsZXRl bmVzcyBhbmQgMikgY29uZmlybSByZWFjaGFiaWxpdHkvDQphY2tub3dsZWRnZSBzb2xpY2l0YXRp b24uDQoNCj4gcHJvcG9zZWQgTGluayBJZGVudGlmaWVyIFJBIG9wdGlvbiBpcyBhbiBleGNlbGxl bnQgc29sdXRpb24sIGlmIHlvdSBuZWVkIHRvIA0KPiB1c2UgUkFzIGZvciBtb3ZlbWVudCBkZXRl Y3Rpb24gYmVjYXVzZSB5b3UgZG9uJ3QgaGF2ZSByZWxpYWJsZSBMMiB0cmlnZ2VycyB0byANCj4g Z2l2ZSB5b3UgdGhlIHNhbWUgaW5mb3JtYXRpb24uIFNvbWUgbGluayB0eXBlcyBsaWtlIFdpRmkg d2lsbCBoYXZlIHJlbGlhYmxlIEwyIA0KPiB0cmlnZ2VycyB0aGF0IGNhbiBiZSB1c2VkIHRvIGRl dGVjdCBhIGNoYW5nZSBvZiBuZXR3b3JrIChFU1NJRCwgZm9yIFdpRmkpLiBJbiANCj4gdGhhdCBj YXNlLCBJTUhPIGl0IGlzIHByZWZlcmFibGUgdG8gdXNlIHRoZSBMMiB0cmlnZ2VycyBhbmQgbGVh dmUgdGhlIGN1cnJlbnQgDQo+IG5vbi1tb2JpbGl0eS1hd2FyZSBSQSBiZWhhdmlvciB1bmNoYW5n ZWQuIEJ1dCwgcGVvcGxlIGRlcGxveWluZyBNb2JpbGUgSVB2NiANCj4gd2lsbCBkbyB3aGF0ZXZl ciB0aGV5IHdhbnQuDQoNCldpdGggdGhpcyBkcmFmdCwgd2UgdHJ5IHRvIHB1dCBpbnB1dCBmb3Ig TkQgdXBkYXRlLiBTbyB3ZSBlbXBoYXNpemVkIG9uIHByb2JsZW1zIA0KYW5kIGdhdmUganVzdCBh IGJyaWVmIHNrZXRjaCBvZiBwb3NzaWJsZSBzb2x1dGlvbnMuIEkgdGhpbmsgaXQncyBETkEgd2hp Y2ggd2lsbCBkZXNpZ24gDQpNRC8gRE5BIHNvbHV0aW9uLiANCg0KTXVsdGlwbGUgcHJlZml4ZXMg b24gYSBtdWx0aXBsZSBsaW5rcyB3aXRoIG11bHRpcGxlIHJvdXRlcnMgbWFrZXMgTUQgdmVyeSBj b21wbGV4LiANCk1heWJlIHdlIG5lZWQgc29tZSBndWlkZWxpbmUgZm9yIHByZWZpeCBhc3NpZ25t ZW50LiBJTUhPLCB3ZSdkIGJldHRlciBoYXZlIA0KYmV0dGVyIHVuZGVyc3RhbmRpbmcgb24gTUQg aXNzdWVzLiAgICAgDQogDQo+ID4gPiBJJ20gbm90IGV4YWN0bHkgc3VyZSB3aGF0IHRoZSBwdXJw b3NlIG9mIG5vbi1vbi1saW5rIA0KPiA+IHByZWZpeGVzIGlzLCBidXQgDQo+ID4gPiBJIGFncmVl LCBpdCBjZXJ0YWlubHkgY29uZnVzZXMgdGhpbmdzLg0KPiA+IA0KPiA+IElNTywgdGhlIHB1cnBv c2Ugb2Ygbm9uLW9uLWxpbmsgcHJlZml4IGlzIHRvIGNoZWNrIHRoZSANCj4gPiB2YWxpZGl0eSBv ZiBJUCBhZGRyZXNzLiANCj4gPiANCj4gPiBJdCBtZWFucyB0aGF0IGFuIGFkdmVydGlzaW5nIHJv dXRlciBpbmplY3RzIHRoZSByb3V0ZSBmb3IgDQo+ID4gdGhhdCBwcmVmaXggaW50byBJbnRlcm5l dC4gDQo+ID4gQXNzdW1lIGEgbm9kZSBoYXMgYW4gSVAgYWRkcmVzcyB3aG9zZSBwcmVmaXggaXMg YWR2ZXJ0aXNlZCBpbiANCj4gPiB0aGF0IGxpbmsgYXMgDQo+ID4gbm9uLW9uLWxpbmsgcHJlZml4 LiAoRm9yIGNvbnZlbmllbmNlLCBsZXQncyBhc3N1bWUgdGhhdCANCj4gPiBhZGRyZXNzIGlzIGds b2JhbGx5IA0KPiA+IHVuaXF1ZS4pIFRoZW4gSW50ZXJuZXQgcm91dGluZyBtZWNoYW5pc20gd2ls bCBmb3J3YXJkICB0byANCj4gPiB0aGF0IG5vZGUgYW55IHBhY2tldCANCj4gPiBkZXN0aW5lZCBm b3IgdGhhdCBhZGRyZXNzLiAgDQo+IA0KPiBZZXMsIHRoYXQncyB0aGUgbWVjaGFuaWNzIG9mIGl0 LiBJIHdhcyBzYXlpbmcgdGhhdCBJIGRpZG4ndCB1bmRlcnN0YW5kIHdoeSBpdCANCj4gd291bGQg bmVlZCB0byBiZSB1c2VkLiBBY3R1YWxseSwgSSBqdXN0IHRob3VnaHQgb2YgYSBnb29kIHNjZW5h cmlvIHdoZXJlIGl0IA0KDQpBZnRlciBtb3ZlbWVudCwgYSBub2RlIGNhbiB1c2UgaXQgdG8gY2hl Y2sgd2hldGhlciBpdCdzIGN1cnJlbnQgSVAgYWRkcmVzcyANCmlzIHN0aWxsIHZhbGlkLiBJZiB0 aGUgcHJlZml4IG9mIGl0cyBjdXJyZW50IElQIGFkZHJlc3MgaXMgaW4gYW4gYWR2ZXJ0aXNlZCBS QSwgdGhlIA0KYWRkcmVzcyBpcyB0b3BvbG9naWNhbGx5IGNvcnJlY3QgKHdoZXRoZXIgTD0wIG9y IEw9MSkgYW5kIGEgbm9kZSBjYW4ga2VlcA0KdXNpbmcgaXQgKG1heWJlIGFmdGVyIERBRCkuICAg IA0KDQpCZXN0IHJlZ2FyZHMNCg0KSmluSHllb2NrDQoNClAuUyBJIGJyaW5nIG91ciBkaXNjdXNz aW9uIG91dCBzbyB0aGF0IG90aGVyIHBlb3BsZSBtYXkgYmUgaW5mb3JtZWQgYW5kIA0Kam9pbiBp dC4gDQoNCj4gSmluSHllb2NrIC0NCj4gDQo+ID4gVGhpcyBpcyB0aGUgbWVzc3kgc2NlbmFyaW8g SSBhbSB3b3JyaWVkIG9mLiANCj4gPiANCj4gPiAxKSBBbiBNTiBpcyBpbiBDZWxsIDEsIGhhdmlu ZyBhIENvQSB3aXRoIFByZWZpeCBBOjogDQo+ID4gMikgVGhlIE1OIG1vdmVzIHRvIENlbGwgMiBh bmQgcmVjZWl2ZXMgYSBSQSB3aXRoIExpbmtJRCBhbmQgDQo+ID4gb25seSBQcmVmaXggQjo6Lg0K PiA+IDMpIE1OIGFzc3VtZXMgaXQgaGFzIG1vdmVkIGFuZCBmb3JtcyBhIG5ldyBDb0Egd2l0aCBQ cmVmaXggQjo6Lg0KPiA+IDQpIE1OIHNlbmRzIEJVIHdpdGggdGhlIENvQSB3aXRoIFByZWZpeCBC OjosIHNvIHVubmVjZXNzYXJ5IA0KPiA+IEJVIGhhcHBlbnMuDQo+IA0KPiBVbm5lY2Vzc2FyeSBC VSBpcyBub3QgYSBodWdlIHByb2JsZW0uIFNvIHlvdSBnZXQgYW4gZXh0cmEgTDMgaGFuZG92ZXIu IExldCdzIA0KPiBrZWVwIHRoaW5ncyBzaW1wbGUuLi4gSU1PIHRoaXMgc2NlbmFyaW8geW91IGhh dmUgaWRlbnRpZmllZCBpcyBub3QgYSBnb29kIA0KPiByZWFzb24gZm9yIGludHJvZHVjaW5nIGEg bmV3IGJpdCBpbiB0aGUgUkEuIEFsc28sIEkgc3RpbGwgYmVsaWV2ZSB0aGF0IHRoZSBuZXcgDQo+ IHByb3Bvc2VkIExpbmsgSWRlbnRpZmllciBSQSBvcHRpb24gaXMgYW4gZXhjZWxsZW50IHNvbHV0 aW9uLCBpZiB5b3UgbmVlZCB0byANCj4gdXNlIFJBcyBmb3IgbW92ZW1lbnQgZGV0ZWN0aW9uIGJl Y2F1c2UgeW91IGRvbid0IGhhdmUgcmVsaWFibGUgTDIgdHJpZ2dlcnMgdG8gDQo+IGdpdmUgeW91 IHRoZSBzYW1lIGluZm9ybWF0aW9uLiBTb21lIGxpbmsgdHlwZXMgbGlrZSBXaUZpIHdpbGwgaGF2 ZSByZWxpYWJsZSBMMiANCj4gdHJpZ2dlcnMgdGhhdCBjYW4gYmUgdXNlZCB0byBkZXRlY3QgYSBj aGFuZ2Ugb2YgbmV0d29yayAoRVNTSUQsIGZvciBXaUZpKS4gSW4gDQo+IHRoYXQgY2FzZSwgSU1I TyBpdCBpcyBwcmVmZXJhYmxlIHRvIHVzZSB0aGUgTDIgdHJpZ2dlcnMgYW5kIGxlYXZlIHRoZSBj dXJyZW50IA0KPiBub24tbW9iaWxpdHktYXdhcmUgUkEgYmVoYXZpb3IgdW5jaGFuZ2VkLiBCdXQs IHBlb3BsZSBkZXBsb3lpbmcgTW9iaWxlIElQdjYgDQo+IHdpbGwgZG8gd2hhdGV2ZXIgdGhleSB3 YW50Lg0KPiANCj4gPiA+IEknbSBub3QgZXhhY3RseSBzdXJlIHdoYXQgdGhlIHB1cnBvc2Ugb2Yg bm9uLW9uLWxpbmsgDQo+ID4gcHJlZml4ZXMgaXMsIGJ1dCANCj4gPiA+IEkgYWdyZWUsIGl0IGNl cnRhaW5seSBjb25mdXNlcyB0aGluZ3MuDQo+ID4gDQo+ID4gSU1PLCB0aGUgcHVycG9zZSBvZiBu b24tb24tbGluayBwcmVmaXggaXMgdG8gY2hlY2sgdGhlIA0KPiA+IHZhbGlkaXR5IG9mIElQIGFk ZHJlc3MuIA0KPiA+IA0KPiA+IEl0IG1lYW5zIHRoYXQgYW4gYWR2ZXJ0aXNpbmcgcm91dGVyIGlu amVjdHMgdGhlIHJvdXRlIGZvciANCj4gPiB0aGF0IHByZWZpeCBpbnRvIEludGVybmV0LiANCj4g PiBBc3N1bWUgYSBub2RlIGhhcyBhbiBJUCBhZGRyZXNzIHdob3NlIHByZWZpeCBpcyBhZHZlcnRp c2VkIGluIA0KPiA+IHRoYXQgbGluayBhcyANCj4gPiBub24tb24tbGluayBwcmVmaXguIChGb3Ig Y29udmVuaWVuY2UsIGxldCdzIGFzc3VtZSB0aGF0IA0KPiA+IGFkZHJlc3MgaXMgZ2xvYmFsbHkg DQo+ID4gdW5pcXVlLikgVGhlbiBJbnRlcm5ldCByb3V0aW5nIG1lY2hhbmlzbSB3aWxsIGZvcndh cmQgIHRvIA0KPiA+IHRoYXQgbm9kZSBhbnkgcGFja2V0IA0KPiA+IGRlc3RpbmVkIGZvciB0aGF0 IGFkZHJlc3MuICANCj4gDQo+IFllcywgdGhhdCdzIHRoZSBtZWNoYW5pY3Mgb2YgaXQuIEkgd2Fz IHNheWluZyB0aGF0IEkgZGlkbid0IHVuZGVyc3RhbmQgd2h5IGl0IA0KPiB3b3VsZCBuZWVkIHRv IGJlIHVzZWQuIEFjdHVhbGx5LCBJIGp1c3QgdGhvdWdodCBvZiBhIGdvb2Qgc2NlbmFyaW8gd2hl cmUgaXQgDQo+IG1ha2VzIHNlbnNlIHRvIHVzZSBhIG5vbi1vbi1saW5rIHByZWZpeDogUFBQdjYu IElmIHRoZSBuZXR3b3JrIHNlbmRzIGEgUkEgDQo+IGNvbnRhaW5pbmcgcHJlZml4KGVzKSBmb3Ig c3RhdGVsZXNzIGFkZHJlc3MgYXV0by1jb25maWd1cmF0aW9uIG92ZXIgUFBQdjYgdG8gYSANCj4g aG9zdCwgaXQgY291bGQgYWxsb3cgdGhhdCBzYW1lIHByZWZpeCB0byBiZSB1c2VkIGZvciBzdGF0 ZWxlc3MgYWRkcmVzcyBhdXRvLQ0KPiBjb25maWd1cmF0aW9uIG9uIG90aGVyIFBQUHY2IGxpbmtz LCBiZWNhdXNlIHRoZSBuZXR3b3JrIGhhcyBjb250cm9sIG92ZXIgdGhlIA0KPiBhc3NpZ25tZW50 IG9mIHRoZSBQUFB2NiBFVUktNjQgaW50ZXJmYWNlIElEcyBzaW5jZSB0aGF0IGlzIGFuIG9wdGlv biANCj4gbmVnb3RpYXRlZCBieSBQUFB2Ni4NCj4gIA0KPiA+IFAuUy4gQ2FuIEkgc2VuZCBhIGNv cHkgb2YgdGhpcyB0byBJUHY2IFdHPyANCj4gU3VyZSwgbm8gbmVlZCB0byBhc2sgbWUuIFlvdSBj YW4gc2VuZCB0aGUgd2hvbGUgdGhyZWFkIGlmIHlvdSdkIGxpa2UgOy0pDQo+IA0KPiBUaGFua3Mu DQo+IC0gRWQNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBUaGlzIEUtTWFpbCB3YXMgc2VudCB3aXRoIE1haWxNYXgvV0VCLg0KPiBodHRwOi8vd3d3 LnNtYXJ0bWF4LmNvbQ0KPg0KPiANCj4gDQo+IA0KPiA+IERlYXIgRWQNCj4gPiANCj4gPiBUaGFu a3MgZm9yIHlvdXIgY29tbWVudHMuIA0KPiA+IA0KPiA+ID4gSSBkaXNhZ3JlZS4gV2hhdCBkb2Vz IHRoZSBNTiBsb3NlIGJ5IHBlcmZvcm1pbmcgYSBMMyBtb3ZlIGluIHRoaXMgY2FzZT8NCj4gPiA+ IE5vdCB2ZXJ5IG11Y2guIFRoZSBNTiBuZWVkcyB0byByZWNlaXZlIHRoZSBSQSBmaXJzdCBiZWZv cmUgZGV0ZWN0aW5nDQo+ID4gPiBtb3ZlbWVudCAoTDIgdHJpZ2dlcnMgYXJlIGZhc3RlciAtIFJB cyBjYW4gYmUgZGVsYXllZCkuIEkgaGF2ZSBzZWVuIG91cg0KPiA+ID4gTU4gaW1wbGVtZW50YXRp b24gcmVnaXN0ZXIgYSBuZXcgY2FyZS1vZiBhZGRyZXNzIHdpdGggdGhlIEhBIGluIGxlc3MNCj4g PiA+IHRoYW4gMSBtaWxsaXNlY29uZCAodGhhdCB3YXMgd2l0aG91dCBJUHNlYykuIFNvLCB0aGUg TU4gZHJvcHMgdGhlIENvQQ0KPiA+IA0KPiA+IFRoYSdzIGltcHJlc3NpdmUuIEJ1dCBob3cgYWJv dXQgREFEPyAgDQo+ID4gDQo+ID4gPiB3aXRoIHByZWZpeCBBOiwgZG9lcyBhIEwzIG1vdmUgYmVj YXVzZSB0aGUgbGluayBpZGVudGlmaWVyIGNoYW5nZWQsIGFuZA0KPiA+ID4gdGhlbiByZWRpc2Nv dmVycyBwcmVmaXggQTogYW5kIGF1dG8tY29uZmlndXJlcyB0aGUgc2FtZSBDb0EgYWdhaW4gYW5k DQo+ID4gPiByZXJlZ2lzdGVycyBpdCB3aXRoIHRoZSBIQS4uLiB0aGF0IGlzbid0IGEgYmlnIHBy b2JsZW0sIGFzIGZhciBhcyBJJ20NCj4gPiA+IGNvbmNlcm5lZC4gSW4gZmFjdCwgYWxsIG9mIHRo ZSBleHRyYSBwcm90b2NvbCBvdmVyaGVhZCBpbnZvbHZlZCBpbg0KPiA+IA0KPiA+IFRoaXMgaXMg dGhlIG1lc3N5IHNjZW5hcmlvIEkgYW0gd29ycmllZCBvZi4gDQo+ID4gDQo+ID4gMSkgQW4gTU4g aXMgaW4gQ2VsbCAxLCBoYXZpbmcgYSBDb0Egd2l0aCBQcmVmaXggQTo6IA0KPiA+IDIpIFRoZSBN TiBtb3ZlcyB0byBDZWxsIDIgYW5kIHJlY2VpdmVzIGEgUkEgd2l0aCBMaW5rSUQgYW5kIG9ubHkg UHJlZml4IEI6Oi4NCj4gPiAzKSBNTiBhc3N1bWVzIGl0IGhhcyBtb3ZlZCBhbmQgZm9ybXMgYSBu ZXcgQ29BIHdpdGggUHJlZml4IEI6Oi4NCj4gPiA0KSBNTiBzZW5kcyBCVSB3aXRoIHRoZSBDb0Eg d2l0aCBQcmVmaXggQjo6LCBzbyB1bm5lY2Vzc2FyeSBCVSBoYXBwZW5zLg0KPiA+IA0KPiA+ID4g SSdtIG5vdCBleGFjdGx5IHN1cmUgd2hhdCB0aGUgcHVycG9zZSBvZiBub24tb24tbGluayBwcmVm aXhlcyBpcywgYnV0IEkNCj4gPiA+IGFncmVlLCBpdCBjZXJ0YWlubHkgY29uZnVzZXMgdGhpbmdz LiANCj4gPiANCj4gPiBJTU8sIHRoZSBwdXJwb3NlIG9mIG5vbi1vbi1saW5rIHByZWZpeCBpcyB0 byBjaGVjayB0aGUgdmFsaWRpdHkgb2YgSVAgYWRkcmVzcy4gDQo+ID4gDQo+ID4gSXQgbWVhbnMg dGhhdCBhbiBhZHZlcnRpc2luZyByb3V0ZXIgaW5qZWN0cyB0aGUgcm91dGUgZm9yIHRoYXQgcHJl Zml4IGludG8gSW50ZXJuZXQuIA0KPiA+IEFzc3VtZSBhIG5vZGUgaGFzIGFuIElQIGFkZHJlc3Mg d2hvc2UgcHJlZml4IGlzIGFkdmVydGlzZWQgaW4gdGhhdCBsaW5rIGFzIA0KPiA+IG5vbi1vbi1s aW5rIHByZWZpeC4gKEZvciBjb252ZW5pZW5jZSwgbGV0J3MgYXNzdW1lIHRoYXQgYWRkcmVzcyBp cyBnbG9iYWxseSANCj4gPiB1bmlxdWUuKSBUaGVuIEludGVybmV0IHJvdXRpbmcgbWVjaGFuaXNt IHdpbGwgZm9yd2FyZCAgdG8gdGhhdCBub2RlIGFueSBwYWNrZXQgDQo+ID4gZGVzdGluZWQgZm9y IHRoYXQgYWRkcmVzcy4gIA0KPiA+IA0KPiA+IEkgd2lzaCB0aGUgYWJvdmUgaGVscHMuIEJ1dCB3 ZSdkIGJldHRlciBjaGVjayB3aXRoIHRoZSBhdXRob3JzLiBFcmlrIG9yIFRob21hcy4gIA0KPiA+ IA0KPiA+ID4gQnV0IGluIHRoaXMgY2FzZSwgSSB3b3VsZCBqdXN0DQo+ID4gPiBpZ25vcmUgdGhp cyBwYXRob2xvZ2ljYWwgc2NlbmFyaW8uDQo+ID4gDQo+ID4gVGhpcyBtYXkgYmUgcHJhY3RpY2Fs LiBCdXQgbXkgcG9pbnQgaXMgdGhhdCBpdCBpcyB3b3J0aHdoaWxlIHRvIGludmVzdGlnYXRlIHRo ZSANCj4gPiBtZXRob2Qgb2YgYWRkaW5nIG9uZSBhZGRpdGlvbmFsIGJpdCB0byBmYWNpbGl0YXRl IGVmZmljaWVudCBNRC4gDQo+ID4gDQo+ID4gQXMgYmVmb3JlLCBpdCdzIGlsbHVtaW5hdGluZyB0 byBleGNoYW5nZSBvcGluaW9ucyB3aXRoIHlvdS4gSSB3aXNoIHdlIHdpbGwgaGF2ZSANCj4gPiBh IGZhY2UgdG8gZmFjZSBkaXNjdXNzaW9uIGF0IE1pbm5lYXBvbGlzLiAgIA0KPiA+IA0KPiA+IEJl c3QgcmVnYXJkcw0KPiA+IA0KPiA+IEppbkh5ZW9jaw0KPiA+IA0KPiA+IFAuUy4gQ2FuIEkgc2Vu ZCBhIGNvcHkgb2YgdGhpcyB0byBJUHY2IFdHPyANCj4gPiANCj4gPg0KPiA+IA0KPiA+IA0KPiA+ ID4gPiBJIGFtIGFmcmFpZCB0aGF0IHRoZXJlIGlzIHNvbWUgcGF0aG9sb2dpY2FsIGNhc2UgaW4g d2hpY2ggDQo+ID4gPiA+IGxpbmsgaWRlbnRpZmllciBpcyANCj4gPiA+ID4gbm90IHN1ZmZpY2ll bnQuIEhlcmUgaXMgYW4gZXhhbXBsZS4gS2luZGx5IGZpbmQgYW4gYXR0YWNoZWQgDQo+ID4gPiA+ IGZpbGUuIEl0J3MgZGlmZmljdWx0IHRvIGRyYXcgYSBmaWd1cmUgaW4gdGV4dCBmaWxlLiANCj4g PiA+ID4gDQo+ID4gPiA+IEluIHRoZSBmaWd1cmUsIGFuIHJvdXRlciBoYXMgdHdvIGludGVyZmFj ZXMsIGludGVyZmFjZSAxIGFuZCANCj4gPiA+ID4gaW50ZXJmYWNlIDIuIFRvIGVhY2ggDQo+ID4g PiA+IGludGVyZmFjZSwgYW4gQVAgKGhlbmNlIGEgY2VsbCkgaXMgYXR0YWNoZWQuIEludGVyZmFj ZSAxIA0KPiA+ID4gPiBhZHZlcnRpc2VzIHRoZSBwcmVmaXggQTo6IA0KPiA+ID4gPiBhbmQgaW50 ZXJmYWNlIDIgYWR2ZXJ0aXNlcyBQcmVmaXggQTo6YW5kIEI6Oi4gDQo+ID4gPiA+IA0KPiA+ID4g PiBDZWxsIDEgYW5kIENlbGwgMiBjYW4ndCBoYXZlIHRoZSBzYW1lIGxpbmsgaWRlbnRpZmllci4g SWYgTU4gDQo+ID4gPiA+IG1vdmVzIGZyb20gQ2VsbCAxIHRvIA0KPiA+ID4gPiBDZWxsIDIsIGl0 IGNhbiBrZWVwIHVzaW5nIGl0cyBjdXJyZW50IENvQSB3aXRoIFByZWZpeCBBOjouIA0KPiA+ID4g PiBCdXQgaWYgTU4gaGF2aW5nIENvQSB3aXRoIA0KPiA+ID4gPiBQcmVmaXggQjo6IG1vdmVzIGZy b20gQ2VsbCAyIHRvIENlbGwgMSwgaXQgY2FuJ3QgdXNlIGl0cyBDb0EgYW55bW9yZS4gDQo+ID4g PiA+IA0KPiA+ID4gPiBTbyBNTiBjYW4ndCBjaGVjayB0aGUgdmFsaWRpdHkgb2YgaXRzIGN1cnJl bnQgQ29BIHdpdGggTGluayANCj4gPiA+ID4gSWRlbnRpZmllciBvbmx5LiANCj4gPiA+ID4gDQo+ ID4gPiANCj4gPiA+IEppbkh5ZW9jayAtDQo+ID4gPiANCj4gPiA+IEkgZGlzYWdyZWUuIFdoYXQg ZG9lcyB0aGUgTU4gbG9zZSBieSBwZXJmb3JtaW5nIGEgTDMgbW92ZSBpbiB0aGlzIGNhc2U/DQo+ ID4gPiBOb3QgdmVyeSBtdWNoLiBUaGUgTU4gbmVlZHMgdG8gcmVjZWl2ZSB0aGUgUkEgZmlyc3Qg YmVmb3JlIGRldGVjdGluZw0KPiA+ID4gbW92ZW1lbnQgKEwyIHRyaWdnZXJzIGFyZSBmYXN0ZXIg LSBSQXMgY2FuIGJlIGRlbGF5ZWQpLiBJIGhhdmUgc2VlbiBvdXINCj4gPiA+IE1OIGltcGxlbWVu dGF0aW9uIHJlZ2lzdGVyIGEgbmV3IGNhcmUtb2YgYWRkcmVzcyB3aXRoIHRoZSBIQSBpbiBsZXNz DQo+ID4gPiB0aGFuIDEgbWlsbGlzZWNvbmQgKHRoYXQgd2FzIHdpdGhvdXQgSVBzZWMpLiBTbywg dGhlIE1OIGRyb3BzIHRoZSBDb0ENCj4gPiA+IHdpdGggcHJlZml4IEE6LCBkb2VzIGEgTDMgbW92 ZSBiZWNhdXNlIHRoZSBsaW5rIGlkZW50aWZpZXIgY2hhbmdlZCwgYW5kDQo+ID4gPiB0aGVuIHJl ZGlzY292ZXJzIHByZWZpeCBBOiBhbmQgYXV0by1jb25maWd1cmVzIHRoZSBzYW1lIENvQSBhZ2Fp biBhbmQNCj4gPiA+IHJlcmVnaXN0ZXJzIGl0IHdpdGggdGhlIEhBLi4uIHRoYXQgaXNuJ3QgYSBi aWcgcHJvYmxlbSwgYXMgZmFyIGFzIEknbQ0KPiA+ID4gY29uY2VybmVkLiBJbiBmYWN0LCBhbGwg b2YgdGhlIGV4dHJhIHByb3RvY29sIG92ZXJoZWFkIGludm9sdmVkIGluDQo+ID4gPiByZXJlZ2lz dGVyaW5nIHRoZSBzYW1lIENvQSB0aHJvdWdoIHRoZSBuZXcgcm91dGVyIGlzIG5lZWRlZCB0byB0 ZWxsIHRoZQ0KPiA+ID4gbmV0d29yayB0aGF0IHRoYXQgQ29BIGlzIG5vdyByZWFjaGFibGUgdGhy b3VnaCB0aGUgbmV3IHJvdXRlciwgbm90IHRoZQ0KPiA+ID4gb2xkIHJvdXRlci4NCj4gPiA+IA0K PiA+ID4gSSdtIG5vdCBleGFjdGx5IHN1cmUgd2hhdCB0aGUgcHVycG9zZSBvZiBub24tb24tbGlu ayBwcmVmaXhlcyBpcywgYnV0IEkNCj4gPiA+IGFncmVlLCBpdCBjZXJ0YWlubHkgY29uZnVzZXMg dGhpbmdzLiBCdXQgaW4gdGhpcyBjYXNlLCBJIHdvdWxkIGp1c3QNCj4gPiA+IGlnbm9yZSB0aGlz IHBhdGhvbG9naWNhbCBzY2VuYXJpby4NCj4gPiA+IA0KPiA+ID4gVGhhbmtzLg0KPiA+ID4gLSBF ZA0KPiA+ID4gDQo+ID4gPiAtLS0NCj4gPiA+IE91dGdvaW5nIG1haWwgaXMgY2VydGlmaWVkIFZp cnVzIEZyZWUuDQo+ID4gPiBDaGVja2VkIGJ5IEFWRyBhbnRpLXZpcnVzIHN5c3RlbSAoaHR0cDov L3d3dy5ncmlzb2Z0LmNvbSkuDQo+ID4gPiBWZXJzaW9uOiA2LjAuNTIyIC8gVmlydXMgRGF0YWJh c2U6IDMyMCAtIFJlbGVhc2UgRGF0ZTogOS8yOS8yMDAzDQo+ID4gPiAgDQo+ID4gPiANCj4gPiA+ IA0KPiA+ID4gDQo+ID4gPiA+IERlYXIgRWQNCj4gPiA+ID4gDQo+ID4gPiA+IFRoYW5rcyBmb3Ig cHJvbXB0IGFuZCBoZWxwZnVsIHJlcGx5LiANCj4gPiA+ID4gDQo+ID4gPiA+IEluIHRoaXMgZHJh ZnQsIHdlIHRyeSB0byBmb2N1cyBvbiBwcm9ibGVtcyBhbmQgcHJlc2VudCBvbmx5IHRoZSBza2V0 Y2ggb2YgDQo+ID4gPiA+IHNvbHV0aW9ucy4gV2Ugd2lsbCBwcmVzZW50IG1vcmUgZGV0YWlsZWQg c29sdXRpb24gbGF0ZXIuIA0KPiA+ID4gPiANCj4gPiA+ID4gPiBBY3R1YWxseSwgdGhlIGxpbmsg aWRlbnRpZmllciBvcHRpb24gZHJhZnQgd291bGQgcmVzb2x2ZSB0aGlzIGlzc3VlLCBhbHNvLiBU aGUgDQo+ID4gPiA+ID4gTU4gdXNlcyB0aGUgUkEgdG8gZGV0ZWN0IG1vdmVtZW50IChhc3N1bWlu ZyBMMiB0cmlnZ2VycyBhcmUgbm90IGF2YWlsYWJsZSkuIEEgDQo+ID4gPiA+ID4gY2hhbmdlIGlu IGxpbmsgaWRlbnRpZmllciBpbiB0aGUgUkEgaXMgZW5vdWdoIG9mIGFuIGluZGljYXRpb24gdGhh dCBtb3ZlbWVudCANCj4gPiA+ID4gPiBoYXMgb2NjdXJyZWQuDQo+ID4gPiA+IA0KPiA+ID4gPiBJ IGFtIGFmcmFpZCB0aGF0IHRoZXJlIGlzIHNvbWUgcGF0aG9sb2dpY2FsIGNhc2UgaW4gd2hpY2gg bGluayBpZGVudGlmaWVyIGlzIA0KPiA+ID4gPiBub3Qgc3VmZmljaWVudC4gSGVyZSBpcyBhbiBl eGFtcGxlLiBLaW5kbHkgZmluZCBhbiBhdHRhY2hlZCBmaWxlLiBJdCdzIGRpZmZpY3VsdA0KPiA+ ID4gPiB0byBkcmF3IGEgZmlndXJlIGluIHRleHQgZmlsZS4gDQo+ID4gPiA+IA0KPiA+ID4gPiBJ biB0aGUgZmlndXJlLCBhbiByb3V0ZXIgaGFzIHR3byBpbnRlcmZhY2VzLCBpbnRlcmZhY2UgMSBh bmQgaW50ZXJmYWNlIDIuIFRvIGVhY2ggDQo+ID4gPiA+IGludGVyZmFjZSwgYW4gQVAgKGhlbmNl IGEgY2VsbCkgaXMgYXR0YWNoZWQuIEludGVyZmFjZSAxIGFkdmVydGlzZXMgdGhlIHByZWZpeCBB OjogDQo+ID4gPiA+IGFuZCBpbnRlcmZhY2UgMiBhZHZlcnRpc2VzIFByZWZpeCBBOjphbmQgQjo6 LiANCj4gPiA+ID4gDQo+ID4gPiA+IENlbGwgMSBhbmQgQ2VsbCAyIGNhbid0IGhhdmUgdGhlIHNh bWUgbGluayBpZGVudGlmaWVyLiBJZiBNTiBtb3ZlcyBmcm9tIENlbGwgMSB0byANCj4gPiA+ID4g Q2VsbCAyLCBpdCBjYW4ga2VlcCB1c2luZyBpdHMgY3VycmVudCBDb0Egd2l0aCBQcmVmaXggQTo6 LiBCdXQgaWYgTU4gaGF2aW5nIENvQSB3aXRoIA0KPiA+ID4gPiBQcmVmaXggQjo6IG1vdmVzIGZy b20gQ2VsbCAyIHRvIENlbGwgMSwgaXQgY2FuJ3QgdXNlIGl0cyBDb0EgYW55bW9yZS4gDQo+ID4g PiA+IA0KPiA+ID4gPiBTbyBNTiBjYW4ndCBjaGVjayB0aGUgdmFsaWRpdHkgb2YgaXRzIGN1cnJl bnQgQ29BIHdpdGggTGluayBJZGVudGlmaWVyIG9ubHkuIA0KPiA+ID4gPiANCj4gPiA+ID4gTXVs dGlwbGUgcm91dGVycyBvbiBtdWx0aXBsZSBsaW5rcyB3aXRoIG11bHRpcGxlIHByZWZpeGVzIG1h a2UgTUQgdmVyeSBjb21wbGV4LiANCj4gPiA+ID4gSSB0aGluayB3ZSdkIGJldHRlciBoYXZlIG1v cmUgY2xlYXIgdW5kZXJzdGFuZGluZy4gTWF5YmUgYXQgRE5BLiBJIHdpc2ggeW91IA0KPiA+ID4g PiBwYXJ0aWNpcGF0ZSBhdCAmIGNvbnRyaWJ1dGUgdG8gRE5BIG1lZXRpbmcgYXQgTWlubmVhcG9s aXMuICAgIA0KPiA+ID4gPiAgDQo+ID4gPiA+ID4gSSBsb29rZWQgYXQgeW91ciBkcmFmdCwgaXQg aXMgYSB2ZXJ5IGNsZWFyIGFuZCBhY2N1cmF0ZSBkZXNjcmlwdGlvbiBvZiB0aGUgDQo+ID4gPiA+ ID4gY3VycmVudCBpc3N1ZXMgd2l0aCBSQXMgdy8gcmVnYXJkcyB0byB1c2luZyB0aGVtIGZvciBt b3ZlbWVudCBkZXRlY3Rpb24uDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBTZWN0aW9uIDIuMzoNCj4g PiA+ID4gPiAiICAgSXQgbWF5IHVzZWZ1bCB0byBhc3NpZ24gUyBiaXQsIGluIHRoZSBjYXNlIHdo ZXJlIHdlIHdhbnQgbm9kZXMgdG8gYmUgDQo+ID4gPiA+ID4gICAgYWJsZSB0byBkZXRlcm1pbmUg dGhhdCB0aGV5IGhhdmUgcmVjZWl2ZWQgYSBzb2xpY2l0ZWQgcm91dGVyIA0KPiA+ID4gPiA+ICAg IGFkdmVydGlzZW1lbnQuIFdpdGggUyBiaXQsIGEgbm9kZSBjYW4gY29uZmlybSByZWFjaGFiaWxp dHkgd2l0aCBvbmx5IA0KPiA+ID4gPiA+ICAgIFJTLyBSQSBleGNoYW5nZS4iDQo+ID4gPiA+ID4g DQo+ID4gPiA+ID4gQSBuZXcgYml0IGlzIG5vdCBuZWVkZWQgaGVyZS4gSWYgdGhlIFJBIGlzIHNl bnQgdG8gYSB1bmljYXN0IGRlc3RpbmF0aW9uIElQdjYgDQo+ID4gPiA+ID4gYWRkcmVzcyB0aGF0 IGlzIGxvY2FsIHRvIHRoZSBNTiwgdGhhdCBpcyBzdWZmaWNpZW50LiBCdXQsIHRoZSByb3V0ZXIg d2lsbCANCj4gPiA+ID4gDQo+ID4gPiA+IEkgYWdyZWUgd2l0aCB5b3UuIEJ1dCBjYW4gd2UgdXNl IGl0IHRvIGNvbmZpcm0gYmktZGlyZWN0aW9uYWwgcmVhY2hhYmlsaXR5PyBJIGhvcGUgDQo+ID4g PiA+IFdHIHdpbGwgZGVjaWRlIHNvLiAgIA0KPiA+ID4gPiANCj4gPiA+ID4gPiBwcm9iYWJseSBz ZW5kIHRoZSBSQSB0byBhIG11bHRpY2FzdCBkZXN0aW5hdGlvbiBhZGRyZXNzICh3aGVuIHNvbGlj aXRlZCBieSBSUykgDQo+ID4gPiA+ID4gYmVjYXVzZSB0aGF0J3Mgd2hhdCBSRkMtMjQ2MSByZWNv bW1lbmRzIHRvIGRvLg0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IFNlY3Rpb24gMy4xOg0KPiA+ID4g PiA+ICIgICBXZSBwcm9wb3NlIHRvIGFzc2lnbiBhIG5ldyBiaXQgKENvbXBsZXRlIGJpdCkgaW4g UkEgbWVzc2FnZSB0byANCj4gPiA+ID4gPiAgICBpbmRpY2F0ZSBpdHMgY29tcGxldGVuZXNzLiBX aGVuIENvbXBsZXRlIGJpdCBpcyBzZXQsIGl0IG1lYW5zIHRoZSBSQSANCj4gPiA+ID4gPiAgICBj b250YWlucyBhbGwgdGhlIG9wdGlvbnMgKGluY2x1ZGluZyBhbGwgdGhlIFByZWZpeCBJbmZvcm1h dGlvbiANCj4gPiA+ID4gPiAgICBPcHRpb25zKS4iDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gV2Vs bCwgdGhpcyBkb2Vzbid0IGZpdCB0b28gd2VsbCB3aXRoIGZyZXF1ZW50IFJBIGJlYWNvbnMgKyBN TiBFYWdlciBDZWxsIA0KPiA+ID4gPiA+IFN3aXRjaGluZy4gSW4gdGhhdCBjYXNlLCB5b3Ugd2Fu dCB0aGUgUkEgdG8gYmUgYXMgc21hbGwgYXMgcG9zc2libGUgd2hpbGUgDQo+ID4gPiA+ID4gc3Rp bGwgc3VwcG9ydGluZyBNTiBFYWdlciBDZWxsIFN3aXRjaGluZywgaS5lLiBSLWJpdCBvcHRpb24g aXMgcHJvYmFibHkgdGhlIA0KPiA+ID4gPiANCj4gPiA+ID4gSSBhZ3JlZSB0aGF0IGl0J3Mgbm90 IGEgZ29vZCBpZGVhIHRvIHNlbmQgQ29tcGxldGUgUkEgY29uc3RhbnRseS4gSXQgbWF5IHRha2Ug DQo+ID4gPiA+IHRvbyBtdWNoIGJhbmR3aWR0aC4gSSB0aGluayB3ZSdkIGJldHRlciBzZW5kIENv bXBsZXRlIFJBIG9ubHkgd2hlbiBpdCdzIA0KPiA+ID4gPiBiZW5lZmljaWFsLCBmb3IgZXhhbXBs ZSB3aGVuIGEgUlMgaXMgcmVjZWl2ZWQuIA0KPiA+ID4gPiANCj4gPiA+ID4gVGhhbmtzIGZvciB5 b3VyIGtpbmQgd29yZHMuIA0KPiA+ID4gPiAgDQo+ID4gPiA+IFdvdWxkIHlvdSBwdXQgeW91ciBj b21tZW50cyBpbiBJUHY2IG1haWxpbmcgbGlzdCBhbmQgYnJpbmcgdGhpcyBkaXNjdXNzaW9uIG91 dCwgDQo+ID4gPiA+IHNvIHRoYXQgb3RoZXIgcGVvcGxlIG1heSBiZSBpbmZvbWVkIGFuZCBqb2lu IGl0PyANCj4gPiA+ID4gDQo+ID4gPiA+IFdlIHJlcXVlc3RlZCBjaGFpcnMgZm9yIHRpbWUgc2xv dCBhdCBNaW5uZWFwb2xpcyBhbmQgaXQnbGwgaGVscCB1cyBpZiB0aGVyZSBpcyBhIA0KPiA+ID4g PiB0aHJlYWQgYWJvdXQgaXQuIFdlIGhhZCBhc2tlZCBhdCBTRiBidXQgZGVuaWVkIGZvciB0aGUg bGFjayBvZiBpbnRlcmVzdHMuIDotKA0KPiA+ID4gPiAgDQo+ID4gPiA+IFRoYW5rcyBmb3IgeW91 ciBraW5kIHdvcmRzIGFuZCBzZWUgeW91IGF0IE1pbm5lYXBvbGlzLiANCj4gPiA+ID4gDQo+ID4g PiA+IEJlc3QgcmVnYXJkcw0KPiA+ID4gPiANCj4gPiA+ID4gSmluSHllb2NrIENob2kNCj4gPiA+ ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+ID4gSmluSHllb2NrICYg R3JlZyAtDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gQWN0dWFsbHksIHRoZSBsaW5rIGlkZW50aWZp ZXIgb3B0aW9uIGRyYWZ0IHdvdWxkIHJlc29sdmUgdGhpcyBpc3N1ZSwgYWxzby4gVGhlIA0KPiA+ ID4gPiA+IE1OIHVzZXMgdGhlIFJBIHRvIGRldGVjdCBtb3ZlbWVudCAoYXNzdW1pbmcgTDIgdHJp Z2dlcnMgYXJlIG5vdCBhdmFpbGFibGUpLiBBIA0KPiA+ID4gPiA+IGNoYW5nZSBpbiBsaW5rIGlk ZW50aWZpZXIgaW4gdGhlIFJBIGlzIGVub3VnaCBvZiBhbiBpbmRpY2F0aW9uIHRoYXQgbW92ZW1l bnQgDQo+ID4gPiA+ID4gaGFzIG9jY3VycmVkLg0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IEkgbG9v a2VkIGF0IHlvdXIgZHJhZnQsIGl0IGlzIGEgdmVyeSBjbGVhciBhbmQgYWNjdXJhdGUgZGVzY3Jp cHRpb24gb2YgdGhlIA0KPiA+ID4gPiA+IGN1cnJlbnQgaXNzdWVzIHdpdGggUkFzIHcvIHJlZ2Fy ZHMgdG8gdXNpbmcgdGhlbSBmb3IgbW92ZW1lbnQgZGV0ZWN0aW9uLg0KPiA+ID4gPiA+IA0KPiA+ ID4gPiA+IFNlY3Rpb24gMi4zOg0KPiA+ID4gPiA+ICIgICBJdCBtYXkgdXNlZnVsIHRvIGFzc2ln biBTIGJpdCwgaW4gdGhlIGNhc2Ugd2hlcmUgd2Ugd2FudCBub2RlcyB0byBiZSANCj4gPiA+ID4g PiAgICBhYmxlIHRvIGRldGVybWluZSB0aGF0IHRoZXkgaGF2ZSByZWNlaXZlZCBhIHNvbGljaXRl ZCByb3V0ZXIgDQo+ID4gPiA+ID4gICAgYWR2ZXJ0aXNlbWVudC4gV2l0aCBTIGJpdCwgYSBub2Rl IGNhbiBjb25maXJtIHJlYWNoYWJpbGl0eSB3aXRoIG9ubHkgDQo+ID4gPiA+ID4gICAgUlMvIFJB IGV4Y2hhbmdlLiINCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBBIG5ldyBiaXQgaXMgbm90IG5lZWRl ZCBoZXJlLiBJZiB0aGUgUkEgaXMgc2VudCB0byBhIHVuaWNhc3QgZGVzdGluYXRpb24gSVB2NiAN Cj4gPiA+ID4gPiBhZGRyZXNzIHRoYXQgaXMgbG9jYWwgdG8gdGhlIE1OLCB0aGF0IGlzIHN1ZmZp Y2llbnQuIEJ1dCwgdGhlIHJvdXRlciB3aWxsIA0KPiA+ID4gPiA+IHByb2JhYmx5IHNlbmQgdGhl IFJBIHRvIGEgbXVsdGljYXN0IGRlc3RpbmF0aW9uIGFkZHJlc3MgKHdoZW4gc29saWNpdGVkIGJ5 IFJTKSANCj4gPiA+ID4gPiBiZWNhdXNlIHRoYXQncyB3aGF0IFJGQy0yNDYxIHJlY29tbWVuZHMg dG8gZG8uDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gU2VjdGlvbiAzLjE6DQo+ID4gPiA+ID4gIiAg IFdlIHByb3Bvc2UgdG8gYXNzaWduIGEgbmV3IGJpdCAoQ29tcGxldGUgYml0KSBpbiBSQSBtZXNz YWdlIHRvIA0KPiA+ID4gPiA+ICAgIGluZGljYXRlIGl0cyBjb21wbGV0ZW5lc3MuIFdoZW4gQ29t cGxldGUgYml0IGlzIHNldCwgaXQgbWVhbnMgdGhlIFJBIA0KPiA+ID4gPiA+ICAgIGNvbnRhaW5z IGFsbCB0aGUgb3B0aW9ucyAoaW5jbHVkaW5nIGFsbCB0aGUgUHJlZml4IEluZm9ybWF0aW9uIA0K PiA+ID4gPiA+ICAgIE9wdGlvbnMpLiINCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBXZWxsLCB0aGlz IGRvZXNuJ3QgZml0IHRvbyB3ZWxsIHdpdGggZnJlcXVlbnQgUkEgYmVhY29ucyArIE1OIEVhZ2Vy IENlbGwgDQo+ID4gPiA+ID4gU3dpdGNoaW5nLiBJbiB0aGF0IGNhc2UsIHlvdSB3YW50IHRoZSBS QSB0byBiZSBhcyBzbWFsbCBhcyBwb3NzaWJsZSB3aGlsZSANCj4gPiA+ID4gPiBzdGlsbCBzdXBw b3J0aW5nIE1OIEVhZ2VyIENlbGwgU3dpdGNoaW5nLCBpLmUuIFItYml0IG9wdGlvbiBpcyBwcm9i YWJseSB0aGUgDQo+ID4gPiA+ID4gb25seSBvcHRpb24gbmVlZGVkIGluIHRoZSBSQSBiZWFjb24u IFNvLCBJIGRvIG5vdCBsaWtlIHRoaXMgcHJvcG9zYWwsIGJ1dCBJIGRvIA0KPiA+ID4gPiA+IGxp a2UgIjMuMiBSQSB3aXRoIExpbmsgSWRlbnRpZmllciBPcHRpb24iLiBbTGlua0lEXSBzZWVtcyBs aWtlIGEgdmVyeSBnb29kIA0KPiA+ID4gPiA+IHNvbHV0aW9uLg0KPiA+ID4gPiA+IA0KPiA+ID4g PiA+IFRoYW5rcy4NCj4gPiA+ID4gPiAtIEVkIFJlbW1lbGwNCj4gPiA+ID4gPiBFbG1pYyBTeXN0 ZW1zLCBVU0ENCj4gPiA+ID4gPiANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+IFRoaXMgRS1N YWlsIHdhcyBzZW50IHdpdGggTWFpbE1heC9XRUIuDQo+ID4gPiA+ID4gaHR0cDovL3d3dy5zbWFy dG1heC5jb20NCiANCg0KDQo+IHByb3Bvc2VkIExpbmsgSWRlbnRpZmllciBSQSBvcHRpb24gaXMg YW4gZXhjZWxsZW50IHNvbHV0aW9uLCBpZiB5b3UgbmVlZCB0byANCj4gdXNlIFJBcyBmb3IgbW92 ZW1lbnQgZGV0ZWN0aW9uIGJlY2F1c2UgeW91IGRvbid0IGhhdmUgcmVsaWFibGUgTDIgdHJpZ2dl cnMgdG8gDQo+IGdpdmUgeW91IHRoZSBzYW1lIGluZm9ybWF0aW9uLiBTb21lIGxpbmsgdHlwZXMg bGlrZSBXaUZpIHdpbGwgaGF2ZSByZWxpYWJsZSBMMiANCj4gdHJpZ2dlcnMgdGhhdCBjYW4gYmUg dXNlZCB0byBkZXRlY3QgYSBjaGFuZ2Ugb2YgbmV0d29yayAoRVNTSUQsIGZvciBXaUZpKS4gSW4g DQo+IHRoYXQgY2FzZSwgSU1ITyBpdCBpcyBwcmVmZXJhYmxlIHRvIHVzZSB0aGUgTDIgdHJpZ2dl cnMgYW5kIGxlYXZlIHRoZSBjdXJyZW50IA0KPiBub24tbW9iaWxpdHktYXdhcmUgUkEgYmVoYXZp b3IgdW5jaGFuZ2VkLiBCdXQsIHBlb3BsZSBkZXBsb3lpbmcgTW9iaWxlIElQdjYgDQo+IHdpbGwg ZG8gd2hhdGV2ZXIgdGhleSB3YW50Lg0KPiANCj4gPiA+IEknbSBub3QgZXhhY3RseSBzdXJlIHdo YXQgdGhlIHB1cnBvc2Ugb2Ygbm9uLW9uLWxpbmsgDQo+ID4gcHJlZml4ZXMgaXMsIGJ1dCANCj4g PiA+IEkgYWdyZWUsIGl0IGNlcnRhaW5seSBjb25mdXNlcyB0aGluZ3MuDQo+ID4gDQo+ID4gSU1P LCB0aGUgcHVycG9zZSBvZiBub24tb24tbGluayBwcmVmaXggaXMgdG8gY2hlY2sgdGhlIA0KPiA+ IHZhbGlkaXR5IG9mIElQIGFkZHJlc3MuIA0KPiA+IA0KPiA+IEl0IG1lYW5zIHRoYXQgYW4gYWR2 ZXJ0aXNpbmcgcm91dGVyIGluamVjdHMgdGhlIHJvdXRlIGZvciANCj4gPiB0aGF0IHByZWZpeCBp bnRvIEludGVybmV0LiANCj4gPiBBc3N1bWUgYSBub2RlIGhhcyBhbiBJUCBhZGRyZXNzIHdob3Nl IHByZWZpeCBpcyBhZHZlcnRpc2VkIGluIA0KPiA+IHRoYXQgbGluayBhcyANCj4gPiBub24tb24t bGluayBwcmVmaXguIChGb3IgY29udmVuaWVuY2UsIGxldCdzIGFzc3VtZSB0aGF0IA0KPiA+IGFk ZHJlc3MgaXMgZ2xvYmFsbHkgDQo+ID4gdW5pcXVlLikgVGhlbiBJbnRlcm5ldCByb3V0aW5nIG1l Y2hhbmlzbSB3aWxsIGZvcndhcmQgIHRvIA0KPiA+IHRoYXQgbm9kZSBhbnkgcGFja2V0IA0KPiA+ IGRlc3RpbmVkIGZvciB0aGF0IGFkZHJlc3MuICANCj4gDQo+IFllcywgdGhhdCdzIHRoZSBtZWNo YW5pY3Mgb2YgaXQuIEkgd2FzIHNheWluZyB0aGF0IEkgZGlkbid0IHVuZGVyc3RhbmQgd2h5IGl0 IA0KPiB3b3VsZCBuZWVkIHRvIGJlIHVzZWQuIEFjdHVhbGx5LCBJIGp1c3QgdGhvdWdodCBvZiBh IGdvb2Qgc2NlbmFyaW8gd2hlcmUgaXQgDQo+IG1ha2VzIHNlbnNlIHRvIHVzZSBhIG5vbi1vbi1s aW5rIHByZWZpeDogUFBQdjYuIElmIHRoZSBuZXR3b3JrIHNlbmRzIGEgUkEgDQo+IGNvbnRhaW5p bmcgcHJlZml4KGVzKSBmb3Igc3RhdGVsZXNzIGFkZHJlc3MgYXV0by1jb25maWd1cmF0aW9uIG92 ZXIgUFBQdjYgdG8gYSANCj4gaG9zdCwgaXQgY291bGQgYWxsb3cgdGhhdCBzYW1lIHByZWZpeCB0 byBiZSB1c2VkIGZvciBzdGF0ZWxlc3MgYWRkcmVzcyBhdXRvLQ0KPiBjb25maWd1cmF0aW9uIG9u IG90aGVyIFBQUHY2IGxpbmtzLCBiZWNhdXNlIHRoZSBuZXR3b3JrIGhhcyBjb250cm9sIG92ZXIg dGhlIA0KPiBhc3NpZ25tZW50IG9mIHRoZSBQUFB2NiBFVUktNjQgaW50ZXJmYWNlIElEcyBzaW5j ZSB0aGF0IGlzIGFuIG9wdGlvbiANCj4gbmVnb3RpYXRlZCBieSBQUFB2Ni4NCj4gIA0KPiA+IFAu Uy4gQ2FuIEkgc2VuZCBhIGNvcHkgb2YgdGhpcyB0byBJUHY2IFdHPyANCj4gU3VyZSwgbm8gbmVl ZCB0byBhc2sgbWUuIFlvdSBjYW4gc2VuZCB0aGUgd2hvbGUgdGhyZWFkIGlmIHlvdSdkIGxpa2Ug Oy0pDQo+IA0KPiBUaGFua3MuDQo+IC0gRWQNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBUaGlzIEUtTWFpbCB3YXMgc2VudCB3aXRoIE1haWxNYXgv V0VCLg0KPiBodHRwOi8vd3d3LnNtYXJ0bWF4LmNvbQ0KPg0KPiANCj4gDQo+IA0KPiA+IERlYXIg RWQNCj4gPiANCj4gPiBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIA0KPiA+IA0KPiA+ID4gSSBk aXNhZ3JlZS4gV2hhdCBkb2VzIHRoZSBNTiBsb3NlIGJ5IHBlcmZvcm1pbmcgYSBMMyBtb3ZlIGlu IHRoaXMgY2FzZT8NCj4gPiA+IE5vdCB2ZXJ5IG11Y2guIFRoZSBNTiBuZWVkcyB0byByZWNlaXZl IHRoZSBSQSBmaXJzdCBiZWZvcmUgZGV0ZWN0aW5nDQo+ID4gPiBtb3ZlbWVudCAoTDIgdHJpZ2dl cnMgYXJlIGZhc3RlciAtIFJBcyBjYW4gYmUgZGVsYXllZCkuIEkgaGF2ZSBzZWVuIG91cg0KPiA+ ID4gTU4gaW1wbGVtZW50YXRpb24gcmVnaXN0ZXIgYSBuZXcgY2FyZS1vZiBhZGRyZXNzIHdpdGgg dGhlIEhBIGluIGxlc3MNCj4gPiA+IHRoYW4gMSBtaWxsaXNlY29uZCAodGhhdCB3YXMgd2l0aG91 dCBJUHNlYykuIFNvLCB0aGUgTU4gZHJvcHMgdGhlIENvQQ0KPiA+IA0KPiA+IFRoYSdzIGltcHJl c3NpdmUuIEJ1dCBob3cgYWJvdXQgREFEPyAgDQo+ID4gDQo+ID4gPiB3aXRoIHByZWZpeCBBOiwg ZG9lcyBhIEwzIG1vdmUgYmVjYXVzZSB0aGUgbGluayBpZGVudGlmaWVyIGNoYW5nZWQsIGFuZA0K PiA+ID4gdGhlbiByZWRpc2NvdmVycyBwcmVmaXggQTogYW5kIGF1dG8tY29uZmlndXJlcyB0aGUg c2FtZSBDb0EgYWdhaW4gYW5kDQo+ID4gPiByZXJlZ2lzdGVycyBpdCB3aXRoIHRoZSBIQS4uLiB0 aGF0IGlzbid0IGEgYmlnIHByb2JsZW0sIGFzIGZhciBhcyBJJ20NCj4gPiA+IGNvbmNlcm5lZC4g SW4gZmFjdCwgYWxsIG9mIHRoZSBleHRyYSBwcm90b2NvbCBvdmVyaGVhZCBpbnZvbHZlZCBpbg0K PiA+IA0KPiA+IFRoaXMgaXMgdGhlIG1lc3N5IHNjZW5hcmlvIEkgYW0gd29ycmllZCBvZi4gDQo+ ID4gDQo+ID4gMSkgQW4gTU4gaXMgaW4gQ2VsbCAxLCBoYXZpbmcgYSBDb0Egd2l0aCBQcmVmaXgg QTo6IA0KPiA+IDIpIFRoZSBNTiBtb3ZlcyB0byBDZWxsIDIgYW5kIHJlY2VpdmVzIGEgUkEgd2l0 aCBMaW5rSUQgYW5kIG9ubHkgUHJlZml4IEI6Oi4NCj4gPiAzKSBNTiBhc3N1bWVzIGl0IGhhcyBt b3ZlZCBhbmQgZm9ybXMgYSBuZXcgQ29BIHdpdGggUHJlZml4IEI6Oi4NCj4gPiA0KSBNTiBzZW5k cyBCVSB3aXRoIHRoZSBDb0Egd2l0aCBQcmVmaXggQjo6LCBzbyB1bm5lY2Vzc2FyeSBCVSBoYXBw ZW5zLg0KPiA+IA0KPiA+ID4gSSdtIG5vdCBleGFjdGx5IHN1cmUgd2hhdCB0aGUgcHVycG9zZSBv ZiBub24tb24tbGluayBwcmVmaXhlcyBpcywgYnV0IEkNCj4gPiA+IGFncmVlLCBpdCBjZXJ0YWlu bHkgY29uZnVzZXMgdGhpbmdzLiANCj4gPiANCj4gPiBJTU8sIHRoZSBwdXJwb3NlIG9mIG5vbi1v bi1saW5rIHByZWZpeCBpcyB0byBjaGVjayB0aGUgdmFsaWRpdHkgb2YgSVAgYWRkcmVzcy4gDQo+ ID4gDQo+ID4gSXQgbWVhbnMgdGhhdCBhbiBhZHZlcnRpc2luZyByb3V0ZXIgaW5qZWN0cyB0aGUg cm91dGUgZm9yIHRoYXQgcHJlZml4IGludG8gSW50ZXJuZXQuIA0KPiA+IEFzc3VtZSBhIG5vZGUg aGFzIGFuIElQIGFkZHJlc3Mgd2hvc2UgcHJlZml4IGlzIGFkdmVydGlzZWQgaW4gdGhhdCBsaW5r IGFzIA0KPiA+IG5vbi1vbi1saW5rIHByZWZpeC4gKEZvciBjb252ZW5pZW5jZSwgbGV0J3MgYXNz dW1lIHRoYXQgYWRkcmVzcyBpcyBnbG9iYWxseSANCj4gPiB1bmlxdWUuKSBUaGVuIEludGVybmV0 IHJvdXRpbmcgbWVjaGFuaXNtIHdpbGwgZm9yd2FyZCAgdG8gdGhhdCBub2RlIGFueSBwYWNrZXQg DQo+ID4gZGVzdGluZWQgZm9yIHRoYXQgYWRkcmVzcy4gIA0KPiA+IA0KPiA+IEkgd2lzaCB0aGUg YWJvdmUgaGVscHMuIEJ1dCB3ZSdkIGJldHRlciBjaGVjayB3aXRoIHRoZSBhdXRob3JzLiBFcmlr IG9yIFRob21hcy4gIA0KPiA+IA0KPiA+ID4gQnV0IGluIHRoaXMgY2FzZSwgSSB3b3VsZCBqdXN0 DQo+ID4gPiBpZ25vcmUgdGhpcyBwYXRob2xvZ2ljYWwgc2NlbmFyaW8uDQo+ID4gDQo+ID4gVGhp cyBtYXkgYmUgcHJhY3RpY2FsLiBCdXQgbXkgcG9pbnQgaXMgdGhhdCBpdCBpcyB3b3J0aHdoaWxl IHRvIGludmVzdGlnYXRlIHRoZSANCj4gPiBtZXRob2Qgb2YgYWRkaW5nIG9uZSBhZGRpdGlvbmFs IGJpdCB0byBmYWNpbGl0YXRlIGVmZmljaWVudCBNRC4gDQo+ID4gDQo+ID4gQXMgYmVmb3JlLCBp dCdzIGlsbHVtaW5hdGluZyB0byBleGNoYW5nZSBvcGluaW9ucyB3aXRoIHlvdS4gSSB3aXNoIHdl IHdpbGwgaGF2ZSANCj4gPiBhIGZhY2UgdG8gZmFjZSBkaXNjdXNzaW9uIGF0IE1pbm5lYXBvbGlz LiAgIA0KPiA+IA0KPiA+IEJlc3QgcmVnYXJkcw0KPiA+IA0KPiA+IEppbkh5ZW9jaw0KPiA+IA0K PiA+IFAuUy4gQ2FuIEkgc2VuZCBhIGNvcHkgb2YgdGhpcyB0byBJUHY2IFdHPyANCj4gPiANCj4g Pg0KPiA+IA0KPiA+IA0KPiA+ID4gPiBJIGFtIGFmcmFpZCB0aGF0IHRoZXJlIGlzIHNvbWUgcGF0 aG9sb2dpY2FsIGNhc2UgaW4gd2hpY2ggDQo+ID4gPiA+IGxpbmsgaWRlbnRpZmllciBpcyANCj4g PiA+ID4gbm90IHN1ZmZpY2llbnQuIEhlcmUgaXMgYW4gZXhhbXBsZS4gS2luZGx5IGZpbmQgYW4g YXR0YWNoZWQgDQo+ID4gPiA+IGZpbGUuIEl0J3MgZGlmZmljdWx0IHRvIGRyYXcgYSBmaWd1cmUg aW4gdGV4dCBmaWxlLiANCj4gPiA+ID4gDQo+ID4gPiA+IEluIHRoZSBmaWd1cmUsIGFuIHJvdXRl ciBoYXMgdHdvIGludGVyZmFjZXMsIGludGVyZmFjZSAxIGFuZCANCj4gPiA+ID4gaW50ZXJmYWNl IDIuIFRvIGVhY2ggDQo+ID4gPiA+IGludGVyZmFjZSwgYW4gQVAgKGhlbmNlIGEgY2VsbCkgaXMg YXR0YWNoZWQuIEludGVyZmFjZSAxIA0KPiA+ID4gPiBhZHZlcnRpc2VzIHRoZSBwcmVmaXggQTo6 IA0KPiA+ID4gPiBhbmQgaW50ZXJmYWNlIDIgYWR2ZXJ0aXNlcyBQcmVmaXggQTo6YW5kIEI6Oi4g DQo+ID4gPiA+IA0KPiA+ID4gPiBDZWxsIDEgYW5kIENlbGwgMiBjYW4ndCBoYXZlIHRoZSBzYW1l IGxpbmsgaWRlbnRpZmllci4gSWYgTU4gDQo+ID4gPiA+IG1vdmVzIGZyb20gQ2VsbCAxIHRvIA0K PiA+ID4gPiBDZWxsIDIsIGl0IGNhbiBrZWVwIHVzaW5nIGl0cyBjdXJyZW50IENvQSB3aXRoIFBy ZWZpeCBBOjouIA0KPiA+ID4gPiBCdXQgaWYgTU4gaGF2aW5nIENvQSB3aXRoIA0KPiA+ID4gPiBQ cmVmaXggQjo6IG1vdmVzIGZyb20gQ2VsbCAyIHRvIENlbGwgMSwgaXQgY2FuJ3QgdXNlIGl0cyBD b0EgYW55bW9yZS4gDQo+ID4gPiA+IA0KPiA+ID4gPiBTbyBNTiBjYW4ndCBjaGVjayB0aGUgdmFs aWRpdHkgb2YgaXRzIGN1cnJlbnQgQ29BIHdpdGggTGluayANCj4gPiA+ID4gSWRlbnRpZmllciBv bmx5LiANCj4gPiA+ID4gDQo+ID4gPiANCj4gPiA+IEppbkh5ZW9jayAtDQo+ID4gPiANCj4gPiA+ IEkgZGlzYWdyZWUuIFdoYXQgZG9lcyB0aGUgTU4gbG9zZSBieSBwZXJmb3JtaW5nIGEgTDMgbW92 ZSBpbiB0aGlzIGNhc2U/DQo+ID4gPiBOb3QgdmVyeSBtdWNoLiBUaGUgTU4gbmVlZHMgdG8gcmVj ZWl2ZSB0aGUgUkEgZmlyc3QgYmVmb3JlIGRldGVjdGluZw0KPiA+ID4gbW92ZW1lbnQgKEwyIHRy aWdnZXJzIGFyZSBmYXN0ZXIgLSBSQXMgY2FuIGJlIGRlbGF5ZWQpLiBJIGhhdmUgc2VlbiBvdXIN Cj4gPiA+IE1OIGltcGxlbWVudGF0aW9uIHJlZ2lzdGVyIGEgbmV3IGNhcmUtb2YgYWRkcmVzcyB3 aXRoIHRoZSBIQSBpbiBsZXNzDQo+ID4gPiB0aGFuIDEgbWlsbGlzZWNvbmQgKHRoYXQgd2FzIHdp dGhvdXQgSVBzZWMpLiBTbywgdGhlIE1OIGRyb3BzIHRoZSBDb0ENCj4gPiA+IHdpdGggcHJlZml4 IEE6LCBkb2VzIGEgTDMgbW92ZSBiZWNhdXNlIHRoZSBsaW5rIGlkZW50aWZpZXIgY2hhbmdlZCwg YW5kDQo+ID4gPiB0aGVuIHJlZGlzY292ZXJzIHByZWZpeCBBOiBhbmQgYXV0by1jb25maWd1cmVz IHRoZSBzYW1lIENvQSBhZ2FpbiBhbmQNCj4gPiA+IHJlcmVnaXN0ZXJzIGl0IHdpdGggdGhlIEhB Li4uIHRoYXQgaXNuJ3QgYSBiaWcgcHJvYmxlbSwgYXMgZmFyIGFzIEknbQ0KPiA+ID4gY29uY2Vy bmVkLiBJbiBmYWN0LCBhbGwgb2YgdGhlIGV4dHJhIHByb3RvY29sIG92ZXJoZWFkIGludm9sdmVk IGluDQo+ID4gPiByZXJlZ2lzdGVyaW5nIHRoZSBzYW1lIENvQSB0aHJvdWdoIHRoZSBuZXcgcm91 dGVyIGlzIG5lZWRlZCB0byB0ZWxsIHRoZQ0KPiA+ID4gbmV0d29yayB0aGF0IHRoYXQgQ29BIGlz IG5vdyByZWFjaGFibGUgdGhyb3VnaCB0aGUgbmV3IHJvdXRlciwgbm90IHRoZQ0KPiA+ID4gb2xk IHJvdXRlci4NCj4gPiA+IA0KPiA+ID4gSSdtIG5vdCBleGFjdGx5IHN1cmUgd2hhdCB0aGUgcHVy cG9zZSBvZiBub24tb24tbGluayBwcmVmaXhlcyBpcywgYnV0IEkNCj4gPiA+IGFncmVlLCBpdCBj ZXJ0YWlubHkgY29uZnVzZXMgdGhpbmdzLiBCdXQgaW4gdGhpcyBjYXNlLCBJIHdvdWxkIGp1c3QN Cj4gPiA+IGlnbm9yZSB0aGlzIHBhdGhvbG9naWNhbCBzY2VuYXJpby4NCj4gPiA+IA0KPiA+ID4g VGhhbmtzLg0KPiA+ID4gLSBFZA0KPiA+ID4gDQo+ID4gPiAtLS0NCj4gPiA+IE91dGdvaW5nIG1h aWwgaXMgY2VydGlmaWVkIFZpcnVzIEZyZWUuDQo+ID4gPiBDaGVja2VkIGJ5IEFWRyBhbnRpLXZp cnVzIHN5c3RlbSAoaHR0cDovL3d3dy5ncmlzb2Z0LmNvbSkuDQo+ID4gPiBWZXJzaW9uOiA2LjAu NTIyIC8gVmlydXMgRGF0YWJhc2U6IDMyMCAtIFJlbGVhc2UgRGF0ZTogOS8yOS8yMDAzDQo+ID4g PiAgDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiA+IERlYXIgRWQNCj4gPiA+ID4gDQo+ ID4gPiA+IFRoYW5rcyBmb3IgcHJvbXB0IGFuZCBoZWxwZnVsIHJlcGx5LiANCj4gPiA+ID4gDQo+ ID4gPiA+IEluIHRoaXMgZHJhZnQsIHdlIHRyeSB0byBmb2N1cyBvbiBwcm9ibGVtcyBhbmQgcHJl c2VudCBvbmx5IHRoZSBza2V0Y2ggb2YgDQo+ID4gPiA+IHNvbHV0aW9ucy4gV2Ugd2lsbCBwcmVz ZW50IG1vcmUgZGV0YWlsZWQgc29sdXRpb24gbGF0ZXIuIA0KPiA+ID4gPiANCj4gPiA+ID4gPiBB Y3R1YWxseSwgdGhlIGxpbmsgaWRlbnRpZmllciBvcHRpb24gZHJhZnQgd291bGQgcmVzb2x2ZSB0 aGlzIGlzc3VlLCBhbHNvLiBUaGUgDQo+ID4gPiA+ID4gTU4gdXNlcyB0aGUgUkEgdG8gZGV0ZWN0 IG1vdmVtZW50IChhc3N1bWluZyBMMiB0cmlnZ2VycyBhcmUgbm90IGF2YWlsYWJsZSkuIEEgDQo+ ID4gPiA+ID4gY2hhbmdlIGluIGxpbmsgaWRlbnRpZmllciBpbiB0aGUgUkEgaXMgZW5vdWdoIG9m IGFuIGluZGljYXRpb24gdGhhdCBtb3ZlbWVudCANCj4gPiA+ID4gPiBoYXMgb2NjdXJyZWQuDQo+ ID4gPiA+IA0KPiA+ID4gPiBJIGFtIGFmcmFpZCB0aGF0IHRoZXJlIGlzIHNvbWUgcGF0aG9sb2dp Y2FsIGNhc2UgaW4gd2hpY2ggbGluayBpZGVudGlmaWVyIGlzIA0KPiA+ID4gPiBub3Qgc3VmZmlj aWVudC4gSGVyZSBpcyBhbiBleGFtcGxlLiBLaW5kbHkgZmluZCBhbiBhdHRhY2hlZCBmaWxlLiBJ dCdzIGRpZmZpY3VsdA0KPiA+ID4gPiB0byBkcmF3IGEgZmlndXJlIGluIHRleHQgZmlsZS4gDQo+ ID4gPiA+IA0KPiA+ID4gPiBJbiB0aGUgZmlndXJlLCBhbiByb3V0ZXIgaGFzIHR3byBpbnRlcmZh Y2VzLCBpbnRlcmZhY2UgMSBhbmQgaW50ZXJmYWNlIDIuIFRvIGVhY2ggDQo+ID4gPiA+IGludGVy ZmFjZSwgYW4gQVAgKGhlbmNlIGEgY2VsbCkgaXMgYXR0YWNoZWQuIEludGVyZmFjZSAxIGFkdmVy dGlzZXMgdGhlIHByZWZpeCBBOjogDQo+ID4gPiA+IGFuZCBpbnRlcmZhY2UgMiBhZHZlcnRpc2Vz IFByZWZpeCBBOjphbmQgQjo6LiANCj4gPiA+ID4gDQo+ID4gPiA+IENlbGwgMSBhbmQgQ2VsbCAy IGNhbid0IGhhdmUgdGhlIHNhbWUgbGluayBpZGVudGlmaWVyLiBJZiBNTiBtb3ZlcyBmcm9tIENl bGwgMSB0byANCj4gPiA+ID4gQ2VsbCAyLCBpdCBjYW4ga2VlcCB1c2luZyBpdHMgY3VycmVudCBD b0Egd2l0aCBQcmVmaXggQTo6LiBCdXQgaWYgTU4gaGF2aW5nIENvQSB3aXRoIA0KPiA+ID4gPiBQ cmVmaXggQjo6IG1vdmVzIGZyb20gQ2VsbCAyIHRvIENlbGwgMSwgaXQgY2FuJ3QgdXNlIGl0cyBD b0EgYW55bW9yZS4gDQo+ID4gPiA+IA0KPiA+ID4gPiBTbyBNTiBjYW4ndCBjaGVjayB0aGUgdmFs aWRpdHkgb2YgaXRzIGN1cnJlbnQgQ29BIHdpdGggTGluayBJZGVudGlmaWVyIG9ubHkuIA0KPiA+ ID4gPiANCj4gPiA+ID4gTXVsdGlwbGUgcm91dGVycyBvbiBtdWx0aXBsZSBsaW5rcyB3aXRoIG11 bHRpcGxlIHByZWZpeGVzIG1ha2UgTUQgdmVyeSBjb21wbGV4LiANCj4gPiA+ID4gSSB0aGluayB3 ZSdkIGJldHRlciBoYXZlIG1vcmUgY2xlYXIgdW5kZXJzdGFuZGluZy4gTWF5YmUgYXQgRE5BLiBJ IHdpc2ggeW91IA0KPiA+ID4gPiBwYXJ0aWNpcGF0ZSBhdCAmIGNvbnRyaWJ1dGUgdG8gRE5BIG1l ZXRpbmcgYXQgTWlubmVhcG9saXMuICAgIA0KPiA+ID4gPiAgDQo+ID4gPiA+ID4gSSBsb29rZWQg YXQgeW91ciBkcmFmdCwgaXQgaXMgYSB2ZXJ5IGNsZWFyIGFuZCBhY2N1cmF0ZSBkZXNjcmlwdGlv biBvZiB0aGUgDQo+ID4gPiA+ID4gY3VycmVudCBpc3N1ZXMgd2l0aCBSQXMgdy8gcmVnYXJkcyB0 byB1c2luZyB0aGVtIGZvciBtb3ZlbWVudCBkZXRlY3Rpb24uDQo+ID4gPiA+ID4NCj4gPiA+ID4g PiBTZWN0aW9uIDIuMzoNCj4gPiA+ID4gPiAiICAgSXQgbWF5IHVzZWZ1bCB0byBhc3NpZ24gUyBi aXQsIGluIHRoZSBjYXNlIHdoZXJlIHdlIHdhbnQgbm9kZXMgdG8gYmUgDQo+ID4gPiA+ID4gICAg YWJsZSB0byBkZXRlcm1pbmUgdGhhdCB0aGV5IGhhdmUgcmVjZWl2ZWQgYSBzb2xpY2l0ZWQgcm91 dGVyIA0KPiA+ID4gPiA+ICAgIGFkdmVydGlzZW1lbnQuIFdpdGggUyBiaXQsIGEgbm9kZSBjYW4g Y29uZmlybSByZWFjaGFiaWxpdHkgd2l0aCBvbmx5IA0KPiA+ID4gPiA+ICAgIFJTLyBSQSBleGNo YW5nZS4iDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gQSBuZXcgYml0IGlzIG5vdCBuZWVkZWQgaGVy ZS4gSWYgdGhlIFJBIGlzIHNlbnQgdG8gYSB1bmljYXN0IGRlc3RpbmF0aW9uIElQdjYgDQo+ID4g PiA+ID4gYWRkcmVzcyB0aGF0IGlzIGxvY2FsIHRvIHRoZSBNTiwgdGhhdCBpcyBzdWZmaWNpZW50 LiBCdXQsIHRoZSByb3V0ZXIgd2lsbCANCj4gPiA+ID4gDQo+ID4gPiA+IEkgYWdyZWUgd2l0aCB5 b3UuIEJ1dCBjYW4gd2UgdXNlIGl0IHRvIGNvbmZpcm0gYmktZGlyZWN0aW9uYWwgcmVhY2hhYmls aXR5PyBJIGhvcGUgDQo+ID4gPiA+IFdHIHdpbGwgZGVjaWRlIHNvLiAgIA0KPiA+ID4gPiANCj4g PiA+ID4gPiBwcm9iYWJseSBzZW5kIHRoZSBSQSB0byBhIG11bHRpY2FzdCBkZXN0aW5hdGlvbiBh ZGRyZXNzICh3aGVuIHNvbGljaXRlZCBieSBSUykgDQo+ID4gPiA+ID4gYmVjYXVzZSB0aGF0J3Mg d2hhdCBSRkMtMjQ2MSByZWNvbW1lbmRzIHRvIGRvLg0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IFNl Y3Rpb24gMy4xOg0KPiA+ID4gPiA+ICIgICBXZSBwcm9wb3NlIHRvIGFzc2lnbiBhIG5ldyBiaXQg KENvbXBsZXRlIGJpdCkgaW4gUkEgbWVzc2FnZSB0byANCj4gPiA+ID4gPiAgICBpbmRpY2F0ZSBp dHMgY29tcGxldGVuZXNzLiBXaGVuIENvbXBsZXRlIGJpdCBpcyBzZXQsIGl0IG1lYW5zIHRoZSBS QSANCj4gPiA+ID4gPiAgICBjb250YWlucyBhbGwgdGhlIG9wdGlvbnMgKGluY2x1ZGluZyBhbGwg dGhlIFByZWZpeCBJbmZvcm1hdGlvbiANCj4gPiA+ID4gPiAgICBPcHRpb25zKS4iDQo+ID4gPiA+ ID4gDQo+ID4gPiA+ID4gV2VsbCwgdGhpcyBkb2Vzbid0IGZpdCB0b28gd2VsbCB3aXRoIGZyZXF1 ZW50IFJBIGJlYWNvbnMgKyBNTiBFYWdlciBDZWxsIA0KPiA+ID4gPiA+IFN3aXRjaGluZy4gSW4g dGhhdCBjYXNlLCB5b3Ugd2FudCB0aGUgUkEgdG8gYmUgYXMgc21hbGwgYXMgcG9zc2libGUgd2hp bGUgDQo+ID4gPiA+ID4gc3RpbGwgc3VwcG9ydGluZyBNTiBFYWdlciBDZWxsIFN3aXRjaGluZywg aS5lLiBSLWJpdCBvcHRpb24gaXMgcHJvYmFibHkgdGhlIA0KPiA+ID4gPiANCj4gPiA+ID4gSSBh Z3JlZSB0aGF0IGl0J3Mgbm90IGEgZ29vZCBpZGVhIHRvIHNlbmQgQ29tcGxldGUgUkEgY29uc3Rh bnRseS4gSXQgbWF5IHRha2UgDQo+ID4gPiA+IHRvbyBtdWNoIGJhbmR3aWR0aC4gSSB0aGluayB3 ZSdkIGJldHRlciBzZW5kIENvbXBsZXRlIFJBIG9ubHkgd2hlbiBpdCdzIA0KPiA+ID4gPiBiZW5l ZmljaWFsLCBmb3IgZXhhbXBsZSB3aGVuIGEgUlMgaXMgcmVjZWl2ZWQuIA0KPiA+ID4gPiANCj4g PiA+ID4gVGhhbmtzIGZvciB5b3VyIGtpbmQgd29yZHMuIA0KPiA+ID4gPiAgDQo+ID4gPiA+IFdv dWxkIHlvdSBwdXQgeW91ciBjb21tZW50cyBpbiBJUHY2IG1haWxpbmcgbGlzdCBhbmQgYnJpbmcg dGhpcyBkaXNjdXNzaW9uIG91dCwgDQo+ID4gPiA+IHNvIHRoYXQgb3RoZXIgcGVvcGxlIG1heSBi ZSBpbmZvbWVkIGFuZCBqb2luIGl0PyANCj4gPiA+ID4gDQo+ID4gPiA+IFdlIHJlcXVlc3RlZCBj aGFpcnMgZm9yIHRpbWUgc2xvdCBhdCBNaW5uZWFwb2xpcyBhbmQgaXQnbGwgaGVscCB1cyBpZiB0 aGVyZSBpcyBhIA0KPiA+ID4gPiB0aHJlYWQgYWJvdXQgaXQuIFdlIGhhZCBhc2tlZCBhdCBTRiBi dXQgZGVuaWVkIGZvciB0aGUgbGFjayBvZiBpbnRlcmVzdHMuIDotKA0KPiA+ID4gPiAgDQo+ID4g PiA+IFRoYW5rcyBmb3IgeW91ciBraW5kIHdvcmRzIGFuZCBzZWUgeW91IGF0IE1pbm5lYXBvbGlz LiANCj4gPiA+ID4gDQo+ID4gPiA+IEJlc3QgcmVnYXJkcw0KPiA+ID4gPiANCj4gPiA+ID4gSmlu SHllb2NrIENob2kNCj4gPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gDQo+ID4g PiA+ID4gSmluSHllb2NrICYgR3JlZyAtDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gQWN0dWFsbHks IHRoZSBsaW5rIGlkZW50aWZpZXIgb3B0aW9uIGRyYWZ0IHdvdWxkIHJlc29sdmUgdGhpcyBpc3N1 ZSwgYWxzby4gVGhlIA0KPiA+ID4gPiA+IE1OIHVzZXMgdGhlIFJBIHRvIGRldGVjdCBtb3ZlbWVu dCAoYXNzdW1pbmcgTDIgdHJpZ2dlcnMgYXJlIG5vdCBhdmFpbGFibGUpLiBBIA0KPiA+ID4gPiA+ IGNoYW5nZSBpbiBsaW5rIGlkZW50aWZpZXIgaW4gdGhlIFJBIGlzIGVub3VnaCBvZiBhbiBpbmRp Y2F0aW9uIHRoYXQgbW92ZW1lbnQgDQo+ID4gPiA+ID4gaGFzIG9jY3VycmVkLg0KPiA+ID4gPiA+ IA0KPiA+ID4gPiA+IEkgbG9va2VkIGF0IHlvdXIgZHJhZnQsIGl0IGlzIGEgdmVyeSBjbGVhciBh bmQgYWNjdXJhdGUgZGVzY3JpcHRpb24gb2YgdGhlIA0KPiA+ID4gPiA+IGN1cnJlbnQgaXNzdWVz IHdpdGggUkFzIHcvIHJlZ2FyZHMgdG8gdXNpbmcgdGhlbSBmb3IgbW92ZW1lbnQgZGV0ZWN0aW9u Lg0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IFNlY3Rpb24gMi4zOg0KPiA+ID4gPiA+ICIgICBJdCBt YXkgdXNlZnVsIHRvIGFzc2lnbiBTIGJpdCwgaW4gdGhlIGNhc2Ugd2hlcmUgd2Ugd2FudCBub2Rl cyB0byBiZSANCj4gPiA+ID4gPiAgICBhYmxlIHRvIGRldGVybWluZSB0aGF0IHRoZXkgaGF2ZSBy ZWNlaXZlZCBhIHNvbGljaXRlZCByb3V0ZXIgDQo+ID4gPiA+ID4gICAgYWR2ZXJ0aXNlbWVudC4g V2l0aCBTIGJpdCwgYSBub2RlIGNhbiBjb25maXJtIHJlYWNoYWJpbGl0eSB3aXRoIG9ubHkgDQo+ ID4gPiA+ID4gICAgUlMvIFJBIGV4Y2hhbmdlLiINCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBBIG5l dyBiaXQgaXMgbm90IG5lZWRlZCBoZXJlLiBJZiB0aGUgUkEgaXMgc2VudCB0byBhIHVuaWNhc3Qg ZGVzdGluYXRpb24gSVB2NiANCj4gPiA+ID4gPiBhZGRyZXNzIHRoYXQgaXMgbG9jYWwgdG8gdGhl IE1OLCB0aGF0IGlzIHN1ZmZpY2llbnQuIEJ1dCwgdGhlIHJvdXRlciB3aWxsIA0KPiA+ID4gPiA+ IHByb2JhYmx5IHNlbmQgdGhlIFJBIHRvIGEgbXVsdGljYXN0IGRlc3RpbmF0aW9uIGFkZHJlc3Mg KHdoZW4gc29saWNpdGVkIGJ5IFJTKSANCj4gPiA+ID4gPiBiZWNhdXNlIHRoYXQncyB3aGF0IFJG Qy0yNDYxIHJlY29tbWVuZHMgdG8gZG8uDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gU2VjdGlvbiAz LjE6DQo+ID4gPiA+ID4gIiAgIFdlIHByb3Bvc2UgdG8gYXNzaWduIGEgbmV3IGJpdCAoQ29tcGxl dGUgYml0KSBpbiBSQSBtZXNzYWdlIHRvIA0KPiA+ID4gPiA+ICAgIGluZGljYXRlIGl0cyBjb21w bGV0ZW5lc3MuIFdoZW4gQ29tcGxldGUgYml0IGlzIHNldCwgaXQgbWVhbnMgdGhlIFJBIA0KPiA+ ID4gPiA+ICAgIGNvbnRhaW5zIGFsbCB0aGUgb3B0aW9ucyAoaW5jbHVkaW5nIGFsbCB0aGUgUHJl Zml4IEluZm9ybWF0aW9uIA0KPiA+ID4gPiA+ICAgIE9wdGlvbnMpLiINCj4gPiA+ID4gPiANCj4g PiA+ID4gPiBXZWxsLCB0aGlzIGRvZXNuJ3QgZml0IHRvbyB3ZWxsIHdpdGggZnJlcXVlbnQgUkEg YmVhY29ucyArIE1OIEVhZ2VyIENlbGwgDQo+ID4gPiA+ID4gU3dpdGNoaW5nLiBJbiB0aGF0IGNh c2UsIHlvdSB3YW50IHRoZSBSQSB0byBiZSBhcyBzbWFsbCBhcyBwb3NzaWJsZSB3aGlsZSANCj4g PiA+ID4gPiBzdGlsbCBzdXBwb3J0aW5nIE1OIEVhZ2VyIENlbGwgU3dpdGNoaW5nLCBpLmUuIFIt Yml0IG9wdGlvbiBpcyBwcm9iYWJseSB0aGUgDQo+ID4gPiA+ID4gb25seSBvcHRpb24gbmVlZGVk IGluIHRoZSBSQSBiZWFjb24uIFNvLCBJIGRvIG5vdCBsaWtlIHRoaXMgcHJvcG9zYWwsIGJ1dCBJ IGRvIA0KPiA+ID4gPiA+IGxpa2UgIjMuMiBSQSB3aXRoIExpbmsgSWRlbnRpZmllciBPcHRpb24i LiBbTGlua0lEXSBzZWVtcyBsaWtlIGEgdmVyeSBnb29kIA0KPiA+ID4gPiA+IHNvbHV0aW9uLg0K PiA+ID4gPiA+IA0KPiA+ID4gPiA+IFRoYW5rcy4NCj4gPiA+ID4gPiAtIEVkIFJlbW1lbGwNCj4g PiA+ID4gPiBFbG1pYyBTeXN0ZW1zLCBVU0ENCj4gPiA+ID4gPiANCj4gPiA+ID4gPiANCj4gPiA+ ID4gPiANCj4gPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+ID4gPiA+IFRoaXMgRS1NYWlsIHdhcyBzZW50IHdpdGggTWFpbE1heC9XRUIuDQo+ID4gPiA+ ID4gaHR0cDovL3d3dy5zbWFydG1heA== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 16 23:32:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04485 for ; Thu, 16 Oct 2003 23:32:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AALLo-0002Fo-MD for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 23:32:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9H3WSVU008663 for ipv6-archive@odin.ietf.org; Thu, 16 Oct 2003 23:32:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AALLo-0002F1-8Y for ipv6-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 23:32:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04460 for ; Thu, 16 Oct 2003 23:32:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AALLm-0005qE-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 23:32:26 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AALLl-0005qB-00 for ipv6-web-archive@ietf.org; Thu, 16 Oct 2003 23:32:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AALJU-0001xn-7W; Thu, 16 Oct 2003 23:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AALJ7-0001xG-4i for ipv6@optimus.ietf.org; Thu, 16 Oct 2003 23:29:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04375 for ; Thu, 16 Oct 2003 23:29:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AALJ4-0005nw-00 for ipv6@ietf.org; Thu, 16 Oct 2003 23:29:38 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AALJ3-0005n6-00 for ipv6@ietf.org; Thu, 16 Oct 2003 23:29:38 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h9H3SxO8020734; Thu, 16 Oct 2003 22:29:00 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Thu, 16 Oct 2003 22:28:16 -0500 Received: from [142.133.72.18] (142.133.72.18 [142.133.72.18]) by eammlex033.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 43LM1BRH; Thu, 16 Oct 2003 23:31:54 -0400 Date: Thu, 16 Oct 2003 23:27:18 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: suresh.krishnan@ericsson.ca To: Bob Hinden , , Steve Deering Subject: Re: I-D ACTION:draft-ietf-ipv6-addr-arch-v4-00.txt In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF830BD627B7@eammlex037.lmc.ericsson.se> Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830CCE42C5-100000@eammlex037.lmc.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi Folks, I have some comments regarding this draft. * The draft does not mention that it is RFC 2119 compliant and it is not. Hence it is impossible to figure out if something is mandatory or not. For example in section 2.7.1 page 17 "A node is required to compute and join...". What is the compliance level for this requirement. MUST/SHOULD or MAY? * There is no definition of scope. Types of addresses like unicasr/anycast/multicast are defined but global/local(link/interface) scope are not defined. * section 2.1 paragraph 2 third sentence "Unicast addresses with scope greater than link-scope are not needed for interfaces that are not used as the origin or destination of any IPv6 packets to or from non-neighbors." Sentence is too complex (double negative). Can be something like "Unicast addresses with scope greater than link-scope are needed only for interfaces that are used to communicate with non-neighbors." * section 2.2 point number 1 The IP address used as an example is a site-local address (FEDC:...). Since this range may never be used it might be changed to something non-controversial * section 2.2 point number 2 typo for unspecified address (it says unspecified addresses) * section 2.4 address type table Section number for global unicast(2.5.4) is missing in table * section 2.5 second address format Since the interface ID will be 64 bits in most cases it may make sense to split the address picture more evenly * section 2.5.1 paragraph 6 last sentence The simpler alternative would be 1,2,etc. should be The simpler alternative would be 0:0:0:1,0:0:0:2,etc. * section 2.5.3 third sentence It reads "It may never be assigned to any physical interface". Shouldn't this be "It MUST never be assigned to any physical interface"? * section 2.5.4 last paragraph It mentions that the global routing prefix is assigned to a "site" which is fuzzy. Is it possible to make it clearer? Similarly I would think of a link to be some layer2 connection not necessarily comprising a subnet. * section 2.7 Shouldn't the site local scope for multicast be removed in the multicast address format? "NTP servers in site" example should be removed. The paragraph following the examples also need to be removed Typo. The last three paragraphs have scope misspelt as scop. * section 2.7.1 The list of 16 reserved addresses with group id set to 0:0:0:0:0:0:0 can be replaced with a sentence which goes something like "All permanently assigned multicast addresses with group id 0:0:0:0:0:0:0 are reserved." All routers in site example should be removed. * appendix A Instead of explaining this procedure for 48 bit MACs isn't it better to put in a reference to RFC 2464 * appendix A section "Links with other kinds of identifiers" line 2 Typo. EIU should be EUI That's about it. Cheers Suresh On Fri, 10 Oct 2003 Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. > > Title : IP Version 6 Addressing Architecture > Author(s) : R. Hinden, S. Deering > Filename : draft-ietf-ipv6-addr-arch-v4-00.txt > Pages : 25 > Date : 2003-10-10 > >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-3513 'IP Version 6 Addressing Architecture'. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-ipv6-addr-arch-v4-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-ipv6-addr-arch-v4-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 17 00:32:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06229 for ; Fri, 17 Oct 2003 00:32:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAMHO-0004QM-V8 for ipv6-archive@odin.ietf.org; Fri, 17 Oct 2003 00:32:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9H4VwRP017007 for ipv6-archive@odin.ietf.org; Fri, 17 Oct 2003 00:31:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAMHO-0004QE-OY for ipv6-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 00:31:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06207 for ; Fri, 17 Oct 2003 00:31:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAMHM-0006KY-00 for ipv6-web-archive@ietf.org; Fri, 17 Oct 2003 00:31:56 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAMHL-0006KV-00 for ipv6-web-archive@ietf.org; Fri, 17 Oct 2003 00:31:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAMFW-000497-Q3; Fri, 17 Oct 2003 00:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAMFJ-00048g-QV for ipv6@optimus.ietf.org; Fri, 17 Oct 2003 00:29:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06160 for ; Fri, 17 Oct 2003 00:29:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAMFH-0006JM-00 for ipv6@ietf.org; Fri, 17 Oct 2003 00:29:47 -0400 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1AAMFF-0006JE-00 for ipv6@ietf.org; Fri, 17 Oct 2003 00:29:45 -0400 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id AAA29060; Fri, 17 Oct 2003 00:29:42 -0400 (EDT) Date: Fri, 17 Oct 2003 00:29:42 -0400 (EDT) From: Dan Lanciani Message-Id: <200310170429.AAA29060@ss10.danlan.com> To: ipv6@ietf.org Subject: RE: IPv6 adoption behavior Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , "Tony Hain" wrote: |Dan Lanciani wrote: |> ... Attempting to pigeonhole |> each aspect of that isolation (and offer limited solutions) encourages a |> divide-and-sweep-under-the-rug attack. | |Recent evidence around the IETF supports this claim, but in the real world |where NAT is seen as the single solution to all the problems, we need to |break them down to show the alternative solutions to each. That's easier said than done. NAT is stiff competition--and it is the incumbent, so being almost as good is nowhere near good enough. Moreover, a single solution is appealing exactly because it is a single solution. You have to take that into account even if it is irrational. We all know how the NAT story was supposed to play out. The unwashed masses were going to struggle along in constant and terrible pain from the horrible effects of ambiguous addressing. Every day they would pray for the next generation of IP to descend from on high and save them. Because the pain of NAT had been so great, no cost (one-time or recurring) would be too high to pay for the privilege of renting multiple global addresses once again. But something went wrong. NAT was not as painful as it was supposed to be. For most users, NAT was empowering. Anyone--even an insignificant residential client--could hook up an entire network of their own. They could do this without having a network manager to go negotiate with the ISP for a few more expensive addresses. They could do this without talking to the ISP at all. And the networks worked. The machines could talk to each other without interference from the ISP and they could also talk to the internet when the ISP was up. The ISP could in fact be replaced with few repercussions for the user's machines. There was a brief period when people pondered why they had to set ftp's passive mode, but it quickly became the default. This may not be the way the net worked in the good old days (for those who even remembered when users were allowed to own their own addresses) but it was darn close: a lot closer than the pre-NAT PA situation, and a lot closer than the proposed IPv6 "solution" as currently envisioned. Network consumers are not fools. They may not understand the details, but they understand the functionality that they have at a high level. They are not going to give it up easily, and repeated assertions that they are suffering in great pain (the cure being to abandon NAT) will not be convincing. We need to offer them something better, where better is a true superset. I had high hopes that IPv6 could be that superset, but over the years I've seen it reduced to IPv4 with more address bits. Or worse. The internet is about interconnecting networks, not about turning the operation of those networks into a for-pay service of an external provider cloud. |> |Concerns about tracability are dealt with by RFC 3041 addresses. |> |> I have my doubts about this; it may backfire. If you tell your |> ISP that you |> need more privacy it may be happy to oblige by increasing the |> frequency with |> which your single valid address changes. Be careful what you wish for. | |If a provider is going to offer me a single address, I will insist on a |globally routable IPv4 one, It would be interesting to take a poll of people whose ISPs do not offer a globally routable IPv4 address to see what happened when they insisted on one. Even if they got it, it seems a roundabout way to assure IPv6 privacy... |> |That leaves address stability for external application use, |> |> It also leaves address rental cost, and limitations on number of addresses |> available regardless of what you may be willing to pay (at least within a |> class of service). | |Current policies are fed by the resource scarcity, which over the short term |is artifical, but over the long term is real. We haven't gotten the correct |version at the nav6tf web site yet, but a paper there will show that we will |need well over 400 additional /8's to get a single address to 20% of the |population outside the countries that already have one or more for 20% of |theirs. This is for an HD ratio of 90% which is well in excess of the pain |threashold documented in RFC3194. Taking that down to current practice of |85% more than triples the number of /8's required to well over 1300. And |again, that is only to provide one address to 20% of the population in those |countries that don't already have that many. | |Take scarcity off the table, and it will be difficult to maintain per |address costs if there is any competition in the environment. I disagree completely. ISPs use address count as a surrogate for bandwidth measurement, and they they want you to pay per machine (just as the cell phone companies want you to pay per phone even if you use only one at a time). It's a business model and it isn't going to change with IPv6. Besides, I want to be able to connect multiple machines even in areas with only a single uncompetitive ISP. I want a protocol solution that works regardless of the market dynamics. But I think you've just shown why we will fail. Other people have equally (un)convincing hand-waving arguments that ISPs will generously give us stable IPv6 prefixes even if they currently churn our IPv4 address daily. Clearly then we do not need site-locals or anything to replace them. As long as you are willing to dismiss the aspects of the problem that you don't care about (or leave them to the supposedly-competitive market) you will never find the unanimity to tackle the problem as a whole. |> It probably leaves other things that I am forgetting. I |> think this is a good illustration of the pigeonhole pitfall. If you fail |> to address any one aspect of isolation and that aspect is |> important to enough |> people, a NAT solution will appear to fill the void. That |> solution will likely |> include all the "bad" features of NAT as well simply because it's easy and |> people already understand the model. | |I agree, so we need to be documenting all the cases we can find for why |network managers will demand isolation from SP provided addresses. Why bother? You've already dismissed a critical requirement, and one which users understand NAT to accommodate perfectly. No matter what other problems you solve, the battle is lost by a single omission. |> The core issue appears to be that any comprehensive solution to |> the isolation |> problem would disenfranchise the address allocation hierarchy |> (just as simple |> PI allocation would), and we aren't prepared to do that. | |I agree that some approaches will disenfranchise some historical |institutions, but I don't think that is what is holding us back. I have yet to find any other explanation for why we discard relatively simple (yet comprehensive) solutions while spending time on extremely difficult and incomplete approaches like transparent renumbering. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 17 04:00:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23352 for ; Fri, 17 Oct 2003 04:00:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAPWW-0006Al-OU for ipv6-archive@odin.ietf.org; Fri, 17 Oct 2003 03:59:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9H7xmqx023728 for ipv6-archive@odin.ietf.org; Fri, 17 Oct 2003 03:59:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAPWV-0006Ad-OU for ipv6-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 03:59:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23311 for ; Fri, 17 Oct 2003 03:59:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAPWT-0000L1-00 for ipv6-web-archive@ietf.org; Fri, 17 Oct 2003 03:59:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAPWS-0000Ky-00 for ipv6-web-archive@ietf.org; Fri, 17 Oct 2003 03:59:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAPVn-00063w-8k; Fri, 17 Oct 2003 03:59:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAPVh-00063a-Gl for ipv6@optimus.ietf.org; Fri, 17 Oct 2003 03:58:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23223 for ; Fri, 17 Oct 2003 03:58:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAPVe-0000K7-00 for ipv6@ietf.org; Fri, 17 Oct 2003 03:58:54 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AAPVd-0000JS-00 for ipv6@ietf.org; Fri, 17 Oct 2003 03:58:54 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9H7wNL19782; Fri, 17 Oct 2003 00:58:23 -0700 X-mProtect: <200310170758> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdtuolTY; Wed, 15 Oct 2003 16:44:57 PDT Message-Id: <4.3.2.7.2.20031015163251.030d5350@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 15 Oct 2003 16:41:59 -0700 To: ipv6@ietf.org From: Bob Hinden Subject: Re: I-D ACTION:draft-ietf-ipv6-addr-arch-v4-00.txt Cc: hinden@iprg.nokia.com In-Reply-To: <200310101939.PAA15840@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > Title : IP Version 6 Addressing Architecture > Author(s) : R. Hinden, S. Deering > Filename : draft-ietf-ipv6-addr-arch-v4-00.txt > Pages : 25 > Date : 2003-10-10 This new version of the IPv6 address architecture has changes in two areas: - Deprecated the Site-Local prefix - Resolve issues raised in IAB response to Robert Elz appeal Note: The changes relating to deprecating the SL prefix are intended to track the deprecation draft and are subject to change until that document is completed and approved. A detailed list of the changes can be found in "APPENDIX B: Changes from RFC-3513". Also, a diff'ed version with the draft that became RFC3513 can be found at: http://people.nokia.net/~hinden/draft-ietf-ipv6-addr-arch-v4-00.html This makes it easy to see many of the specific small changes. It less useful where there were major changes in a section (e.g., changes from previous RFC, IANA considerations, etc.). Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 17 05:10:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25091 for ; Fri, 17 Oct 2003 05:10:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAQcT-00013W-Hx for ipv6-archive@odin.ietf.org; Fri, 17 Oct 2003 05:10:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9H9A1cc004057 for ipv6-archive@odin.ietf.org; Fri, 17 Oct 2003 05:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAQcS-00013M-1o for ipv6-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 05:10:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25050 for ; Fri, 17 Oct 2003 05:09:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAQcO-00010v-00 for ipv6-web-archive@ietf.org; Fri, 17 Oct 2003 05:09:56 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAQcO-00010s-00 for ipv6-web-archive@ietf.org; Fri, 17 Oct 2003 05:09:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAQbZ-0000nb-BR; Fri, 17 Oct 2003 05:09:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAQAO-0008Rs-PX for ipv6@optimus.ietf.org; Fri, 17 Oct 2003 04:41:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24443 for ; Fri, 17 Oct 2003 04:40:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAQAL-0000mN-00 for ipv6@ietf.org; Fri, 17 Oct 2003 04:40:57 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AAQAK-0000mK-00 for ipv6@ietf.org; Fri, 17 Oct 2003 04:40:56 -0400 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id EAAF315210 for ; Fri, 17 Oct 2003 17:40:54 +0900 (JST) Date: Fri, 17 Oct 2003 17:40:52 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: A list of issues for RFC2462 update User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hello, The attached below is a issue list to make necessary updates on RFC2462 (Stateless Address Autoconfiguration). To make this list, I've grepped the ipngwg/ipv6 ML archives from Jan. 1998 with the keywords "2462" and "stateless," and picked up issues that seem to be related to this update. Of course, I'm not claiming the keywords are enough, and even if they are, I may have missed something important. Thus, any corrections/additions are welcome. I'd apologize in advance the list is not necessarily very readable, but I believe it provides some hints to start discussion. I'll collect comments on the list, and edit a new internet draft which will basically be a copy of RFC2462 with the issue list. Due to a lack of time to the cut-off date of an initial draft, I don't think I can propose any resolutions to the issues. So, please concentrate, at the moment, on completing or correcting the list, rather than to discuss how to solve particular ones. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp Easy ones (which will only need some editorial works): - A minor typo by Ignatios Souvatzis, Dec. 1998 http://www.wcug.wwu.edu/lists/ipng/199812/msg00043.html - Dead Code in Addrconf DOS Algortim Prevention by Jim Bound, Nov 1998 http://www.wcug.wwu.edu/lists/ipng/199811/msg00024.html - A corner case about inbound NA processing by Richard Draves (via TAHI test), Jun 2000 There was a consensus on the behavior, but the text is not clear. Need to update. - Unclear text about StoredLifetime by jinmei, Aug 2001 http://www.wcug.wwu.edu/lists/ipng/200108/msg00541.html need to clarify the text. === Issues that may require some discussion, but will not be very hard to get consensus: - Source address selection issues wrt deprecated addresses mainly by Richard Draves, several times. e.g. which should be preferred between a deprecated address and smaller-scope address? - Deprecated address handling (the semantics of "new communication" is not very clear) by itojun, Nov 2000 and Aug 2002 There seemed to be a consensus on a text proposed by Thomas Narten: http://www.atm.tut.fi/list-archive/ipng/msg05182.html Erik Nordmark made a related point (what if an application specifies a deprecated address as a source address): http://www.atm.tut.fi/list-archive/ipng/msg05311.html There seemed to be no discussion on this, but we may need to consider this as well. - Semantics about the L=0 and A=1 case by Fred Templin, Feb 2003 Thomas Narten said he did not see the need for further clarification (which I agree on): http://www.atm.tut.fi/list-archive/ipng/msg07820.html - Conflict with the MLD spec about random delay for the first packet by Greg Daley, May 2005 http://www.atm.tut.fi/list-archive/ipng/msg09614.html - Using stable storage for autoconfigured addresses by Erik Nordmark, Jun 2002 http://www.atm.tut.fi/list-archive/ipng/msg04383.html There seemed to be no discussion on this. === Issues that may be controversial: - DAD related issues inconsistency in the text (mixture of SHOULD and MAY) by itojun, Jun 2001 What about the link partitioning case by Pekka Savola, Jun 2001(?) omitting DAD, DAD vs DIID, etc. many people, many times - Possible Denial of Service Attack by Ken Powell, Feb 2002 What if a malicious node intentionally sends prefixes for other LANs? There seemed to be no clear consensus. - The semantics of the M/O flags by several people, several times. Points from Ralph Droms in Mar 2003 seems to be a good starting point: http://www.atm.tut.fi/list-archive/ipng/msg03047.html a. the text needs to be updated to use RFC 2119 keywords b. which keywords? c. what is "the stateful configuration protocol"? d. if the answer to "c" is DHCPv6, should RFC 2462 more explicitly reference the configuration-only version of DHCPv6 in the description of the 'O'flag? Adam Machalek also pointed out some inconsistency about mandatory level of the stateful configuration protocol: http://www.atm.tut.fi/list-archive/ipng/msg04363.html - Whether a (not a host) router can autoconfigure itself using RFC2462 (or bis) including if a router can configure a global address by stateless autoconf if a router can configure a link-local address in a way described in RFC 2462 if a router can configure itself about "other" configuration information by several people, several times - If we need a 'not-yet-ready' status of an autoconfigured address to help renumbering operation by Fred Baker, Apr 2003 http://www.atm.tut.fi/list-archive/ipng/msg09394.html - Avoiding interface failure upon DAD failure (mainly) by Jari Arkko, May 2003 related to mip6. (the latest draft leaves this as "ND extensions") - If RFC2462 requires 64bit IFID by several people, several times. - Issues raised in the send requirement draft. (Sorry, I've not gone through the send requirement draft. So there may or may not be issues from the draft that need to be added here) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 17 05:10:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25122 for ; Fri, 17 Oct 2003 05:10:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAQcY-00017s-4I for ipv6-archive@odin.ietf.org; Fri, 17 Oct 2003 05:10:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9H9A5Jn004322 for ipv6-archive@odin.ietf.org; Fri, 17 Oct 2003 05:10:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAQcX-00017d-Kz for ipv6-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 05:10:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25054 for ; Fri, 17 Oct 2003 05:09:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAQcU-000112-00 for ipv6-web-archive@ietf.org; Fri, 17 Oct 2003 05:10:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAQcT-00010z-00 for ipv6-web-archive@ietf.org; Fri, 17 Oct 2003 05:10:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAQcW-00013y-1z; Fri, 17 Oct 2003 05:10:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAQbz-0000sy-1P for ipv6@optimus.ietf.org; Fri, 17 Oct 2003 05:09:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25042 for ; Fri, 17 Oct 2003 05:09:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAQbv-00010f-00 for ipv6@ietf.org; Fri, 17 Oct 2003 05:09:27 -0400 Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx with esmtp (Exim 4.12) id 1AAQbv-00010c-00 for ipv6@ietf.org; Fri, 17 Oct 2003 05:09:27 -0400 Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel10.hp.com (Postfix) with ESMTP id 0D8CC1C01BB5 for ; Fri, 17 Oct 2003 02:09:26 -0700 (PDT) Received: from hp.com (nt23076.india.hp.com [15.42.230.76]) by hpuxsrv.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id OAA15480 for ; Fri, 17 Oct 2003 14:43:28 +0530 (IST) Message-ID: <3F8FB1C2.2010404@hp.com> Date: Fri, 17 Oct 2003 14:39:22 +0530 From: Srinivasan Narasimhan Reply-To: srinivasan_narasimhan@hp.com Organization: Hewlett Packard STSD User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Question on RFC 2473 about Tunnel Encapsulation Limit Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Section 4.1.1 of RFC 2473 discusses the procedure to be followed for every packet entering the tunnel with respect to Tunnel Encapsulation Limit. Following 4 cases are discussed: 1. A packet with a tunnel encapsulation limit value of zero. 2. A packet with a non-zero tunnel encapsulation limit. 3. A packet with no tunnel encapsulation limit, but a tunnel encapsulation limit value is configured in the new tunnel entry point. 4. A packet with no tunnel encapsulation limit and no limit is configured in the new tunnel entry point. Consider a case where the incoming IPv6 packet has a tunnel encapsulation limit value of 100. But the new tunnel entry point has a tunnel encapsulation limit of 50. Should the new tunnel encapsulation limit be 99 or 50? I guess this case is not discussed in the RFC. -- Cheers, Cheenu +91 (80) 2053120 TN 847-3120 Pager: +91 (9624) 274259 Email Page: 274259@messageindia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 17 07:28:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28011 for ; Fri, 17 Oct 2003 07:28:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AASlf-0006ls-Hu for ipv6-archive@odin.ietf.org; Fri, 17 Oct 2003 07:27:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HBRdGZ026028 for ipv6-archive@odin.ietf.org; Fri, 17 Oct 2003 07:27:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AASlf-0006lj-CZ for ipv6-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 07:27:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27973 for ; Fri, 17 Oct 2003 07:27:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AASle-0002Mp-00 for ipv6-web-archive@ietf.org; Fri, 17 Oct 2003 07:27:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AASle-0002Mm-00 for ipv6-web-archive@ietf.org; Fri, 17 Oct 2003 07:27:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AASl4-0006bB-0c; Fri, 17 Oct 2003 07:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AASk2-0006Zs-Si for ipv6@optimus.ietf.org; Fri, 17 Oct 2003 07:26:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27939 for ; Fri, 17 Oct 2003 07:25:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AASk2-0002M9-00 for ipv6@ietf.org; Fri, 17 Oct 2003 07:25:58 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1AASk1-0002M6-00 for ipv6@ietf.org; Fri, 17 Oct 2003 07:25:57 -0400 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9HBPded016209; Fri, 17 Oct 2003 13:25:39 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <200310170429.AAA29060@ss10.danlan.com> References: <200310170429.AAA29060@ss10.danlan.com> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org From: Iljitsch van Beijnum Subject: Re: IPv6 adoption behavior Date: Fri, 17 Oct 2003 13:25:38 +0200 To: Dan Lanciani X-Mailer: Apple Mail (2.604) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 17 okt 2003, at 6:29, Dan Lanciani wrote: > NAT is stiff competition--and it is the > incumbent, so being almost as good is nowhere near good enough. > Moreover, > a single solution is appealing exactly because it is a single solution. > You have to take that into account even if it is irrational. So what are you saying? That we should give up on IPv6 because IPv4 w/NAT is so great that we don't need it? Or that we should add NAT to IPv6? I'm not buying. IPv6 is superior to IPv4 (with and without NAT) in many ways. The trouble with networking has always been that even poorly designed networks can work well so there is little incentive to do it right. > NAT was not as painful as it was supposed to be. > For most users, NAT was empowering. Anyone--even an insignificant > residential > client--could hook up an entire network of their own. But this entire network only enjoys a subset of the capabilities of a network connected without NAT. Application builders are bending over backwards to work within those limits, which costs time and money and isn't 100% successful. But this discussion is moot as there is no requirement that IETF protocols are adopted by 100% of all internet-connected systems. > It would be interesting to take a poll of people whose ISPs do not > offer > a globally routable IPv4 address That is impossible as ISPs by definition offer access to the internet which means providing globally routable addresss space. So such an SP wouldn't be an _I_SP. > |will show that we will > |need well over 400 additional /8's to get a single address to 20% of > the > |population outside the countries that already have one or more for > 20% of > |theirs. This is for an HD ratio of 90% which is well in excess of the > pain > |threashold documented in RFC3194. That's 6.4 billion addresses, a little more than four times what we have available today, for no more than 1.3 billion users. Can someone please explain where the other 4 addresses per user go? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 17 15:37:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18737 for ; Fri, 17 Oct 2003 15:37:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAaOu-0006ac-2X for ipv6-archive@odin.ietf.org; Fri, 17 Oct 2003 15:36:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HJaerS025329 for ipv6-archive@odin.ietf.org; Fri, 17 Oct 2003 15:36:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAaOt-0006aN-FD for ipv6-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 15:36:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18631 for ; Fri, 17 Oct 2003 15:36:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAaOs-0007UR-00 for ipv6-web-archive@ietf.org; Fri, 17 Oct 2003 15:36:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAaOr-0007UN-00 for ipv6-web-archive@ietf.org; Fri, 17 Oct 2003 15:36:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAaNL-0006Cl-Jl; Fri, 17 Oct 2003 15:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAaN0-0006BO-Nq for ipv6@optimus.ietf.org; Fri, 17 Oct 2003 15:34:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18229 for ; Fri, 17 Oct 2003 15:34:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAaMz-0007QL-00 for ipv6@ietf.org; Fri, 17 Oct 2003 15:34:41 -0400 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1AAaMx-0007QB-00 for ipv6@ietf.org; Fri, 17 Oct 2003 15:34:40 -0400 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id PAA05878; Fri, 17 Oct 2003 15:34:27 -0400 (EDT) Date: Fri, 17 Oct 2003 15:34:27 -0400 (EDT) From: Dan Lanciani Message-Id: <200310171934.PAA05878@ss10.danlan.com> To: ipv6@ietf.org Subject: Re: IPv6 adoption behavior Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Iljitsch van Beijnum wrote: |On 17 okt 2003, at 6:29, Dan Lanciani wrote: | |> NAT is stiff competition--and it is the |> incumbent, so being almost as good is nowhere near good enough. |> Moreover, |> a single solution is appealing exactly because it is a single solution. |> You have to take that into account even if it is irrational. | |So what are you saying? I'm saying that IPv6 will be a hard sell since it brings great upgrade costs and offers a reduction in the functionality that people expect and depend on. |That we should give up on IPv6 because IPv4 w/NAT is so great that we |don't need it? By posing this question, are you suggesting that we really can't make IPv6 as great as IPv4+NAT? Or that we shouldn't even try? |Or that we should add NAT to IPv6? By posing this question, are you suggesting that the only way to make IPv6 as great as IPv4+NAT is to add NAT to IPv6? If that is true then the market will take care of adding NAT to IPv6; we don't have to bother. |I'm not buying. IPv6 is superior to IPv4 (with and without NAT) in many |ways. Unfortunately, being "superior" in some abstract sense is not sufficient for something as utilitarian as a networking protocol suite. We have to examine actual usage requirements. |The trouble with networking has always been that even poorly |designed networks can work well so there is little incentive to do it |right. I don't buy into the idea that users are not entitled to the functionality that they now enjoy just because it is somehow tainted by having once been provided by NAT. If you are claiming that there is just no way to deliver that functionality with a network that is *not* poorly designed then I think you have to reconsider your definition of "poorly." |> NAT was not as painful as it was supposed to be. |> For most users, NAT was empowering. Anyone--even an insignificant |> residential |> client--could hook up an entire network of their own. | |But this entire network only enjoys a subset of the capabilities of a |network connected without NAT. Your statement is extremely misleading, comparing apples and turnips. It is true that _a_ network connected without NAT enjoys a slightly larger set of capabilities (though they are capabilities that are not important to the typical NAT user) than the same network connected with NAT. But the residential client in question typically does not have the opportunity to connect _her_ network without NAT because her ISP provides only one dynamic IP address. The correct comparison, then, is between a NAT-connected network and a network that is not connected to the internet at all. Which one enjoys greater capability? |Application builders are bending over |backwards to work within those limits, which costs time and money and |isn't 100% successful. Even if this were true, it merely proves that the market will bend over backwards to accommodate the functional requirements of the users. This is a valuable lesson that we should take to heart. We cannot ignore those requirements with impunity. But why did you bring this up at all? It seems to be part of the argument that NAT is bad (and by the way, I agree that NAT is bad--it just happens to be better than all the alternatives) and therefore we need not provide any of the good things that NAT offers. Why can't we provide a protocol that offers the same benefits that NAT offers but which does not require application builders to bend over backwards? |But this discussion is moot as there is no requirement that IETF |protocols are adopted by 100% of all internet-connected systems. Wow. If that renders this discussion moot, wouldn't it render any discussion of anything moot? |> It would be interesting to take a poll of people whose ISPs do not |> offer |> a globally routable IPv4 address | |That is impossible as ISPs by definition offer access to the internet |which means providing globally routable addresss space. So such an SP |wouldn't be an _I_SP. Wow. I know this whole topic is sensitive, but resorting to acronym games? |> |will show that we will |> |need well over 400 additional /8's to get a single address to 20% of |> the |> |population outside the countries that already have one or more for |> 20% of |> |theirs. This is for an HD ratio of 90% which is well in excess of the |> pain |> |threashold documented in RFC3194. | |That's 6.4 billion addresses, a little more than four times what we |have available today, for no more than 1.3 billion users. Can someone |please explain where the other 4 addresses per user go? I did not write the above quoted text and I have no explanation for it. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 17 17:28:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25302 for ; Fri, 17 Oct 2003 17:28:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAc8Q-0003qr-U8 for ipv6-archive@odin.ietf.org; Fri, 17 Oct 2003 17:27:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HLRkjX014799 for ipv6-archive@odin.ietf.org; Fri, 17 Oct 2003 17:27:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAc8Q-0003qc-NV for ipv6-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 17:27:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25244 for ; Fri, 17 Oct 2003 17:27:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAc8O-0001mA-00 for ipv6-web-archive@ietf.org; Fri, 17 Oct 2003 17:27:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAc8N-0001m7-00 for ipv6-web-archive@ietf.org; Fri, 17 Oct 2003 17:27:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAc7i-0003kl-5H; Fri, 17 Oct 2003 17:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAc7c-0003js-3d for ipv6@optimus.ietf.org; Fri, 17 Oct 2003 17:26:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25212 for ; Fri, 17 Oct 2003 17:26:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAc7Z-0001lj-00 for ipv6@ietf.org; Fri, 17 Oct 2003 17:26:53 -0400 Received: from usea-naimss3.unisys.com ([192.61.61.105]) by ietf-mx with esmtp (Exim 4.12) id 1AAc7Z-0001lV-00 for ipv6@ietf.org; Fri, 17 Oct 2003 17:26:53 -0400 Received: from us-ea-gtwy-6.ea.unisys.com ([192.61.146.102]unverified) by 192.61.61.105 with InterScan Messaging Security Suite; Fri, 17 Oct 2003 16:30:55 -0500 Received: by us-ea-gtwy-6.ea.unisys.com with Internet Mail Service (5.5.2656.59) id <4RG1HRCQ>; Fri, 17 Oct 2003 16:26:21 -0500 Message-ID: From: "Sellers, Julian P" To: "'ipv6@ietf.org'" Subject: RE: I-D ACTION:draft-ietf-ipv6-addr-arch-v4-00.txt Date: Fri, 17 Oct 2003 16:26:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >-----Original Message----- >From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.ca] . . . >* section 2.5.4 last paragraph > It mentions that the global routing prefix is assigned >to a "site" >which is fuzzy. Is it possible to make it clearer? Similarly I >would think >of a link to be some layer2 connection not necessarily comprising a >subnet. . . . (Actually it's the first paragraph of 2.5.4.) The document should refer to the "link" definition in [ipv6] as it does for "interface" (see 2.0). This should happen at or before the first reference to "link," which is at the end of 2.1: Currently IPv6 continues the IPv4 model that a subnet prefix is associated with one link. Multiple subnet prefixes may be assigned to the same link. Julian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Oct 18 18:04:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10557 for ; Sat, 18 Oct 2003 18:04:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAzAm-0003j7-Qj for ipv6-archive@odin.ietf.org; Sat, 18 Oct 2003 18:03:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9IM3i1j014325 for ipv6-archive@odin.ietf.org; Sat, 18 Oct 2003 18:03:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAzAm-0003iy-Lu for ipv6-web-archive@optimus.ietf.org; Sat, 18 Oct 2003 18:03:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10492 for ; Sat, 18 Oct 2003 18:03:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAzAk-0007JX-00 for ipv6-web-archive@ietf.org; Sat, 18 Oct 2003 18:03:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAzAj-0007JT-00 for ipv6-web-archive@ietf.org; Sat, 18 Oct 2003 18:03:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAz98-0003R7-6M; Sat, 18 Oct 2003 18:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAz8p-0003Ok-4l for ipv6@optimus.ietf.org; Sat, 18 Oct 2003 18:01:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10390 for ; Sat, 18 Oct 2003 18:01:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAz8m-0007IM-00 for ipv6@ietf.org; Sat, 18 Oct 2003 18:01:40 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1AAz8l-0007II-00 for ipv6@ietf.org; Sat, 18 Oct 2003 18:01:39 -0400 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9IM1Fed041157; Sun, 19 Oct 2003 00:01:15 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <200310171934.PAA05878@ss10.danlan.com> References: <200310171934.PAA05878@ss10.danlan.com> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <98E55676-01B6-11D8-A47E-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org From: Iljitsch van Beijnum Subject: Re: IPv6 adoption behavior Date: Sun, 19 Oct 2003 00:01:16 +0200 To: Dan Lanciani X-Mailer: Apple Mail (2.604) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 17 okt 2003, at 21:34, Dan Lanciani wrote: > |So what are you saying? > I'm saying that IPv6 will be a hard sell since it brings great upgrade > costs and offers a reduction in the functionality that people expect > and > depend on. I don't see the upgrade costs for regular users. Users are by now used to upgrading monthly (if not more often) to plug the latest and greatest security holes, so a software upgrade to install IPv6 functionality somewhere in the next three years or so isn't a huge hardship. Functionality won't disappear unless people turn off IPv4, which I don't expect them to do. (I even get strange looks from people in IPv6 circles when I say I want to run IPv6-only hosts for test purposes.) > |That we should give up on IPv6 because IPv4 w/NAT is so great that we > |don't need it? > By posing this question, are you suggesting that we really can't make > IPv6 > as great as IPv4+NAT? Or that we shouldn't even try? As long as IPv6 isn't a full superset of IPv4+NAT then it's going to be possible to argue that "IPv6 isn't as great as IPv4+NAT". But I think we can and should add all the missing stuff to IPv6. > |Or that we should add NAT to IPv6? > By posing this question, are you suggesting that the only way to make > IPv6 > as great as IPv4+NAT is to add NAT to IPv6? If that is true then the > market > will take care of adding NAT to IPv6; we don't have to bother. If we're going to be doing NAT anyway why bother with IPv6? Yes, there are some advantages regardless, but those alone aren't worth the hassle of upgrading the whole internet. > |I'm not buying. IPv6 is superior to IPv4 (with and without NAT) in > many > |ways. > Unfortunately, being "superior" in some abstract sense is not > sufficient for > something as utilitarian as a networking protocol suite. We have to > examine > actual usage requirements. Yes. But note that this doesn't have to be the actual end-user. > |The trouble with networking has always been that even poorly > |designed networks can work well so there is little incentive to do it > |right. > I don't buy into the idea that users are not entitled to the > functionality > that they now enjoy just because it is somehow tainted by having once > been > provided by NAT. Well, there was a time when I had email without spam too. Sometimes progress isn't progress. It is becoming quite apparent that having a stable internal network and an ephemeral externally reachable network provide seamless functionality can only be achieved using very dirty hacks. NAT is one of those hacks, two-faced DNS is another one. > If you are claiming that there is just no way to deliver > that functionality with a network that is *not* poorly designed then I > think > you have to reconsider your definition of "poorly." Disagree. The internet supported address portability until 10 years ago. This was a poor design because it doesn't scale, regardless of the usefulness of the functionality. > |That's 6.4 billion addresses, a little more than four times what we > |have available today, for no more than 1.3 billion users. Can someone > |please explain where the other 4 addresses per user go? > I did not write the above quoted text and I have no explanation for it. I know. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Oct 19 00:02:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17476 for ; Sun, 19 Oct 2003 00:02:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB4m3-00052S-I5 for ipv6-archive@odin.ietf.org; Sun, 19 Oct 2003 00:02:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9J42Zuw019362 for ipv6-archive@odin.ietf.org; Sun, 19 Oct 2003 00:02:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB4m3-00052D-DX for ipv6-web-archive@optimus.ietf.org; Sun, 19 Oct 2003 00:02:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17452 for ; Sun, 19 Oct 2003 00:02:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AB4m1-00025I-00 for ipv6-web-archive@ietf.org; Sun, 19 Oct 2003 00:02:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AB4m0-00025F-00 for ipv6-web-archive@ietf.org; Sun, 19 Oct 2003 00:02:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB4kZ-0004jP-03; Sun, 19 Oct 2003 00:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB4kW-0004hB-3M for ipv6@optimus.ietf.org; Sun, 19 Oct 2003 00:01:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17415 for ; Sun, 19 Oct 2003 00:00:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AB4kT-000212-00 for ipv6@ietf.org; Sun, 19 Oct 2003 00:00:57 -0400 Received: from dsl092-066-068.bos1.dsl.speakeasy.net ([66.92.66.68] helo=cyteen.hactrn.net) by ietf-mx with esmtp (Exim 4.12) id 1AB4kT-00020X-00 for ipv6@ietf.org; Sun, 19 Oct 2003 00:00:57 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id CB26E415 for ; Sun, 19 Oct 2003 00:00:26 -0400 (EDT) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 19 Oct 2003 00:00:26 -0400 Message-Id: <20031019040026.CB26E415@cyteen.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Messages | Bytes | Who --------+------+--------+----------+------------------------ 8.97% | 7 | 8.96% | 40397 | ipng-incoming@danlan.com 7.69% | 6 | 6.61% | 29805 | iljitsch@muada.com 2.56% | 2 | 10.41% | 46931 | athene@sait.samsung.co.kr 6.41% | 5 | 6.44% | 29027 | jeroen@unfix.org 5.13% | 4 | 7.64% | 34450 | brc@zurich.ibm.com 6.41% | 5 | 5.31% | 23947 | mansaxel@sunet.se 3.85% | 3 | 4.94% | 22282 | jim.bound@hp.com 3.85% | 3 | 3.16% | 14258 | jrh@it.uc3m.es 3.85% | 3 | 2.90% | 13063 | michel@arneill-py.sacramento.ca.us 2.56% | 2 | 3.10% | 13973 | alh-ietf@tndh.net 2.56% | 2 | 2.86% | 12883 | mohsen.souissi@nic.fr 2.56% | 2 | 2.82% | 12705 | brian@innovationslab.net 2.56% | 2 | 2.57% | 11603 | jinmei@isl.rdc.toshiba.co.jp 2.56% | 2 | 2.48% | 11166 | ipng@uni-muenster.de 2.56% | 2 | 2.35% | 10601 | gih@telstra.net 2.56% | 2 | 2.20% | 9933 | fred@cisco.com 2.56% | 2 | 1.85% | 8343 | moore@cs.utk.edu 2.56% | 2 | 1.77% | 7970 | kurtis@kurtis.pp.se 2.56% | 2 | 1.68% | 7569 | h.soliman@flarion.com 2.56% | 2 | 1.59% | 7153 | bmanning@isi.edu 2.56% | 2 | 1.58% | 7133 | pbarany@qualcomm.com 1.28% | 1 | 1.85% | 8349 | suresh.krishnan@ericsson.ca 1.28% | 1 | 1.65% | 7425 | ipv6@c753173126e0bc8b057a22829880cf26.nosense.org 1.28% | 1 | 1.49% | 6704 | dthaler@windows.microsoft.com 1.28% | 1 | 1.20% | 5395 | j.gregson@dpmms.cam.ac.uk 1.28% | 1 | 1.18% | 5315 | andrew.e.white@motorola.com 1.28% | 1 | 1.07% | 4843 | internet-drafts@ietf.org 1.28% | 1 | 0.99% | 4481 | sra+ipng@hactrn.net 1.28% | 1 | 0.96% | 4345 | soohong.park@samsung.com 1.28% | 1 | 0.92% | 4152 | pekkas@netcore.fi 1.28% | 1 | 0.90% | 4065 | leifj@it.su.se 1.28% | 1 | 0.88% | 3967 | srinivasan_narasimhan@hp.com 1.28% | 1 | 0.88% | 3961 | hinden@iprg.nokia.com 1.28% | 1 | 0.81% | 3668 | cfriacas@fccn.pt 1.28% | 1 | 0.81% | 3665 | yhhan@thinkonweb.com 1.28% | 1 | 0.78% | 3532 | julian.sellers@unisys.com 1.28% | 1 | 0.36% | 1631 | sra@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 78 |100.00% | 450690 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Oct 19 21:29:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25453 for ; Sun, 19 Oct 2003 21:29:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABOqq-0005ZW-Cu for ipv6-archive@odin.ietf.org; Sun, 19 Oct 2003 21:28:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9K1Sqx0021414 for ipv6-archive@odin.ietf.org; Sun, 19 Oct 2003 21:28:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABOqq-0005ZJ-42 for ipv6-web-archive@optimus.ietf.org; Sun, 19 Oct 2003 21:28:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25396 for ; Sun, 19 Oct 2003 21:28:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABOqn-0002KK-00 for ipv6-web-archive@ietf.org; Sun, 19 Oct 2003 21:28:49 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABOqm-0002KG-00 for ipv6-web-archive@ietf.org; Sun, 19 Oct 2003 21:28:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABOq2-0005MC-7h; Sun, 19 Oct 2003 21:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABOpt-0005Ks-17 for ipv6@optimus.ietf.org; Sun, 19 Oct 2003 21:27:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25331 for ; Sun, 19 Oct 2003 21:27:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABOpq-0002Iv-00 for ipv6@ietf.org; Sun, 19 Oct 2003 21:27:50 -0400 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by ietf-mx with esmtp (Exim 4.12) id 1ABOpp-0002Ir-00 for ipv6@ietf.org; Sun, 19 Oct 2003 21:27:49 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 7CDAC87CF; Sun, 19 Oct 2003 21:27:49 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sun, 19 Oct 2003 21:27:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 adoption behavior Date: Sun, 19 Oct 2003 21:27:48 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA147@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 adoption behavior Thread-Index: AcOU5gHEwpqhS632Q2OQSsoBBCXDrQBwniUw From: "Bound, Jim" To: "Dan Lanciani" , X-OriginalArrivalTime: 20 Oct 2003 01:27:49.0204 (UTC) FILETIME=[5F7AF940:01C396A9] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dan, As side note. Outside of the IETF a very coordinated and strong force is stating NAT business view should not be propogated with IPv6 adoption and NAT does not provide security and has a great cost. That body/force is the IPv6 Forum with Task Forces totally dedicated to the deployment of IPv6 in almost every geography in the world. The IPv6 Forum and Task Forces have the attention of Public Governments/Departments and Private Enterprise. If we are successful, and I think we will be, the idea of NAT for IPv6 adoption is dead. We are now running IPv6 network pilot across the U.S. and just had successful two week bring-up period of the new North American Moonv6 network and participation from many entities. Native IPv6 was run across the U.S. and Native IPv6 with IPsec too. www.moonv6.org Moonv6 will stay up too. =20 Regards, /jim > -----Original Message----- > From: Dan Lanciani [mailto:ipng-incoming@danlan.com]=20 > Sent: Friday, October 17, 2003 3:34 PM > To: ipv6@ietf.org > Subject: Re: IPv6 adoption behavior >=20 >=20 > Iljitsch van Beijnum wrote: >=20 > |On 17 okt 2003, at 6:29, Dan Lanciani wrote: > | > |> NAT is stiff competition--and it is the > |> incumbent, so being almost as good is nowhere near good enough. > |> Moreover, > |> a single solution is appealing exactly because it is a=20 > single solution. > |> You have to take that into account even if it is irrational. > | > |So what are you saying? >=20 > I'm saying that IPv6 will be a hard sell since it brings=20 > great upgrade costs and offers a reduction in the=20 > functionality that people expect and depend on. >=20 > |That we should give up on IPv6 because IPv4 w/NAT is so great that we > |don't need it? >=20 > By posing this question, are you suggesting that we really=20 > can't make IPv6 as great as IPv4+NAT? Or that we shouldn't even try? >=20 > |Or that we should add NAT to IPv6? >=20 > By posing this question, are you suggesting that the only way=20 > to make IPv6 as great as IPv4+NAT is to add NAT to IPv6? If=20 > that is true then the market will take care of adding NAT to=20 > IPv6; we don't have to bother. >=20 > |I'm not buying. IPv6 is superior to IPv4 (with and without=20 > NAT) in many > |ways. >=20 > Unfortunately, being "superior" in some abstract sense is not=20 > sufficient for something as utilitarian as a networking=20 > protocol suite. We have to examine actual usage requirements. >=20 > |The trouble with networking has always been that even poorly > |designed networks can work well so there is little incentive=20 > to do it=20 > |right. >=20 > I don't buy into the idea that users are not entitled to the=20 > functionality that they now enjoy just because it is somehow=20 > tainted by having once been provided by NAT. If you are=20 > claiming that there is just no way to deliver that=20 > functionality with a network that is *not* poorly designed=20 > then I think you have to reconsider your definition of "poorly." >=20 > |> NAT was not as painful as it was supposed to be. > |> For most users, NAT was empowering. Anyone--even an insignificant > |> residential > |> client--could hook up an entire network of their own. > | > |But this entire network only enjoys a subset of the capabilities of a > |network connected without NAT. >=20 > Your statement is extremely misleading, comparing apples and=20 > turnips. It is true that _a_ network connected without NAT=20 > enjoys a slightly larger set of capabilities (though they are=20 > capabilities that are not important to the typical NAT user)=20 > than the same network connected with NAT. But the=20 > residential client in question typically does not have the=20 > opportunity to connect _her_ network without NAT because her=20 > ISP provides only one dynamic IP address. The correct=20 > comparison, then, is between a NAT-connected network and a=20 > network that is not connected to the internet at all. Which=20 > one enjoys greater capability? >=20 > |Application builders are bending over > |backwards to work within those limits, which costs time and=20 > money and=20 > |isn't 100% successful. >=20 > Even if this were true, it merely proves that the market will=20 > bend over backwards to accommodate the functional=20 > requirements of the users. This is a valuable lesson that we=20 > should take to heart. We cannot ignore those requirements=20 > with impunity. But why did you bring this up at all? It=20 > seems to be part of the argument that NAT is bad (and by the=20 > way, I agree that NAT is bad--it just happens to be better=20 > than all the alternatives) and therefore we need not provide=20 > any of the good things that NAT offers. Why can't we provide=20 > a protocol that offers the same benefits that NAT offers but=20 > which does not require application builders to bend over backwards? >=20 > |But this discussion is moot as there is no requirement that IETF > |protocols are adopted by 100% of all internet-connected systems. >=20 > Wow. If that renders this discussion moot, wouldn't it=20 > render any discussion of anything moot? >=20 > |> It would be interesting to take a poll of people whose ISPs do not > |> offer > |> a globally routable IPv4 address > | > |That is impossible as ISPs by definition offer access to the internet > |which means providing globally routable addresss space. So=20 > such an SP=20 > |wouldn't be an _I_SP. >=20 > Wow. I know this whole topic is sensitive, but resorting to=20 > acronym games? >=20 > |> |will show that we will > |> |need well over 400 additional /8's to get a single=20 > address to 20% of > |> the > |> |population outside the countries that already have one or more for > |> 20% of > |> |theirs. This is for an HD ratio of 90% which is well in excess of=20 > |> |the > |> pain > |> |threashold documented in RFC3194. > | > |That's 6.4 billion addresses, a little more than four times what we > |have available today, for no more than 1.3 billion users.=20 > Can someone=20 > |please explain where the other 4 addresses per user go? >=20 > I did not write the above quoted text and I have no=20 > explanation for it. >=20 > Dan Lanciani > ddl@danlan.*com >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 20 00:25:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29455 for ; Mon, 20 Oct 2003 00:25:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABRb4-00022h-Vh for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 00:24:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9K4Okfb007845 for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 00:24:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABRb4-00022S-QA for ipv6-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 00:24:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29419 for ; Mon, 20 Oct 2003 00:24:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABRb2-0003f1-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 00:24:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABRb1-0003ey-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 00:24:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABRaM-0001ly-1k; Mon, 20 Oct 2003 00:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABRZY-0001VE-3d for ipv6@optimus.ietf.org; Mon, 20 Oct 2003 00:23:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29354 for ; Mon, 20 Oct 2003 00:23:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABRZV-0003ds-00 for ipv6@ietf.org; Mon, 20 Oct 2003 00:23:09 -0400 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1ABRZT-0003dp-00 for ipv6@ietf.org; Mon, 20 Oct 2003 00:23:07 -0400 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id AAA00548; Mon, 20 Oct 2003 00:23:04 -0400 (EDT) Date: Mon, 20 Oct 2003 00:23:04 -0400 (EDT) From: Dan Lanciani Message-Id: <200310200423.AAA00548@ss10.danlan.com> To: ipv6@ietf.org Subject: Re: IPv6 adoption behavior Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Iljitsch van Beijnum wrote: |On 17 okt 2003, at 21:34, Dan Lanciani wrote: | |> |So what are you saying? | |> I'm saying that IPv6 will be a hard sell since it brings great upgrade |> costs and offers a reduction in the functionality that people expect |> and |> depend on. | |I don't see the upgrade costs for regular users. Users are by now used |to upgrading monthly (if not more often) to plug the latest and |greatest security holes, so a software upgrade to install IPv6 |functionality somewhere in the next three years or so isn't a huge |hardship. I strongly doubt that IPv6 will be available as a software-only upgrade for any but the latest equipment. There is just too little incentive for vendors (especially ones who have gone out of business :) to support "legacy" hardware (where "legacy" seems to mean over six months old). |Functionality won't disappear unless people turn off IPv4, which I |don't expect them to do. Sure, but that's basically saying that IPv6 + IPv4+NAT can replace IPv4+NAT, which isn't very interesting. :) |(I even get strange looks from people in IPv6 |circles when I say I want to run IPv6-only hosts for test purposes.) That's a rather telling response... |> |That we should give up on IPv6 because IPv4 w/NAT is so great that we |> |don't need it? | |> By posing this question, are you suggesting that we really can't make |> IPv6 |> as great as IPv4+NAT? Or that we shouldn't even try? | |As long as IPv6 isn't a full superset of IPv4+NAT then it's going to be |possible to argue that "IPv6 isn't as great as IPv4+NAT". Well, your words, but it really isn't about arguing whether it is as great. Remember that the original assertion that I questioned was that IPv6 could substitute for IPv4+NAT. I think we have a long way to go before it can. |But I think |we can and should add all the missing stuff to IPv6. Naturally I agree, but it seems like one of the key features (address independence) is a stumbling block. |> |Or that we should add NAT to IPv6? | |> By posing this question, are you suggesting that the only way to make |> IPv6 |> as great as IPv4+NAT is to add NAT to IPv6? If that is true then the |> market |> will take care of adding NAT to IPv6; we don't have to bother. | |If we're going to be doing NAT anyway why bother with IPv6? I've been wondering that myself lately. Possibly IPv6 will be useful in circumstances where the provider can control the user's environment via restricted firmware, legal means, etc. (The canonical example seems to be smart phones.) Possibly IPv6+NAT will be marginally useful by slightly lowering the barriers to low-end-business connectivity while leaving the residential users with NAT. None of this sounds particularly revolutionary, but it could be evolutionary. Still, this doesn't answer the question of whether we *can* make IPv6 a superset of IPv4+NAT without making it IPv6+NAT. |> |I'm not buying. IPv6 is superior to IPv4 (with and without NAT) in |> many |> |ways. | |> Unfortunately, being "superior" in some abstract sense is not |> sufficient for |> something as utilitarian as a networking protocol suite. We have to |> examine |> actual usage requirements. | |Yes. But note that this doesn't have to be the actual end-user. I understand that actual end-user requirements are not a major consideration for IPv6 development. This has been discussed before and I've commented that I'm not thrilled with the decision to concentrate on provider requirements, but I can't raise a technical objection because it isn't a technical issue. On the other hand, you can only push this so far. Eventually you have to convince the end-users to use the service or it will fail. End-users have evolved a bit over the years. It's funny; I remember having essentially the same discussion of addressing considerations years ago. This was way before CIDR, when pretty much anyone could get potentially routable address space, but you couldn't get it routed unless you were a direct business-class customer of one of the proto-ISPs. My lament was that the business models of the proto-ISPs precluded the kind of structure I was hoping for: an individual networks his own computers and connects that network to the internet as in the pre-commercial model. The counter was that individuals didn't want or need such capability and wouldn't know what to do with it if they had it (presumably generating lots of tech support calls). Only nerds who remembered the old internet would be interested in such things. To a first approximation this was correct, but the real reason remained the service differentiation for direct customers who paid the big fees. So, long before anyone was talking about address depletion, the value of usable routable address space was recognized. As it is today. As it will be no matter how big the address space becomes. Post-CIDR (really post-provider-controlled-address-allocation) a generation of users grew up with little or no knowledge of the original internet model. They viewed their internet connection more as a media service than as a pipe for packets. Then along came consumerized NAT. Without even realizing how the internet had once worked, users started "sharing" their internet service among their own computers and eventually even further. They were building networks. Granted, there were a number of factors that made this all possible: the proliferation of personal computers, the simplification of configuration, even the success of wireless. Whatever the cause, this is now a commonly understood activity. The point of this long-winded story is that the genie is out of the bottle. It isn't a matter of a few aging nerds this time. The public (technical public perhaps, but becoming less and less so) knows the power of internetworking. They aren't going to give it up easily. We can embrace their requirement or we can try to turn back the clock. The latter will take more than telling the users that what they are doing is evil (the ISPs already tried that), and it will take more than a few NAT-hostile applications to block the NAT solution. I see three possible paths: -We do something to satisfy the users' requirements without making them resort to NAT, possibly upsetting providers who will need to adjust their business models. -We do nothing special and the market supplies IPv6 NAT. Things stay pretty much as they are. -We do something radical to prevent users from employing NAT-like solutions, possibly failing by succeeding if those users reject the protocol. |> |The trouble with networking has always been that even poorly |> |designed networks can work well so there is little incentive to do it |> |right. | |> I don't buy into the idea that users are not entitled to the |> functionality |> that they now enjoy just because it is somehow tainted by having once |> been |> provided by NAT. | |Well, there was a time when I had email without spam too. Sometimes |progress isn't progress. This is a rather strained analogy. :( |It is becoming quite apparent that having a |stable internal network and an ephemeral externally reachable network |provide seamless functionality can only be achieved using very dirty |hacks. It is not at all apparent to me. There are many ways to achieve that goal including PI space handled directly at the routing level, various forms of source routing including locator/identifier separation, and overlay networks. Now if you qualify your statement by saying that there are no politically acceptable approaches I might agree. Ditto if you say that there are no clean approaches that can be implemented by the end-user without our doing something to the protocol. But let's try to keep the genuinely technical limitations separate from the limitations necessary to accommodate current business models that assume that an end-user cannot acquire address space. |The internet supported address portability until 10 years |ago. This was a poor design because it doesn't scale, regardless of the |usefulness of the functionality. This is a common but confusing generalization. Portable address usage grows linearly in the actual number of users. It is very hard to do better than this without NAT-like hacks. Even those merely divide by a constant without changing the order of growth. On the other hand, hierarchical provider-based allocation consumes addresses exponentially in the number of provider levels, assuring that there will always be an address shortage at the lowest level(s). The confusion comes about because people used the scalability of "address portability" as a rather ambiguous shorthand to describe various problems in the current routing model. Initially it seemed to refer to the actual size (i.e., memory use) of the routing table in a full-knowledge system. Even this, though, grew only linearly with the number of addresses, so it took some fancy footwork to come with the desired "exponential growth" catch-phrase that was supposed to end all debate. As near as I can figure, the notion was that the usage of addresses was growing exponentially in *time* so the routing table was also. Increasing hardware capability has taken the wind out of the memory size argument, so the current fashion seems to be to consider the computational load of building the table in the first place, again constraining the process to work exactly as it does today. This is a harder problem to overcome by brute force, but it still has nothing to do with the scalability of portable addresses themselves. It just means that we can't necessarily support an arbitrary number of portable addresses *and* still constrain the routing process to work exactly as it does today. One obvious approach (if we did want to support portable addresses) is to return to a dumb network/smart host model and push the route computation to the edges of the network where the available resources grow with the consumers. Routers could go back to simply forwarding packets as fast as possible rather than spending lots of cycles enforcing economic policies by applying complicated filters to AS paths to determine whether this or that network really deserves transit service. Of course, this would require a change in provider business model because they would not have the fine-grained control currently used to leverage peering agreements. It looks like you snipped a question. Here it is in context: |> NAT was not as painful as it was supposed to be. |> For most users, NAT was empowering. Anyone--even an insignificant |> residential |> client--could hook up an entire network of their own. | |But this entire network only enjoys a subset of the capabilities of a |network connected without NAT. Your statement is extremely misleading, comparing apples and turnips. It is true that _a_ network connected without NAT enjoys a slightly larger set of capabilities (though they are capabilities that are not important to the typical NAT user) than the same network connected with NAT. But the residential client in question typically does not have the opportunity to connect _her_ network without NAT because her ISP provides only one dynamic IP address. The correct comparison, then, is between a NAT-connected network and a network that is not connected to the internet at all. Which one enjoys greater capability? Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 20 01:01:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00338 for ; Mon, 20 Oct 2003 01:01:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABSAT-00044p-BG for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 01:01:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9K51L0h015665 for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 01:01:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABSAT-00044a-5F for ipv6-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 01:01:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00307 for ; Mon, 20 Oct 2003 01:01:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABSAQ-0003z2-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 01:01:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABSAP-0003yz-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 01:01:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABSAA-0003sr-06; Mon, 20 Oct 2003 01:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABS9P-0003dz-N1 for ipv6@optimus.ietf.org; Mon, 20 Oct 2003 01:00:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00245 for ; Mon, 20 Oct 2003 01:00:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABS9M-0003yF-00 for ipv6@ietf.org; Mon, 20 Oct 2003 01:00:12 -0400 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1ABS9L-0003yC-00 for ipv6@ietf.org; Mon, 20 Oct 2003 01:00:12 -0400 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id BAA01053; Mon, 20 Oct 2003 01:00:09 -0400 (EDT) Date: Mon, 20 Oct 2003 01:00:09 -0400 (EDT) From: Dan Lanciani Message-Id: <200310200500.BAA01053@ss10.danlan.com> To: ipv6@ietf.org Subject: RE: IPv6 adoption behavior Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , "Bound, Jim" wrote: |As side note. Outside of the IETF a very coordinated and strong force |is stating NAT business view should not be propogated with IPv6 adoption |and NAT does not provide security and has a great cost. The alleged security feature of NAT makes for a very convenient (and easy to dispatch) straw man. NAT's true power for the consumer lies in its ability to support a flavor of internetworking where none was possible before. This capability will not be easily revoked... |That body/force |is the IPv6 Forum with Task Forces totally dedicated to the deployment |of IPv6 in almost every geography in the world. The IPv6 Forum and Task |Forces have the attention of Public Governments/Departments and Private |Enterprise. If we are successful, and I think we will be, the idea of |NAT for IPv6 adoption is dead. I've read about legislation that can be construed to ban NAT. I suppose you could try to get those "Public Governments/Departments" to step up some sort of enforcement effort (after all, the cell phone providers got the government to ban extensions), but short of that I don't see how you can stop the market from serving its customers. Even if you can succeed through legal means, I have to wonder why this is a good thing. Wouldn't it make more sense to offer functionality in the base protocol so that users don't feel a need for NAT? Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 20 04:51:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18158 for ; Mon, 20 Oct 2003 04:51:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABVkn-0005Sv-W3 for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 04:51:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9K8p5le021008 for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 04:51:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABVkn-0005Sl-Gk for ipv6-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 04:51:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18133 for ; Mon, 20 Oct 2003 04:50:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABVkk-0005rR-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 04:51:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABVkj-0005rO-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 04:51:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABVjm-00055i-Fe; Mon, 20 Oct 2003 04:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABVj0-0004qo-SU for ipv6@optimus.ietf.org; Mon, 20 Oct 2003 04:49:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18105 for ; Mon, 20 Oct 2003 04:49:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABVix-0005r8-00 for ipv6@ietf.org; Mon, 20 Oct 2003 04:49:11 -0400 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1ABViw-0005r5-00 for ipv6@ietf.org; Mon, 20 Oct 2003 04:49:10 -0400 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 8320D8313; Mon, 20 Oct 2003 10:49:07 +0200 (CEST) From: "Jeroen Massar" To: "'Dan Lanciani'" , Subject: RE: IPv6 adoption behavior Date: Mon, 20 Oct 2003 10:49:07 +0200 Organization: Unfix Message-ID: <003101c396e7$074e2740$210d640a@unfix.org> 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.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200310200423.AAA00548@ss10.danlan.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Dan Lanciani wrote: > I strongly doubt that IPv6 will be available as a > software-only upgrade for any but the latest equipment. There is just too little > incentive for vendors (especially ones who have gone out of business :) to > support "legacy" hardware (where "legacy" seems to mean over six months old). Endusers usually only have their OS's and some kind of access device. OS's (Windows, Linux, Solaris, *BSD) all have IPv6 support. As for the access devices this indeed differs as there are a couple of techniques to get the IPv6 to that enduser. Most of the access devices are too simple and are mostly NAT boxes nowadays which most people call 'routers' (ouch). These won't sport IPv6 quickly indeed but we have a number of transition mechanisms to overcome that problem fortunatly. As Jordi Palet's draft points out most of the NAT's can be configured per software to allow IPv6 over IPv4 tunnels, using Teredo we fix anything else. There is a reason btw why Microsoft invented Teredo, they where running into much too many barriers and hooks when wanting to deploy internet-worked gaming for both Xbox and Windows platforms where NAT's are the culprit as the hosts don't have global addressability which really really is the biggest problem of IPv4 because many ISP simply don't pass you more than one IP because that is their business plan and you have to give them much more money for those IP's. Basically that boils to: ISP's should sell bandwidth *NOT* IP space. They should ofcourse only route the IP's delegated to the enduser. And not anything else. > |Functionality won't disappear unless people turn off IPv4, which I > |don't expect them to do. > > Sure, but that's basically saying that IPv6 + IPv4+NAT can > replace IPv4+NAT, which isn't very interesting. :) It is perfectly interresting as I have been using this setup personally for almost the last 3 years now using a smoothly running IPv6 tunnel. It's very useful when having only 1 IPv4 address and a /48 IPv6 @ home allowing all the machines to really communicate with eachothers. With the advent of Netmeeting sporting IPv6 and various VoIP applications this will become very interresting as it solves all the NAT problems. > |(I even get strange looks from people in IPv6 > |circles when I say I want to run IPv6-only hosts for test purposes.) > > That's a rather telling response... One can do with 1 IPv4 address just like now: NAT it :) > Remember that the original assertion that I questioned was > that IPv6 could substitute for IPv4+NAT. I think we have > a long way to go before it can. IMHO it can when most applications are upgraded to use IPv6. When the gaming industry (Sony's Playstation, Microsoft's Xbox) pick up internetworked gaming this will lift off. > |But I think > |we can and should add all the missing stuff to IPv6. > > Naturally I agree, but it seems like one of the key features (address > independence) is a stumbling block. Then we really need to fix that. > I've been wondering that myself lately. Possibly IPv6 will > be useful in circumstances where the provider can control the user's > environment via restricted firmware, legal means, etc. There is no way to stop a user which you gave some method of reaching an outside server which is not under you control to tunnel anything through that connection including IPv6. > I understand that actual end-user requirements are not a > major consideration for IPv6 development. The enduser wants one thing: it needs to work(tm) > an individual networks his own computers and > connects that network to the internet as in the > pre-commercial model. Which won't scale as that would require to much routing information and administration in the RIR's. > -We do something to satisfy the users' requirements without > making them resort to NAT, possibly upsetting providers who > will need to adjust their business models. The typical enduser that plays games, does filesharing and communicates with others (MSN/ICQ/Jabber/...) requires global addressability to do these functions, they don't want NAT. But they don't complain because there is nothing else. > -We do something radical to prevent users from employing > NAT-like solutions, possibly failing by succeeding if those > users reject the protocol. You can't prevent this in any way, a user can do with their IP whatever they want and they will. You can disencourage them though just like ISP's threaten users to 'disconnect users who use their service with more than one computer' just if that ISP can see that you are using more than one with MSN :) > Your statement is extremely misleading, comparing apples and > turnips. It is true that _a_ network connected without NAT > enjoys a slightly larger > set of capabilities (though they are capabilities that are > not important to the typical NAT user) Let me put it this way: they want their mp3's (-> warez). Thus they need to do P2P as they know no other way. This requires a non-NATted IP. They want to game, which requires a client and a server. Of at least the server needs to be non-NATted. If 2 friends have NAT networks and usually they do nowadays they can't play their favourite expensive game together because they are stuck behind a NAT. > The correct comparison, then, is between a NAT-connected network > and a network that is not connected to the internet at all. > Which one enjoys greater capability? The NAT connected network with an IPv6 tunnel :) Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP5OhgymqKFIzPnwjEQJjYACeMLhdkXIJ0XjwA17R8HBbcPFYVpAAn0GR 3ROBVqHnCpVs1XJ2gaECaKJC =0s/D -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 20 09:35:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25817 for ; Mon, 20 Oct 2003 09:35:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABaC7-0004D3-Ld for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 09:35:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KDZZHM016175 for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 09:35:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABaC7-0004Co-G9 for ipv6-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 09:35:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25787 for ; Mon, 20 Oct 2003 09:35:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABaC5-0000GS-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 09:35:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABaC5-0000GP-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 09:35:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABaBa-00040e-7w; Mon, 20 Oct 2003 09:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABaAd-0003jG-8u for ipv6@optimus.ietf.org; Mon, 20 Oct 2003 09:34:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25670 for ; Mon, 20 Oct 2003 09:33:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABaAb-0000En-00 for ipv6@ietf.org; Mon, 20 Oct 2003 09:34:01 -0400 Received: from kirk.rvdp.org ([80.126.101.63]) by ietf-mx with esmtp (Exim 4.12) id 1ABaAa-0000Ee-00 for ipv6@ietf.org; Mon, 20 Oct 2003 09:34:00 -0400 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6p3/8.11.6) id h9KDXp028848; Mon, 20 Oct 2003 15:33:51 +0200 (CEST) Date: Mon, 20 Oct 2003 15:33:51 +0200 From: Ronald van der Pol To: Iljitsch van Beijnum Cc: ipv6@ietf.org Subject: Re: Raise the bar for v6? Message-ID: <20031020133351.GM20204@rvdp.org> References: <16987DC7-FE3C-11D7-B291-00039388672E@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16987DC7-FE3C-11D7-B291-00039388672E@muada.com> User-Agent: Mutt/1.4.1i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, Oct 14, 2003 at 13:46:46 +0200, Iljitsch van Beijnum wrote: > We still don't have any IPv6 root nameservers. I gather one of the > problems here is the limit on response message sizes for DNS queries. We did some measurements about this in an isolated test network. We concluded that the effects are negligible: http://www.nlnetlabs.nl/ipv6/publications/v6rootglue.pdf rvdp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 20 13:29:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04778 for ; Mon, 20 Oct 2003 13:29:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdqW-0002Iy-VO for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 13:29:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KHTWlm008859 for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 13:29:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdqW-0002Io-Qa for ipv6-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 13:29:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04742 for ; Mon, 20 Oct 2003 13:29:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdqU-0002aj-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 13:29:30 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABdqU-0002ag-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 13:29:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdq1-00024n-FS; Mon, 20 Oct 2003 13:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdp2-0001uJ-Mx for ipv6@optimus.ietf.org; Mon, 20 Oct 2003 13:28:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04704 for ; Mon, 20 Oct 2003 13:27:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdp0-0002Z6-00 for ipv6@ietf.org; Mon, 20 Oct 2003 13:27:58 -0400 Received: from h024.c001.snv.cp.net ([209.228.32.139] helo=c001.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 1ABdoz-0002Yr-00 for ipv6@ietf.org; Mon, 20 Oct 2003 13:27:57 -0400 Received: (cpmta 10924 invoked from network); 20 Oct 2003 10:27:56 -0700 Received: from 195.12.18.98 (HELO w2knerick) by smtp.register-admin.com (209.228.32.139) with SMTP; 20 Oct 2003 10:27:56 -0700 X-Sent: 20 Oct 2003 17:27:56 GMT Message-ID: <001a01c3972f$9fcec090$66c8a8c0@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: , , References: <9C422444DE99BC46B3AD3C6EAFC9711B047CA107@tayexc13.americas.cpqcorp.net> Subject: Re: Appeal to the IAB on the site-local issue Date: Mon, 20 Oct 2003 19:28:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Bound, Jim" One point I would like to make in regards to this item: > 3. Were the needs of the market considered in the decision? I don't > think by all but do we ever use this bar? As I said to you once when > you were on the IESG consistency is imperative. The market is > reprsented by our participants. If participants are not here to support > the IETF they do not get heard. We have no way to trust one or a few to > represent an entire market other than present their individual view. > That may or may not influence the WG, it depends on the respect the > individual has with their peers I guess? Setting aside personal opinion on this topic, I think that the WG vote process of the mailing list should have a much stronger deciding factor in making this type of decisions than the meetings. Not to understate the value of the meetings, but as they are spread over quite a geographic area, and many of us are not funded to attend too many of this type of event (especially those of us in industry). I would like to suggest a more standard voting is worked out. Possibly using a log of e-mail addresses (I know this does away with secret votes, but keeps them honest) and check off buttons. There are many sites that offer free voting (the ISOC uses them). Just my opinion, Eric -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 20 14:47:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07393 for ; Mon, 20 Oct 2003 14:47:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABf3E-0008Aw-DN for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 14:46:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KIkic2031423 for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 14:46:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABf3E-0008Ak-6P for ipv6-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 14:46:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07364 for ; Mon, 20 Oct 2003 14:46:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABf3B-0003Jo-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 14:46:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABf3B-0003Jl-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 14:46:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABf2Y-0007sx-CJ; Mon, 20 Oct 2003 14:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABf1Z-0007bj-St for ipv6@optimus.ietf.org; Mon, 20 Oct 2003 14:45:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07321 for ; Mon, 20 Oct 2003 14:44:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABf1X-0003IU-00 for ipv6@ietf.org; Mon, 20 Oct 2003 14:44:59 -0400 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by ietf-mx with esmtp (Exim 4.12) id 1ABf1W-0003Ho-00 for ipv6@ietf.org; Mon, 20 Oct 2003 14:44:58 -0400 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9KIiPfw037138 for ; Mon, 20 Oct 2003 20:44:25 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9KIiPTO261164 for ; Mon, 20 Oct 2003 20:44:25 +0200 Received: from zurich.ibm.com (sig-9-145-243-139.de.ibm.com [9.145.243.139]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id UAA46780 for ; Mon, 20 Oct 2003 20:44:23 +0200 Message-ID: <3F942CE9.71D9DCFF@zurich.ibm.com> Date: Mon, 20 Oct 2003 20:43:53 +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: ipv6@ietf.org Subject: Re: IPv6 adoption behavior References: <200310171934.PAA05878@ss10.danlan.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dan, Dan Lanciani wrote: ... > |> NAT was not as painful as it was supposed to be. > |> For most users, NAT was empowering. Anyone--even an insignificant > |> residential > |> client--could hook up an entire network of their own. > | > |But this entire network only enjoys a subset of the capabilities of a > |network connected without NAT. > > Your statement is extremely misleading, comparing apples and turnips. It > is true that _a_ network connected without NAT enjoys a slightly larger > set of capabilities (though they are capabilities that are not important > to the typical NAT user) than the same network connected with NAT. By definition, facilities unavailable to a NAT user are not important to a NAT user. What we are concerned about here is restoring the ability to innovate that NAT has destroyed. Nobody has an incentive today to develop innovative applications that don't work through domestic NATs. This is a tragedy. > But the > residential client in question typically does not have the opportunity to > connect _her_ network without NAT because her ISP provides only one dynamic > IP address. The correct comparison, then, is between a NAT-connected network > and a network that is not connected to the internet at all. No. That's like comparing a car with only reverse gear to a car with no engine. The correct comparison is between a car with only reverse gear to one that can also drive forwards. Which one enjoys greater capability? Now let's get back to how to resolve this with IPv6. Firstly, ISPs need to follow the IAB and RIR recommendations to assign /48s to subscribers. Then, the IETF (hey, this WG!) needs to approve draft-ietf-ipv6-unique-local-addr-01.txt or something very similar. Then, the equipment vendors need to make domestic and enterprise gateways and firewalls that handle IPv6 appropriately - supporting autoconfig and router renumbering, blackholing draft-ietf-ipv6-unique-local-addr addresses by default, supporting PA addresses in the normal way. Then O'Riley or someone needs to publish the necessary How-To book. Actually, whoever writes the book will find out what is still missing. Certainly, the ADSL router I bought recently for 99 Swiss francs will never be upgraded to support IPv6. But I'd like to think that when I buy a new one in ~3 years, it will have IPv6 out of the factory, as well as legacy IPv4-NAT. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 20 15:14:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12958 for ; Mon, 20 Oct 2003 15:14:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfTr-000069-LX for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 15:14:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KJEFNm000371 for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 15:14:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfTr-00005t-H3 for ipv6-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 15:14:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12770 for ; Mon, 20 Oct 2003 15:14:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABfTq-000456-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 15:14:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABfTp-000453-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 15:14:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfTd-0008QE-GN; Mon, 20 Oct 2003 15:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfSg-00080S-N9 for ipv6@optimus.ietf.org; Mon, 20 Oct 2003 15:13:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12391 for ; Mon, 20 Oct 2003 15:12:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABfSf-00041p-00 for ipv6@IETF.ORG; Mon, 20 Oct 2003 15:13:01 -0400 Received: from mms1.broadcom.com ([63.70.210.58]) by ietf-mx with esmtp (Exim 4.12) id 1ABfSe-00041i-00 for ipv6@IETF.ORG; Mon, 20 Oct 2003 15:13:00 -0400 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.5.3)); Mon, 20 Oct 2003 12:12:58 -0700 Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id MAA28188 for ; Mon, 20 Oct 2003 12:12:19 -0700 (PDT) Received: from pcir000997 (dhcpe1-sj1-094 [10.16.65.94]) by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with SMTP id h9KJClov000017 for ; Mon, 20 Oct 2003 12:12:47 -0700 ( PDT) From: "Guru Yeleswarapu" To: ipv6@ietf.org Subject: Link Local address : Basic question Date: Mon, 20 Oct 2003 12:17:19 -0700 Message-ID: <000e01c3973e$c7c2e130$5e41100a@pcir000997.sj.broadcom.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 In-Reply-To: X-WSS-ID: 138AEC301122964-01-01 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C39704.1B640930" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C39704.1B640930 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit unsubscribeHi, Iam new to IPv6 routing. I have been reading RFC's to understand different aspects of IPV6. I have following questions. I appreciate any replies. [1] Link-Local address: Many RFc's (3513) says clearly that link-local addresses should not be routed by a router. But link-local addresses used in 6 over 4 tunnels use link-local addresses, my question is : if router is end point of the tunnel, ca router do routing using the inner IPv6 header? [2] From my understanding duplicate interfaceId's are allowed between subnet-prefixes. How does station movements handled in that scenario? Thanks ------=_NextPart_000_000F_01C39704.1B640930 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable unsubscribe
Hi,
Iam=20 new to IPv6 routing. I have been reading RFC's to understand different = aspects=20 of IPV6.
I have=20 following questions. I appreciate any replies.
 
[1]=20 Link-Local address: Many RFc's (3513) says clearly that link-local = addresses=20 should
    not be routed by a router. But link-local = addresses=20 used in 6 over 4 tunnels use link-local
    addresses, my question is : if router is end = point of=20 the tunnel, ca router do routing using the inner = IPv6
    header?
 
[2]=20 From my understanding duplicate interfaceId's are allowed between=20 subnet-prefixes. How does station
movements handled in that scenario?
 
 
Thanks
 
------=_NextPart_000_000F_01C39704.1B640930-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 20 15:25:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16243 for ; Mon, 20 Oct 2003 15:25:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfeZ-0003OA-66 for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 15:25:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KJPJDM013026 for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 15:25:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfeY-0003O1-HP for ipv6-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 15:25:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16098 for ; Mon, 20 Oct 2003 15:25:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABfeX-0004Zq-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 15:25:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABfeW-0004Zn-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 15:25:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfeI-0003Cg-KC; Mon, 20 Oct 2003 15:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfdO-000347-9W for ipv6@optimus.ietf.org; Mon, 20 Oct 2003 15:24:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15810 for ; Mon, 20 Oct 2003 15:23:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABfdM-0004XB-00 for ipv6@ietf.org; Mon, 20 Oct 2003 15:24:04 -0400 Received: from alicia.nttmcl.com ([216.69.69.10]) by ietf-mx with esmtp (Exim 4.12) id 1ABfdL-0004Vg-00 for ipv6@ietf.org; Mon, 20 Oct 2003 15:24:04 -0400 Received: from nttmcl.com (daal.nttmcl.com [216.69.69.11]) by alicia.nttmcl.com (8.12.9/8.12.5) with ESMTP id h9KJNQHB075005 for ; Mon, 20 Oct 2003 12:23:26 -0700 (PDT) (envelope-from gene@nttmcl.com) Message-ID: <3F94360E.8030709@nttmcl.com> Date: Mon, 20 Oct 2003 12:22:54 -0700 From: "Eugene M. Kim" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en, ko-kr, ko MIME-Version: 1.0 To: IETF IPv6 Working Group Subject: Re: IPv6 adoption behavior References: <003101c396e7$074e2740$210d640a@unfix.org> In-Reply-To: <003101c396e7$074e2740$210d640a@unfix.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm afraid this whole series of argument is somewhat misled. Pardon me if the whole IPv6 landscape has changed while I was asleep, but I always thought that the main goal of IPv6 is not to replace IPv4, IPv4+NAT, or anything that stands well-established today. There are some holes that the current IPv4 with NAT can't reasonably plug in a sound manner; as Jeroen pointed out, it could be PC/Xbox/PS2 games, NetMeeting, or heaven forbid, P2P warez (I don't want IPv6 to be flagged as a pirate ship by the government =p). IPv4+NAT can work around this, but only with dirty hacks. And in many cases these hacks are not 100% complete either. If some of you want to say those limitations are not really important to most NAT users, just talk to anyone who played StartCraft behind her NAT box and got frustrated how she and her boyfriend can't play online at the same time because only one machine behind the NAT box can connect to the Blizzard's game server. Just in case you didn't know, StarCraft is still quite popular among kids and teens (it's even an official event in an international gaming competition; see www.worldcybergames.com), so I guess it's a bit hard to say it's not important to most NAT users. *grin* Anyhow, I think that these niche markets are the number one target of IPv6. And one day, with people realizing what P2P is and how they actually need it (from their own practical point of view of course; see above), the niche markets won't be niche markets anymore. Yes, it would be also good if IPv6 could `replace' IPv4+NAT one day. But it'd be like putting the cart before the horse to say IPv6 doesn't have much chance because it can't replace IPv4+NAT easily. Because that is not the only purpose of IPv6. I mean, if that replacement actually happens, good. If it doesn't happen, who cares? IPv6 will have its own market anyways. No need to stir up the trouble by shouting `Hey folks, you're all doomed in a sinking ship, whose name is IPv4!' That said, what actually bothers me is the classic chicken-and-egg problem. Application writers are reluctant to add IPv6 support because they know that there is little to none of IPv6 infrastructure (read: ISPs supporting IPv6) out there. ISPs, on the other hand, are reluctant to do IPv6 business because they know that there are few to none of IPv6-ready applications out there. Two-way secret crush. I guess what we need to focus on is how to become a messenger of love. =) Cheers, Eugene -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 20 16:21:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02052 for ; Mon, 20 Oct 2003 16:21:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABgWd-0001BZ-7e for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 16:21:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KKLBgS004557 for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 16:21:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABgWb-0001BO-Kn for ipv6-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 16:21:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01914 for ; Mon, 20 Oct 2003 16:20:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABgWZ-0007Gi-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 16:21:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABgWZ-0007Ge-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 16:21:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABgVZ-0000q9-Gq; Mon, 20 Oct 2003 16:20:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABgUm-0000fZ-4S for ipv6@optimus.ietf.org; Mon, 20 Oct 2003 16:19:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01358 for ; Mon, 20 Oct 2003 16:19:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABgUk-0007Ac-00 for ipv6@ietf.org; Mon, 20 Oct 2003 16:19:14 -0400 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1ABgUi-0007AS-00 for ipv6@ietf.org; Mon, 20 Oct 2003 16:19:13 -0400 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id QAA08845; Mon, 20 Oct 2003 16:19:09 -0400 (EDT) Date: Mon, 20 Oct 2003 16:19:09 -0400 (EDT) From: Dan Lanciani Message-Id: <200310202019.QAA08845@ss10.danlan.com> To: ipv6@ietf.org Subject: RE: IPv6 adoption behavior Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , "Jeroen Massar" wrote: |There is a reason btw why Microsoft invented Teredo, they where |running into much too many barriers and hooks when wanting to |deploy internet-worked gaming for both Xbox and Windows platforms |where NAT's are the culprit as the hosts don't have global |addressability which really really is the biggest problem of IPv4 |because many ISP simply don't pass you more than one IP because |that is their business plan and you have to give them much more |money for those IP's. Exactly. It isn't NAT but the address limitation that causes the problem. |Basically that boils to: | |ISP's should sell bandwidth *NOT* IP space. Sure. I've been saying that for years. IMHO it is one of the great tragedies of IPv6 that we failed to separate allocation of addresses from provision of bandwidth. As long as one entity controls both for a given customer they will make the addresses part of the price model. |> |Functionality won't disappear unless people turn off IPv4, which I |> |don't expect them to do. |> |> Sure, but that's basically saying that IPv6 + IPv4+NAT can |> replace IPv4+NAT, which isn't very interesting. :) | |It is perfectly interresting as [...] Again, it is not very interesting for the purposes of determining whether IPv6 can _replace_ IPv4+NAT as suggested. |> I've been wondering that myself lately. Possibly IPv6 will |> be useful in circumstances where the provider can control the user's |> environment via restricted firmware, legal means, etc. | |There is no way to stop a user which you gave some method of |reaching an outside server which is not under you control |to tunnel anything through that connection including IPv6. Sure there is if the user has no access to the *local* end which is embedded in the tamper-resistant firmware of a smart phone. My point was that this is a context where you can force the user to pay per address since he cannot install NAT within the phone. |> I understand that actual end-user requirements are not a |> major consideration for IPv6 development. | |The enduser wants one thing: it needs to work(tm) The end-user has tasted the power of internetworking. I don't think you will make him forget that easily. But then I may be wrong. It is said that nobody ever lost money underestimating the intelligence of the consumer. Or something like that. |> an individual networks his own computers and |> connects that network to the internet as in the |> pre-commercial model. | |Which won't scale as that would require to much routing |information and administration in the RIR's. This is just another variation of the "PI doesn't scale" argument. The administration angle is kind of funny, though. Isn't it amazing how the registries manage to "administer" as many domain names as anybody cares to pay for? I guess it's much harder to keep a list of numbers than to keep a list of names... |> Your statement is extremely misleading, comparing apples and |> turnips. It is true that _a_ network connected without NAT |> enjoys a slightly larger |> set of capabilities (though they are capabilities that are |> not important to the typical NAT user) | |Let me put it this way: they want their mp3's (-> warez). |Thus they need to do P2P as they know no other way. |This requires a non-NATted IP. Of course, that's not quite true. People keep trying to project onto NAT the problems caused by the provider's limitation of a single IP address. Think of NAT as spreading out the capabilities of the single supplied public address among several machines. If your single public address was capable of running your P2P application then likely NAT will let you run that same application on one machine behind the translator. The fact that you can't run the application on *all* the machines behind the translator is not the fault of NAT, it's the fault of your provider for giving you only one public address. NAT cannot magically create unique public addresses out of the ether, but neither does it destroy in a wholesale manner the functionality of the one you have. Yet because of the complicated and incredibly ugly *mechanics* of NAT it is bound to screw up something and/or require painful manual configuration to get a particular application to work behind the translator. On the other hand, it is a testament to how well NAT approximates a routed network connection that people start blaming it for things that are completely beyond its control. |> The correct comparison, then, is between a NAT-connected network |> and a network that is not connected to the internet at all. |> Which one enjoys greater capability? | |The NAT connected network with an IPv6 tunnel :) I agree that that is even better: (NAT connected network with IPv6 tunnel) > (NAT connected network) > (unconnected network) However, I suspect that you will find that if/when IPv6 access becomes valuable to the typical customer, your tunnel broker will start charging you for addresses just as your local ISP would. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 20 16:37:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03510 for ; Mon, 20 Oct 2003 16:37:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABgmF-0004hS-Hn for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 16:37:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KKbJKe018060 for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 16:37:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABgmF-0004hD-8w for ipv6-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 16:37:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03437 for ; Mon, 20 Oct 2003 16:37:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABgmD-0007kC-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 16:37:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABgmC-0007k9-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 16:37:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABglx-0004WG-F7; Mon, 20 Oct 2003 16:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABglR-0004R5-3B for ipv6@optimus.ietf.org; Mon, 20 Oct 2003 16:36:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03357 for ; Mon, 20 Oct 2003 16:36:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABglP-0007iB-00 for ipv6@ietf.org; Mon, 20 Oct 2003 16:36:27 -0400 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1ABglN-0007i8-00 for ipv6@ietf.org; Mon, 20 Oct 2003 16:36:26 -0400 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id QAA09213; Mon, 20 Oct 2003 16:36:22 -0400 (EDT) Date: Mon, 20 Oct 2003 16:36:22 -0400 (EDT) From: Dan Lanciani Message-Id: <200310202036.QAA09213@ss10.danlan.com> To: ipv6@ietf.org Subject: Re: IPv6 adoption behavior Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , "Eugene M. Kim" wrote: |I'm afraid this whole series of argument is somewhat misled. Pardon me |if the whole IPv6 landscape has changed while I was asleep, but I always |thought that the main goal of IPv6 is not to replace IPv4, IPv4+NAT, or |anything that stands well-established today. I've sort of lost track of the main goal of IPv6; what is it? This particular thread was about whether it _can_ replace IPv4+NAT, which clearly it can't given its current capabilities. As you point out, this may be of no import whatsoever since IPv6 isn't going to replace IPv4+NAT... |If some of you want to say those limitations are not really important to |most NAT users, just talk to anyone who played StartCraft behind her NAT |box and got frustrated how she and her boyfriend can't play online at |the same time because only one machine behind the NAT box can connect to |the Blizzard's game server. But this is not a limitation created by NAT! The problem comes about simply because the ISP is providing only a single public address for NAT to work with. If the ISP provided two public addresses then two people on two machines could play at once with or without NAT. When the ISP provides only a single address then only one user can play, with *or without* NAT. As I mentioned before, it is a testament to just how well NAT simulates a routed network that people start blaming it for external restrictions that it could not possibly work around. |No need to stir up the trouble by shouting `Hey folks, |you're all doomed in a sinking ship, whose name is IPv4!' Suits me... Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 20 19:35:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14459 for ; Mon, 20 Oct 2003 19:35:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABjYS-0006cD-Na for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 19:35:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KNZG1l025428 for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 19:35:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABjYS-0006c3-Gd for ipv6-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 19:35:16 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14416 for ; Mon, 20 Oct 2003 19:35:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABjXF-0006CZ-LZ; Mon, 20 Oct 2003 19:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABjWS-00063t-DK for ipv6@optimus.ietf.org; Mon, 20 Oct 2003 19:33:13 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14242 for ; Mon, 20 Oct 2003 19:33:00 -0400 (EDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9KNWPE30830; Mon, 20 Oct 2003 16:32:25 -0700 X-mProtect: <200310202332> Nokia Silicon Valley Messaging Protection Received: from walnut2.iprg.nokia.com (205.226.9.199, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpd8IxBVS; Mon, 20 Oct 2003 16:32:23 PDT Message-Id: <4.3.2.7.2.20031020162811.03689a10@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Oct 2003 16:32:00 -0700 To: ipv6@ietf.org From: Bob Hinden Subject: Re: Response to IESG comments on draft-ietf-ipv6-flow-label-07.txt Cc: Thomas Narten , margaret.wasserman@nokia.com, Brian E Carpenter Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , The chairs believe this email resolves the issues described in the IESG comments. We request that the authors submit an updated draft as outlined in the email. We think this should resolve the IESG comments and allow the document to move forward. Bob Hinden and Brian Haberman IPv6 Chairs At 05:46 AM 10/14/2003, Brian E Carpenter wrote: >The IESG comments on this document are at >https://www.ietf.org/IESG/EVALUATIONS/draft-ietf-ipv6-flow-label.bal > >It's taken a while for the authors to discover them, but here are our >responses. We'd like the WG's reactions over the next few days, so that >we can update the draft appropriately. > > > Ted Hardie (Discuss - August 7, 2003 teleconference Ted > > reclassified this to a COMMENT): > > This is very mild, and I could be talked out of it on the call, > > but I do find it odd that the key motivational text is in > > section 5.1, in the security requirements. This is the > > text I mean: > > > > > > The goal of the Flow Label is to allow different levels of > service to > > be provided for traffic streams on a common network > infrastructure. A > > variety of techniques may be used to achieve this, but the end > result > > will be that some packets receive different (e.g., better or worse) > > service than others. The mapping of network traffic to the flow- > > specific treatment is triggered by the IP addresses and Flow Label > > value of the IPv6 header, > > > > This looks to me like it belongs in the introduction, so that the reader > > can understand the impetus to the work. > >We think this is correct. Either this duplicates the introduction, or it >belongs in the introduction. In any case, it doesn't belong in the security >section. > > > > > As a side note, I have some concerns about whether any protocol can > > meet the explicit requirements in Section 4 and the implicit requirement > > of "do some good" without running into the maw of some well-known > > dragons, but the statement of requirements looks fair to me. > >We think that unspecified dragons are not useful to mention. In any case, >they should be discussed in specific use case drafts, not here. See below >for more comments on use cases. > > > > Alex Zinin (Discuss): > > > > This document talks about per-flow state establishment and > > processing on interim nodes. This is essentially IntServ > > and it doesn't scale well. > >Not true. The notion of "flow" used here is more general than >in intserv (or NSIS), although the default case of a flow is a single >transport connection. When specific use cases for the flow label are >written up, their individual scaling properties must indeed be documented. > > > > > More comments from rtg-dir (Ross) below. > > > > General Comments > > > > It seems to me that the flow label has a purpose, and two possible > > uses. To me the document seems to be not totally clear or perhaps > > even wrong regarding which of the uses is the main one. > > > > The purpose is to identify flows. For example, this allows the flow to > > be identified using only fields which are in fixed positions in the > > IPv6 Header. This purpose seems to me to be well defined in the > > document. > >That is deliberate. The idea of the draft is to tell IPv6 implementors >(both hosts and router) what is the minimum set of functionality they >MUST or SHOULD implement to enable use of the flow label. The draft >doesn't purport to define specific use cases with their various >detailed considerations. In fact, Ross's comment shows that we have done >what we intended in the draft. Perhaps we need a more explicit statement >about this in the introduction. > > > > > Now that you have an indicator regarding what flow a particular packet > > belongs to, what use would you have for this information? > > > > One possible use is for hashing packets, for example to spread traffic > > across equal cost multi-paths without re-ordering packets from any one > > flow. This seems like a pretty straightforward and sensible use, which > > requires close to zero change to the Internet architecture, and which > > is briefly mentioned in the document. > > > > The other possible use is for an explicit flow set up procedure. > > However, since the flow are per-{source-address; destination-address; > > flow field} triplet, it would seem that this won't scale much better > > than the current int-serve specification. Thus it is not clear whether > > this will end up being useful in practice. At best I would call this > > experimental. > > >We can think immediately of at least two other uses - as an e2e label for a >whole class of traffic (coarse grain aggregation), and [this is new from >recent >debate inside the multi6 design team] as an e2e label for a multihoming >session. > > > > > In some places in the document it appears that the flow field is for > > the purpose of identifying flows, and that either of the two uses > > might be sensible reasons that you might want to identify flows. > >Yes. Exactly. > > > In > > other places in the document it looks like the second purpose (which > > to me seems the more speculative) is the reason for the flow field. > >It might be. > > > > I think that it would make sense to clearly separate these. > >What needs to be clearly stated is that specific applications of the >flow label need to be / will be documented in specific use case >documents. We're not sure that there is anything else we can do in the >present draft. Ross's comment is a bit too general to generate specific >text changes. > > > More specific comments > > >> Section 1: > > > > First three paragraphs do a good job of defining the purpose of the > > flow ID (to allow efficient flow classification based only on fields in > > the fixed part of the IPv6 header). > > > > Fourth paragraph, first sentence: > > The minimum level of IPv6 flow support consists > > of labeling the flows. > > > > In a sense this is reasonable, but I am not sure precisely what it > > means. > > Does this mean: > > > > In order to be an IPv6 conformant node, IPv6 source > > nodes MUST be able to label outgoing flows. > > > > or does this mean: > > > > In order to claim conformance to the IPv6 flow > > label specification, IPv6 source nodes MUST support > > labeling outgoing flows. > > > > Or does this mean something else? > >The second one. We can clarify this. > > > > > >> Sections 2 and 3. > > > > This seems reasonable, and again defines the purpose of the > > flow label in a reasonable way, as well as defining some very > > reasonable requirements, for example specifying how a source > > should set the flow value. > > > > >> Proposed New Section Between section 3 and 4: > > > > It seems to me that the most obviously worthwhile of the > > potential uses of the flow label field is to allow routers to split > > traffic on multiple paths (for example, for load sharing and traffic > > engineering purposes), without having to look past the IPv6 > > header. > >Thus speaks a routing person... > > > > > One example of where this might be very useful is in the case > > of encapsulation, for example over IPsec over IPv6 > > or over GRE over IPv6 encapsulations. In this case > > there might be a potentially very large number of high layer flows > > which will be encapsulated with the same IPv6 source and > > destination addresses in the outer IPv6 header. If you can hash > > only on the outer IPv6 addresses, then you could get a lot of > > traffic which is forced to take the same path. If you allow a finer > > grain flow label to be placed in the flow label field, then you can > > get a much more even distribution of traffic across, for example, > > equal cost multi-paths. > >Indeed. This is one of the use cases that needs to be written up >in its own document. Not squeezed in here. > > > I think that it is worth having a section on this possibility. I don't > > think that this requires all that much text. > > > > There is one question which I have, which could be cleared up > > in such a section: Specifically, the second sentence of section > > 2 states: > > > > A Flow Label of zero is used to indicate packets > > not part of any flow. > > > > Suppose that I am an IPv6 router which is hashing on source > > address, destination address, and flow label, and I am using > > the hash to split traffic among several paths. > > > > If I see a packet with a flow label of zero, which of the following do > > I assume: > > > > - the node does not implement any flow labelling > ability, and > > therefore I must hash only on source and destination > > address. > > > > - the node does implement flow labelling, and is > telling me > > that the packet is not part of any flow, and can > therefore > > be > > forwarded on any path without regard for re-ordering. > > > > If we assume the latter, then implementation of the flow labelling > > capability must be supported by all IPv6 source nodes (at least > > to the point of sticking a non-zero value in the flow field), since > > otherwise their packets might be re-ordered by nodes which > > assume that their packets are not part of any flow. > >The use of the flow label doesn't affect the desired reordering semantics >of the >Internet, which remain "well, try not to reorder." So the functional >difference >between the two interpretations is small. In other words we don't intend a >zero flow >label to be a license to reorder. In fact we can't see any harm done by >including a >zero flow label in the hash - this will just be the default flow for a given >srce/dest pair. So what? There's no presumption that each flow has a >similar amount of traffic, anyway. > >We should perhaps add an explicit statement that a zero flow label does not >imply that significant reordering is acceptable. > > > > > I would suggest using zero to indicate that flow labelling is not > > supported (and thus routers better keep the packets in order > > based only on source and destination addresses). If we also > > want to indicate that some packets are not part of a flow, we > > might give them a random value, or a different special value. > >Well, we just don't see a major semantic difference between "I don't >label flows" and "I decided not to label this packet". Both >require default treatment. > > > > >> Section 4: > > > > The flow state establishment requirements in section 4 seem to be > > very much incomplete. If there were a complete set of flow state > > establishment requirements, then I think that the requirements > > specified in this section are reasonable ones, and would be > > included in the set. However, the two requirements specified in > > section 4 seem to be such a small subset of the complete set of > > requirements that I don't see why it is worth listing them at all. I > > think that it would be cleaner just to say that methods and > > requirements for explicit flow establishment are outside of the > > scope of this document. > >No, these are a consensus view of the minimal requirements that all >nodes must satisfy in order to allow co-existence of various different >flow label use cases in the Internet. The individual use cases will >add their own requirements. The WG wanted us to reduce the detail here >to the vital minimum, and that's what we did. > > > > > Naturally if section 4 were removed, then the last phrase of the > > first paragraph of the abstract would also need to be removed > > (page 1, phrase "and the requirements for flow state establishment > > methods"). Similarly the second to last paragraph of section 1 > > would need to be abbreviated. > > > > >>Section 5: > > > > First paragraph, last sentence: > > > > Even if the flow label were encrypted, its presence > > as a constant value in a fixed position might assist > > traffic analysis and cryptoanalysis. > > > > The flow label is supposed to be unstructured -- in the sense that if > > I am not the source node, then I don't know anything about how the > > source set the label, except that a different value means a different > > flow. As such, I don't understand what encryption would do to change > > the interpretation of a flow label. If two labels were encrypted to > > the same exact value, then it would seem clear that they can't be > > un-encrypted back to different values. If two flow labels were > > encrypted to different values, then as a node in the middle observing > > the packets going by I don't detect any difference. > >That's not the point. There have been a few famous crypto breaks in history >due to fixed patterns occurring in the plaintext. The flow label increases >the number of fixed (non-zero) bits in the packet header, and that is >presumably still a cryptographic risk factor as it was in WW 2. > > > > > Section 5.1, second paragraph (top of page 5), first sentence: > > > > Note that there is no guarantee that flow labels sent > by a node are > > not set in any manner that the node wants to, such as > reusing flow > > labels, against the recommendations in this document. > > > > This seems to be a rather awkward sentence, and should probably > > be re-written. > >OK > > > > Additional Topic: Somewhere in the security section (probably in a new > > subsection at the end) it might be worth mentioning that in those > > locations where a firewall or filtering router is employed which looks > > past the IP header to higher level headers, the flow label does > > nothing to eliminate the need to continue to look at the higher > > headers. > >OK > > > > > Ross > > > > Jon Peterson (Discuss): > > > > Along the same lines as the comments from the Routing Area Directorate, but > > with a few different issues in the text: > > > > I believe there are two purposes of flows given in the document - first, a > > flow as a way of flagging a stream of related traffic coming from a node > > (following Section 3, first paragraph), and second, a flow as something > that > > would be prioritized by routers (following Section 5.1, first paragraph). > > There are a couple of ways in which the two seem to get mixed up. > > > > 1) In the last paragraph of 5.1, it suggests that a policy decision in the > > source node should be made to determine whether or not an application or > > transport protocol is allowed to use a non-zero Flow Label. But > reading, for > > example, the first paragraph of Section 3, the document suggests that "each > > unrelated transport connection and application data stream" on a node > should > > be assigned to a new flow (which presumably means that they would have a > > non-zero Flow Label). > >Yes, the policy can override the SHOULD. That could be clarified. > > > > > 2) Section 3, second paragraph, says: > > > > To enable applications and transport protocols to define what packets > > constitute a flow, the source node MUST provide means for the > > applications and transport protocols to specify the Flow Label values > > to be used with their flows. > > > > Given that there is some sort of policy decision associated with the > > assignment of flows, I don't think applications and transport protocols > > could really get to 'specify' these Flow Labels. > >Why not? Consider a use case where we use the flow label at "traffic type" >granularity. A video codec application might want to use different flow labels >for different levels of video encoding. It's not for the IPv6 WG to prevent >that. > > > It also isn't clear how > > collisions would be managed (Section 3, third paragraph) if it were > possible > > for any multiple applications on the same host to specify Flow Label > values. > >We deleted a whole lot of implementation recommendations in this area, at the >WG's request. It's entirely algorithmic but it takes you into API and local >state areas that are out of place in a protocol spec. The IP stack has to >cache all flow labels in current use, and whether collisions are allowed or >disallowed is again a use case issue - you might want to use the same >coarse flow label for the audio part of video flows and for VoIP - or you >might not, depending on how you've chosen to use the flow label. Again, >it isn't for the IPv6 WG to legislate on this. > > Brian > > >-- >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >Brian E Carpenter >Distinguished Engineer, Internet Standards & Technology, IBM > >NEW ADDRESS PLEASE UPDATE ADDRESS BOOK > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 20 20:28:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15766 for ; Mon, 20 Oct 2003 20:28:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABkNi-0007WI-Bn for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 20:28:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L0SEdi028900 for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 20:28:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABkNi-0007W3-0x for ipv6-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 20:28:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15741 for ; Mon, 20 Oct 2003 20:28:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABkNf-0004Lc-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 20:28:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABkNf-0004LZ-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 20:28:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABkNW-0007Mg-2p; Mon, 20 Oct 2003 20:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABkNU-0007M8-3H for ipv6@optimus.ietf.org; Mon, 20 Oct 2003 20:28:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15736 for ; Mon, 20 Oct 2003 20:27:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABkNR-0004LN-00 for ipv6@ietf.org; Mon, 20 Oct 2003 20:27:57 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1ABkNR-0004Kp-00 for ipv6@ietf.org; Mon, 20 Oct 2003 20:27:57 -0400 Subject: RE: IPv6 adoption behavior Date: Mon, 20 Oct 2003 17:27:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: IPv6 adoption behavior Thread-Index: AcOXQIuimoe4OV1iSUeQMHPPi7HUJAAKTukg From: "Michel Py" To: "Eugene M. Kim" , "IETF IPv6 Working Group" Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Eugene M. Kim wrote: > That said, what actually bothers me is the classic chicken-and-egg > problem. Application writers are reluctant to add IPv6 support > because they know that there is little to none of IPv6 infrastructure > (read: ISPs supporting IPv6) out there. ISPs, on the other hand, > are reluctant to do IPv6 business because they know that there are > few to none of IPv6-ready applications out there. Two-way secret > crush. I guess what we need to focus on is how to become a messenger > of love. =3D) This analysis is flawed. App developers have little influence over deployment and so do ISPs. The market (read, consumer and enterprises) decides if a protocol is successful. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 20 20:52:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16485 for ; Mon, 20 Oct 2003 20:52:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABkl9-0007A2-HB for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 20:52:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L0qRg8027526 for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 20:52:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABkl9-00079t-9I for ipv6-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 20:52:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16423 for ; Mon, 20 Oct 2003 20:52:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABkl6-0004l8-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 20:52:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABkl6-0004l5-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 20:52:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABkkl-0006wz-Cc; Mon, 20 Oct 2003 20:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABkkN-0006kK-A9 for ipv6@optimus.ietf.org; Mon, 20 Oct 2003 20:51:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16381 for ; Mon, 20 Oct 2003 20:51:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABkkK-0004jg-00 for ipv6@ietf.org; Mon, 20 Oct 2003 20:51:36 -0400 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1ABkkK-0004jc-00 for ipv6@ietf.org; Mon, 20 Oct 2003 20:51:36 -0400 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 20 Oct 2003 17:51:06 -0700 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 20 Oct 2003 17:51:06 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 20 Oct 2003 17:51:06 -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(6.0.3790.1069); Mon, 20 Oct 2003 17:51:04 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 20 Oct 2003 17:51:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 adoption behavior Date: Mon, 20 Oct 2003 17:51:02 -0700 Message-ID: Thread-Topic: IPv6 adoption behavior thread-index: AcOXQIuimoe4OV1iSUeQMHPPi7HUJAAKTukgAADVR5A= From: "Christian Huitema" To: "Michel Py" , "Eugene M. Kim" , "IETF IPv6 Working Group" X-OriginalArrivalTime: 21 Oct 2003 00:51:05.0131 (UTC) FILETIME=[6829DFB0:01C3976D] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > That said, what actually bothers me is the classic chicken-and-egg > > problem. Application writers are reluctant to add IPv6 support > > because they know that there is little to none of IPv6 infrastructure > > (read: ISPs supporting IPv6) out there. ISPs, on the other hand, > > are reluctant to do IPv6 business because they know that there are > > few to none of IPv6-ready applications out there. Two-way secret > > crush. I guess what we need to focus on is how to become a messenger > > of love. =3D) >=20 > This analysis is flawed. App developers have little influence over > deployment and so do ISPs. The market (read, consumer and enterprises) > decides if a protocol is successful. The Teredo design is predicated on the idea that we can ship IPv6 as a software upgrade on the PC. The update can be enabled as part of an application development. That is actually quite powerful, and does break the chicken-and-egg problem. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 20 21:12:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16983 for ; Mon, 20 Oct 2003 21:12:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABl4U-000592-Ki for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 21:12:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L1CQTp019770 for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 21:12:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABl4U-00058n-Eo for ipv6-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 21:12:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16953 for ; Mon, 20 Oct 2003 21:12:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABl4R-0004x1-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 21:12:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABl4R-0004wy-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 21:12:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABl46-0004u2-Iu; Mon, 20 Oct 2003 21:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABl3O-0004Ye-04 for ipv6@optimus.ietf.org; Mon, 20 Oct 2003 21:11:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16943 for ; Mon, 20 Oct 2003 21:11:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABl3L-0004wq-00 for ipv6@ietf.org; Mon, 20 Oct 2003 21:11:15 -0400 Received: from alicia.nttmcl.com ([216.69.69.10]) by ietf-mx with esmtp (Exim 4.12) id 1ABl3K-0004wh-00 for ipv6@ietf.org; Mon, 20 Oct 2003 21:11:14 -0400 Received: from nttmcl.com (daal.nttmcl.com [216.69.69.11]) by alicia.nttmcl.com (8.12.9/8.12.5) with ESMTP id h9L12AHB083488; Mon, 20 Oct 2003 18:02:10 -0700 (PDT) (envelope-from gene@nttmcl.com) Message-ID: <3F948565.8090201@nttmcl.com> Date: Mon, 20 Oct 2003 18:01:25 -0700 From: "Eugene M. Kim" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en, ko-kr, ko MIME-Version: 1.0 To: Michel Py CC: IETF IPv6 Working Group Subject: Re: IPv6 adoption behavior References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Michel Py wrote: >>Eugene M. Kim wrote: >>That said, what actually bothers me is the classic chicken-and-egg >>problem. Application writers are reluctant to add IPv6 support >>because they know that there is little to none of IPv6 infrastructure >>(read: ISPs supporting IPv6) out there. ISPs, on the other hand, >>are reluctant to do IPv6 business because they know that there are >>few to none of IPv6-ready applications out there. Two-way secret >>crush. I guess what we need to focus on is how to become a messenger >>of love. =) >> >> > >This analysis is flawed. App developers have little influence over >deployment and so do ISPs. The market (read, consumer and enterprises) >decides if a protocol is successful. > > No. What customers want is to have their needs fulfilled (e.g. to be able to play StarCraft online at a LAN party at their houses). As long as they get what they want, they are less concerned about what technology application developers and ISPs have used to implement it. Thus, the ball is back on application developers and ISPs' side. What the market decides is successful or not is simply a business item offered to them. They don't have to, and in many cases they are not even willing to, decide whether specific parts used in that business item are successful or not. Regards, Eugene -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 20 21:17:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17202 for ; Mon, 20 Oct 2003 21:17:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABl91-0006u3-RT for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 21:17:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L1H754026535 for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 21:17:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABl91-0006tu-G5 for ipv6-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 21:17:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17153 for ; Mon, 20 Oct 2003 21:16:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABl8y-00050V-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 21:17:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABl8y-00050S-00 for ipv6-web-archive@ietf.org; Mon, 20 Oct 2003 21:17:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABl8v-0006kg-Hv; Mon, 20 Oct 2003 21:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABl8X-0006gh-G7 for ipv6@optimus.ietf.org; Mon, 20 Oct 2003 21:16:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17136 for ; Mon, 20 Oct 2003 21:16:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABl8U-00050D-00 for ipv6@ietf.org; Mon, 20 Oct 2003 21:16:34 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1ABl8U-0004zx-00 for ipv6@ietf.org; Mon, 20 Oct 2003 21:16:34 -0400 Subject: RE: IPv6 adoption behavior Date: Mon, 20 Oct 2003 18:16:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: IPv6 adoption behavior Thread-Index: AcOXQIuimoe4OV1iSUeQMHPPi7HUJAAKTukgAADVR5AAAKDkIA== From: "Michel Py" To: "Christian Huitema" , "Eugene M. Kim" , "IETF IPv6 Working Group" Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Christian, > Christian Huitema wrote: > The Teredo design is predicated on the idea that we can ship IPv6 > as a software upgrade on the PC. The update can be enabled as part > of an application development. That is actually quite powerful, > and does break the chicken-and-egg problem. True, but Teredo is both the best friend and the worst enemy of IPv6. The best friend because it does indeed enable app developers to develop IPv6-only apps before IPv6 is largely deployed at ISPs. The worst enemy because if IPv6-only apps work good enough over Teredo, consumers will no scream bloody murder to their ISPs to get native IPv6 and stick to IPv4. This is _not_ a criticism, but you above everyone else should understand that one if not _the_ primary functions of Teredo is NAT traversal, and if it does break the chicken-and-egg problem between ISPs and app developers it does create its own chicken-and-egg problem which basically the following: it enables IPv6 on the desktop without an infrastructure, but OTOH it enhances IPv4 NAT which in turn delays IPv6 deployment. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 20 21:32:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18484 for ; Mon, 20 Oct 2003 21:32:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABlNZ-0002eu-Od for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 21:32:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L1W9cs010214 for ipv6-archive@odin.ietf.org; Mon, 20 Oct 2003 21:32:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABlNZ-0002ef-IZ for ipv6-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 21:32:09 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18456 for ; Mon, 20 Oct 2003 21:31:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABlMU-0002Fn-7E; Mon, 20 Oct 2003 21:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABlM3-00025B-MV for ipv6@optimus.ietf.org; Mon, 20 Oct 2003 21:30:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18268 for ; Mon, 20 Oct 2003 21:30:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABlM0-0005Ml-00 for ipv6@ietf.org; Mon, 20 Oct 2003 21:30:32 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1ABlM0-0005MJ-00 for ipv6@ietf.org; Mon, 20 Oct 2003 21:30:32 -0400 Subject: RE: IPv6 adoption behavior Date: Mon, 20 Oct 2003 18:30:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: IPv6 adoption behavior Thread-Index: AcOXcOluNhgDulWrSbuP/TBa8MhndQAAS90g From: "Michel Py" To: "Eugene M. Kim" Cc: "IETF IPv6 Working Group" Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Eugene M. Kim > What customers want is to have their needs fulfilled (e.g. to be > able to play StarCraft online at a LAN party at their houses). > As long as they get what they want, they are less concerned > about what technology application developers and ISPs have used > to implement it. Thus, the ball is back on application developers > and ISPs' side. True, but keep something in mind: deploying IPv6 is a huge investment for ISPs, and the reason they don't deploy is because there is no consumer demand, _not_ because there are no apps. Good IPv6 apps MAY trigger demand, and may not. There are two things that are drive ISP (and most other businesses as well) investments: fear and greed. Fear to lose customers if they don't implement a new technology, greed if they see a cash cow on the horizon. WRT IPv6 today there is neither fear nor greed. Fear and greed comes from market feedback, nowhere else. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 04:09:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09661 for ; Tue, 21 Oct 2003 04:09:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrZn-0001f8-0S for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 04:09:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L89ATH006389 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 04:09:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrZm-0001ey-QU for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 04:09:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09628 for ; Tue, 21 Oct 2003 04:09:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrZj-0000pF-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 04:09:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABrZj-0000pB-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 04:09:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrYi-0001Fp-3P; Tue, 21 Oct 2003 04:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABrXr-0000qm-Qb for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 04:07:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09587 for ; Tue, 21 Oct 2003 04:07:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABrXo-0000oS-00 for ipv6@ietf.org; Tue, 21 Oct 2003 04:07:08 -0400 Received: from [193.11.93.231] (helo=slimsixten.besserwisser.org ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ABrXo-0000oE-00 for ipv6@ietf.org; Tue, 21 Oct 2003 04:07:08 -0400 Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.6) with ESMTP id h9L87Cqw026848; Tue, 21 Oct 2003 10:07:13 +0200 (CEST) Date: Tue, 21 Oct 2003 09:33:50 +0200 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: ipv6@ietf.org cc: Dan Lanciani Subject: Re: IPv6 adoption behavior Message-ID: <383870000.1066721630@localhost> In-Reply-To: <200310200423.AAA00548@ss10.danlan.com> References: <200310200423.AAA00548@ss10.danlan.com> X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========2033950493==========" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --==========2033950493========== Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Monday, October 20, 2003 00:23:04 -0400 Dan Lanciani wrote: > I strongly doubt that IPv6 will be available as a software-only upgrade > for any but the latest equipment. There is just too little incentive for > vendors (especially ones who have gone out of business :) to support > "legacy" hardware (where "legacy" seems to mean over six months old). My SparcStation 4 machines all run v6. They were built around 1995, iirc. We have a Cisco 7507 router in SUNET, bought around 1996, which runs v6.=20 Do you need more examples?=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========2033950493========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE/lOFf02/pMZDM1cURAk0XAJ460oDMtpfqkgg1cRSDyuPqpPBR/QCgmiNT hGg0uV9InxoMEfpvZ+6UWwc= =lEAm -----END PGP SIGNATURE----- --==========2033950493==========-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 05:40:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11399 for ; Tue, 21 Oct 2003 05:40:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABszM-0007LN-H1 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 05:39:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L9dec0028222 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 05:39:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABszM-0007L7-3y for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 05:39:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11372 for ; Tue, 21 Oct 2003 05:39:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABszI-0001Yn-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 05:39:36 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABszI-0001Yk-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 05:39:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABsyk-00077f-Po; Tue, 21 Oct 2003 05:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABsxv-0006ld-D8 for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 05:38:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11297; Tue, 21 Oct 2003 05:37:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABsxr-0001Y1-00; Tue, 21 Oct 2003 05:38:07 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABsxp-0001XH-00; Tue, 21 Oct 2003 05:38:06 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9L9bVC26462; Tue, 21 Oct 2003 12:37:32 +0300 Date: Tue, 21 Oct 2003 12:37:31 +0300 (EEST) From: Pekka Savola To: Dave Thaler cc: ipv6@ietf.org, , Subject: Re: FW: I-D ACTION:draft-thaler-inet-tunnel-mib-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Wed, 15 Oct 2003, Dave Thaler wrote: > Forwarding this announcement to the most relevant WG's... > > RFC 2667, entitled "IP Tunnel MIB", only supported > point-to-point tunnels over IPv4. This draft updates > RFC 2667 to also support tunnels over IPv6, as well as > tunnels which aren't just point-to-point (e.g. 6to4). > It also clarifies the use of the ifRcvAddressTable > for all tunnels. > > It uses the InetAddress types like the other MIBs > that have been done by the IPv6MIB Design Team. Thanks Dave. Two very high-level comments. An obvious oversight (or intentional one :-) is that I see an IANA registry being created, but no guidance on how new values should be added to it (IETF Consensus, Standards Action, FCFS, etc.) Also, it was not clear which WG you intend to run this through officially. I'm assuming ifmib. (Just trying to figure out what will be the role of v6ops WG in this process..) Pekka > Title : IP Tunnel MIB > Author(s) : D. Thaler > Filename : draft-thaler-inet-tunnel-mib-00.txt > Pages : 26 > Date : 2003-10-14 > > This memo defines a Management Information Base (MIB) for use with > network management protocols in the Internet community. In > particular, it describes managed objects used for managing tunnels > of any type over IPv4 and IPv6 networks. Extension MIBs may be > designed for managing protocol-specific objects. Likewise, > extension MIBs may be designed for managing security-specific > objects. This MIB does not support tunnels over non-IP networks. > Management of such tunnels may be supported by other MIBs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-thaler-inet-tunnel-mib-00.txt [...] -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 07:52:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14329 for ; Tue, 21 Oct 2003 07:52:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABv3d-00032H-VH for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 07:52:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LBqDPt011670 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 07:52:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABv3d-000329-Ls for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 07:52:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14300 for ; Tue, 21 Oct 2003 07:52:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABv3c-0002dw-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 07:52:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABv3c-0002dt-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 07:52:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABv2V-0002ip-Me; Tue, 21 Oct 2003 07:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABv1t-0002WF-Po for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 07:50:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14254 for ; Tue, 21 Oct 2003 07:50:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABv1s-0002cb-00 for ipv6@ietf.org; Tue, 21 Oct 2003 07:50:24 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1ABv1s-0002cY-00 for ipv6@ietf.org; Tue, 21 Oct 2003 07:50:24 -0400 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9LBo7ed081634; Tue, 21 Oct 2003 13:50:07 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <200310200423.AAA00548@ss10.danlan.com> References: <200310200423.AAA00548@ss10.danlan.com> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org From: Iljitsch van Beijnum Subject: Re: IPv6 adoption behavior Date: Tue, 21 Oct 2003 13:50:11 +0200 To: Dan Lanciani X-Mailer: Apple Mail (2.604) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 20 okt 2003, at 6:23, Dan Lanciani wrote: > |I don't see the upgrade costs for regular users. Users are by now > |used to upgrading monthly (if not more often) to plug the latest and > |greatest security holes, so a software upgrade to install IPv6 > |functionality somewhere in the next three years or so isn't a huge > |hardship. > I strongly doubt that IPv6 will be available as a software-only > upgrade for any but the latest equipment. This is indeed a problem for some types of equipment, such as multilayer switches. Those typically have IPv4 hardware on board which isn't easily upgradable. However, this isn't very relevant to end-users who spend most of their money on general-purpose computers that can be upgraded with new software. But all the main operating systems support IPv6 in their latest versions today anyway. > There is just too little incentive for vendors (especially ones who > have gone out of business :) to support "legacy" > hardware (where "legacy" seems to mean over six months old). Yes, that's why I have to buy a new GSM phone to get new features rather than simply update the software. Small stuff such as residential "routers" could be upgraded with new firmware but it's more likely that the vendors want to sell new boxes. Given the prices for this stuff I don't see a huge problem here. For the expensive stuff such a vendor policy wouldn't be accepted. > |Functionality won't disappear unless people turn off IPv4, which I > |don't expect them to do. > Sure, but that's basically saying that IPv6 + IPv4+NAT can replace > IPv4+NAT, which isn't very interesting. :) Why not? This way you get to have the best of both worlds: run existing NAT-compatible v4 apps without having to wait for v6 upgrades, but also run stuff that won't work over NAT. > |(I even get strange looks from people in IPv6 > |circles when I say I want to run IPv6-only hosts for test purposes.) > That's a rather telling response... Telling what about who? > |But I think > |we can and should add all the missing stuff to IPv6. > Naturally I agree, but it seems like one of the key features (address > independence) is a stumbling block. Have a look at what's happening with locator/identifier separation in the multi6 working group. A batch of new drafts is on its way. > |If we're going to be doing NAT anyway why bother with IPv6? > I've been wondering that myself lately. However, note that if we want to get NAT right (ie support incoming connections and referential integrity) we need just as many painful changes as we need for adopting IPv6. The difference being that IPv6 is here today, even if some desired features are still missing. > Possibly IPv6 will be useful in circumstances where the provider can > control the user's environment via restricted firmware, legal means, > etc. (The canonical example seems to be smart phones.) ??? Why would IPv6 be more useful here? > |> Unfortunately, being "superior" in some abstract sense is not > |> sufficient for something as utilitarian as a networking protocol > |> suite. We have to examine actual usage requirements. > |Yes. But note that this doesn't have to be the actual end-user. > I understand that actual end-user requirements are not a major > consideration for IPv6 development. This has been discussed before > and I've commented that I'm not thrilled with the decision to > concentrate on provider requirements, The way something is developed and the way it is subsequently used are two very different things. Obviously ignoring user requirements during development would be a huge mistake. But once the product is there, there are many ways in which it may be adopted by the market place. End-user demand is one, lower operational costs somewhere in the chain is another one. > Eventually you have to convince the end-users to use the service or it > will fail. End-users have evolved a bit over the years. End-users care about applications and services, not whether the first 4 bits in IP packets are "0100" or "0110". If something needs IPv6 in order to work, and that application or service manages to install IPv6 connecivity without bothering the user (by doing toredo on the user's box or 6to4 in the NAT gateway) the user won't mind. > I see three possible paths: > -We do something to satisfy the users' requirements without making > them resort to NAT, possibly upsetting providers who will need to > adjust their business models. Since the IPv6 business model includes far fewer worms (because it's pretty much impossible to infect boxes by randomly trying addresses in IPv6) I think this will work out. > -We do nothing special and the market supplies IPv6 NAT. Things stay > pretty much as they are. Even if IPv6 NAT becomes available, I don't think very many people will use it. > -We do something radical to prevent users from employing NAT-like > solutions, possibly failing by succeeding if those users reject the > protocol. Why would we do this? > |It is becoming quite apparent that having a > |stable internal network and an ephemeral externally reachable network > |provide seamless functionality can only be achieved using very dirty > |hacks. > It is not at all apparent to me. The trouble is that if you have stable address A and you want to connect to someone who has stable address B, you have no way of knowing whether the infrastructure in the middle supports routing packets A->B and B->A. So either you always prefer the stable addresses and you end up waiting for timeouts often, or you always prefer PA addresses and the advantages of stable addressing are largely lost. > There are many ways to achieve that goal including PI space handled > directly at the routing level, various forms of source routing > including locator/identifier separation, and overlay networks. Yes, hopefully we can get this to work. > |The internet supported address portability until 10 years > |ago. This was a poor design because it doesn't scale, regardless of > |the usefulness of the functionality. > > This is a common but confusing generalization. Portable address usage > grows linearly in the actual number of users. It is very hard to do > better than this without NAT-like hacks. CIDR has done relatively well. Could have done much better without the v4 address squeeze. > Even those merely divide by a constant without changing > the order of growth. On the other hand, hierarchical provider-based > allocation consumes addresses exponentially in the number of provider > levels, Not sure about this being exponential, but yes, there is more waste in overhead. However, this is in the addresses used, while the problem is the number of distinct blocks. > assuring that there will always be an address shortage at the lowest > level(s). How do you figure? If ISPs want they can request more addresses from the RIRs as long as they provide documentation of how those addresses are going to be used. > Increasing hardware capability has taken the wind out of the memory > size argument, so the current fashion seems to be to consider the > computational load of building the table in the first place, again > constraining the process to work exactly as it does today. This is a > harder problem to overcome by brute force, but it still has nothing to > do with the scalability of portable addresses themselves. Why not? > It just means that we can't necessarily support an arbitrary number > of portable addresses *and* still constrain the routing process to > work exactly as it does today. In what way exactly would you like to change routing? Sure, there is lots of optimization to be had (I talked about encoding reachability for multihomers in bitmaps at one point) but you can't get around the fact that when a link goes down, you must send an update and every ISP has to process it. And the bigger your routing table is, the longer the processing takes... This scales worse than linear. > One obvious approach (if we did want to support portable addresses) is > to return to a dumb network/smart host model and push the route > computation to the edges of the network where the available resources > grow with the consumers. Sounds nice, but how is this going to work in practice? > Routers could go back to simply forwarding packets as fast as possible > rather than spending lots of cycles enforcing economic policies by > applying complicated filters to AS paths to determine whether this or > that network really deserves transit service. You need this regardless but it's moot anyway as route processing and packet forwarding are decoupled in fast routers today. > It looks like you snipped a question. Here it is in context: Others already talked about the right vs wrong analogy, no need to repeat it. Iljitsch -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 07:53:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14400 for ; Tue, 21 Oct 2003 07:53:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABv4e-0003Tz-9u for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 07:53:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LBrGLX013381 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 07:53:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABv4d-0003Sb-UM for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 07:53:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14360 for ; Tue, 21 Oct 2003 07:53:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABv4a-0002eh-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 07:53:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABv4a-0002eb-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 07:53:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABv4S-0003Gy-7R; Tue, 21 Oct 2003 07:53:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABv4D-0003Cz-6D for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 07:52:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14346 for ; Tue, 21 Oct 2003 07:52:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABv4C-0002eE-00 for ipv6@ietf.org; Tue, 21 Oct 2003 07:52:48 -0400 Received: from [195.41.29.4] (helo=ursa.amorsen.dk) by ietf-mx with esmtp (Exim 4.12) id 1ABv4B-0002ds-00 for ipv6@ietf.org; Tue, 21 Oct 2003 07:52:47 -0400 Received: from [10.0.0.217] (lion2.ipservice.dk [212.242.77.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ursa.amorsen.dk (Postfix) with ESMTP id E77ED1C150 for ; Tue, 21 Oct 2003 13:52:07 +0200 (CEST) Subject: RE: IPv6 adoption behavior From: Benny Amorsen To: IETF IPv6 Working Group In-Reply-To: References: Content-Type: text/plain Message-Id: <1066737124.1777.9.camel@vega.amorsen.dk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-5) Date: Tue, 21 Oct 2003 13:52:05 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 2003-10-21 at 03:16, Michel Py wrote: > True, but Teredo is both the best friend and the worst enemy of IPv6. > The best friend because it does indeed enable app developers to develop > IPv6-only apps before IPv6 is largely deployed at ISPs. The worst enemy > because if IPv6-only apps work good enough over Teredo, consumers will > no scream bloody murder to their ISPs to get native IPv6 and stick to > IPv4. If ISPs see the a significant amount of their traffic is IPv6 encapsulated in IPv4, they will be pushed towards providing native IPv6 or at least their own IPv6-to-IPv4 gateways. Otherwise their lines to other ISPs are burdened with the overhead of tunnelling, and traffic that is between customers of one ISP will go to a foreign gateway and back. Eventually when there are many applications, customers will start demanding low latency -- certain user segments already choose providers based on latency. Obviously native IPv6 will provide better latency than tunnelling. Teredo and 6to4 also ensures that there it does not make business sense for ISPs to provide only a single IPv6-address to a user. If they do that, the user will ignore the native IPv6-connectivity and use Teredo or 6to4. Sure, those tunnelling technologies may delay native IPv6, but on the other hand they ensure that when native IPv6 arrives, it will be the real thing and not crippled. /Benny -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 08:19:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15083 for ; Tue, 21 Oct 2003 08:19:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABvTu-0001Bf-8S for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 08:19:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LCJMxE004562 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 08:19:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABvTt-0001BN-LZ for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 08:19:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15054 for ; Tue, 21 Oct 2003 08:19:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABvTs-0002tq-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 08:19:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABvTr-0002tn-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 08:19:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABvTZ-0000zO-R0; Tue, 21 Oct 2003 08:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABvSg-0000jX-Dg for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 08:18:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14955 for ; Tue, 21 Oct 2003 08:17:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABvSf-0002te-00 for ipv6@ietf.org; Tue, 21 Oct 2003 08:18:05 -0400 Received: from ns1.fries.net ([66.210.106.27] helo=fries.net ident=hvfwhjzhue24k9r47o99) by ietf-mx with esmtp (Exim 4.12) id 1ABvSc-0002tK-00 for ipv6@ietf.org; Tue, 21 Oct 2003 08:18:02 -0400 Received: from shadow.fries.net (localhost.fries.net [IPv6:::1]) by fries.net (8.12.9/8.12.9) with ESMTP id h9LCF83p013398 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2003 07:15:08 -0500 (CDT) Received: (from todd@localhost) by shadow.fries.net (8.12.9/8.12.9/Submit) id h9LCF6qL023518; Tue, 21 Oct 2003 07:15:06 -0500 (CDT) Date: Tue, 21 Oct 2003 07:15:06 -0500 From: "Todd T. Fries" To: Dan Lanciani Cc: ipv6@ietf.org Subject: Re: IPv6 adoption behavior Message-ID: <20031021121506.GA18743@fries.net> Reply-To: todd@fries.net References: <200310142211.SAA04345@ss10.danlan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310142211.SAA04345@ss10.danlan.com> User-Agent: Mutt/1.4.1i X-Operating-System: OpenBSD shadow.fries.net 3.4 GENERIC X-PGP-Fingerprint: B6 3B 70 46 BC 0F 8C DD 14 D4 C7 D1 47 F6 23 FA X-URL: http://todd.fries.net X-tra-email: todd@{fries.net,OpenBSD.org} toddf@acm.org toddfries@yahoo.com X-IM: toddfries@{AIM,Yahoo} 115268457@ICQ {toddfries,fr[1i]es}@*.irc.fries.net X-Jabber: todd@tipic.com Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , I'm sorry to reply late to this, but I can't help but realize that NAT+IPv4 vs IPv6+firewall can be equivalent in `isolation'. Simply `block in all' and `pass out on $ext_if keep state' (in the pf terms of OpenBSD) and in two rules you have the same isolation of a NAT+IPv4 as you do with IPv6+firewall. I do not get your `reduced functionality' paridim. It is the NAT network that has the reduced functionality. Most people that are using NAT are using NAT because there was not the address space available from their upstream to allocate a sufficient amount of IPv4 addresses to cover the subnets and machines needing addressing space. I include myself in this group. Some people (perhaps a larger number of devices, due to enterprise deployment) seem to think NAT is a safety net, a magic key, that will be a simple firewall to protect them from the nasties of virueses and such. To them I simply ask, how do you block mail viruses that are retrieved by the client? How do you stop the users inside the NAT from retrieving via other means (http, nntp, im, etc) nasties that you want to keep out, and also keep them from blowing up your internal network should a nasty infect a machine? I believe a firewall + real allocation is superior to NAT in that protocols that need true address space to operate properly (otherwise require proxies; for example: ftp, realaudio) .. or they cannot operate at all (ever try to do ESP IPsec from multiple machines inside nat to a single remote IPsec gateway?) benifit, and there is only the `fear factor' regarding any other differences. -- Todd Fries .. todd@fries.net Free Daemon Consulting, LLC Land: 405-748-4596 http://FreeDaemonConsulting.com Mobile: 405-203-6124 "..in support of free software solutions." Key fingerprint: 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A Key: http://todd.fries.net/pgp.txt (last updated 2003/03/13 07:14:10) Penned by Dan Lanciani on Tue, Oct 14, 2003 at 06:11:24PM -0400, we have: | Geoff Huston writes: | | |Indeed. The only other factor here is that it is not entirely a clean | |substitution, | |as NATs provide an alternative product which is an imperfect substitution. | |The extent | |to which the market, over the past few years, has tended towards NATs despite | |the negative effects in both local and network domains is quickly | |becoming the dominant factor in any economic consideration of this entire | |IPv4 / IPv6 area. | | IMO, to consider IPv6 even as an imperfect substitution for IPv4+NAT is to | vastly overstate IPv6 functionality. IPv6 offers absolutely nothing as a | replacement for NAT's primary function: isolation of the customer network | from the (typically business-driven) address policies of the service provider | (e.g., cost, limits on number and stability, etc.). If anything IPv6 moves | in the opposite direction by providing more invasive mechanisms than existing | DHCP leases for the provider to disrupt the customer's network. It's all well | and good to speculate that IPv6 customers won't *need* the isolation that NAT | now offers with IPv4 because of (insert your favorite fantasy about transparent | renumbering or philanthropic ISPs) but none of those dodges exist at present. | Moreover, discussion of solutions that could actually fulfill the prophesy of | rendering isolation unnecessary (e.g., source routing in its guise of locator/ | identifier separation) are systematically relegated to small discussion lists | where they pose no threat of implementation. | | You might be able to call IPv6 an imperfect substitution for IPv4 *without* | NAT except for the glaring problem of single-address multi-homing support. | Similarly, IPv6+NAT might be said to be an imperfect substitution for IPv4+NAT, | and is probably what we will end up with if we end up with IPv6 (as an IPv4 | replacement) at all. More likely v4 and v6 will continue in parallel forever | since the upgrade costs are significant, especially when you consider the | reduced functionality. | | Dan Lanciani | ddl@danlan.*com | | -------------------------------------------------------------------- | IETF IPv6 working group mailing list | ipv6@ietf.org | Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 | -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 09:41:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17344 for ; Tue, 21 Oct 2003 09:41:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABwlW-0005zN-BU for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 09:41:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LDfcWU023015 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 09:41:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABwlW-0005z8-5h for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 09:41:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17310 for ; Tue, 21 Oct 2003 09:41:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABwlU-0003X8-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 09:41:36 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABwlU-0003X5-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 09:41:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABwkx-0005gF-G2; Tue, 21 Oct 2003 09:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABwkQ-0005Wt-8h for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 09:40:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17274 for ; Tue, 21 Oct 2003 09:40:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABwkO-0003WH-00 for ipv6@ietf.org; Tue, 21 Oct 2003 09:40:28 -0400 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1ABwkN-0003WD-00 for ipv6@ietf.org; Tue, 21 Oct 2003 09:40:27 -0400 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 359E5830F; Tue, 21 Oct 2003 15:40:20 +0200 (CEST) From: "Jeroen Massar" To: "'Benny Amorsen'" , Subject: RE: IPv6 adoption behavior Date: Tue, 21 Oct 2003 15:40:21 +0200 Organization: Unfix Message-ID: <004d01c397d8$e0349b60$210d640a@unfix.org> 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.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <1066739712.1777.16.camel@vega.amorsen.dk> Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Benny Amorsen wrote: > On 2003-10-21 at 14:15, Todd T. Fries wrote: > > > I'm sorry to reply late to this, but I can't help but realize that > > NAT+IPv4 vs IPv6+firewall can be equivalent in `isolation'. Simply > > `block in all' and `pass out on $ext_if keep state' (in the pf terms of > > OpenBSD) and in two rules you have the same isolation of a NAT+IPv4 as > > you do with IPv6+firewall. > > Imagine that two internal hosts are communicating in your > scenario. They have a TCP connection running for weeks. > Then the outside connection to > the Internet breaks and is brought back up, but assigned a different > address. In the IPv4+NAT case hosts that only contact other > hosts on the internal network do not notice the failure at all. > In the IPv6+firewall case the new addresses are provided to the > hosts and eventually the old > addresses time out -- and the internal TCP connection breaks. Ouch. As long as the IP addresses are not deconfigured this is no problem The "old" IP addresses are deprecated for use, 'old' connections stay up, but the new IP is used for new connections. Note that ofcourse you will need to update DNS and such. Last week I saw a good example of this. In May 2003 we transitioned the Concepts POP from to RIPE addresses by allowing both the old and new prefix to be used until June 1st after which we reconfigged the ingress filter, allowing only the delegated RIPE space and dropping and logging the rest. Even upto last month connections where seen coming from the 6bone space from one person who still had machines running which where not reconfigured and thus still used the old prefix in his local setup. I think IPv6 works perfectly well in cases like these ;) Neeeeeeexxxt reason why NAT is so good..... which it really isn't. It indeed has some advantages but most problems outweigh those with ease. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP5U3RCmqKFIzPnwjEQJ6GgCZAV1jHd/+iCUX/Zb2QBR4ki7xpDUAoIP8 ST7IRo2QGmcgJ03w0DNILuau =LiAZ -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 10:15:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19221 for ; Tue, 21 Oct 2003 10:15:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxI6-0007CJ-AQ for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 10:15:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LEFIcB027661 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 10:15:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxI6-0007C4-4A for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 10:15:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19156 for ; Tue, 21 Oct 2003 10:15:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABxI3-0003pw-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 10:15:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABxI3-0003pt-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 10:15:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxGs-0006eD-7o; Tue, 21 Oct 2003 10:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxGJ-0006We-WF for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 10:13:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18948 for ; Tue, 21 Oct 2003 10:13:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABxGH-0003nS-00 for ipv6@ietf.org; Tue, 21 Oct 2003 10:13:25 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1ABxGH-0003nD-00 for ipv6@ietf.org; Tue, 21 Oct 2003 10:13:25 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h9LECpO8027756; Tue, 21 Oct 2003 09:12:51 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 21 Oct 2003 09:12:02 -0500 Received: from [142.133.72.18] (142.133.72.18 [142.133.72.18]) by eammlex033.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 43LM1P7K; Tue, 21 Oct 2003 10:15:46 -0400 Date: Tue, 21 Oct 2003 10:11:17 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: suresh.krishnan@ericsson.ca To: Benny Amorsen cc: ipv6@ietf.org Subject: Re: IPv6 adoption behavior In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF830BD6282D@eammlex037.lmc.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, 21 Oct 2003, Benny Amorsen wrote: >internal network do not notice the failure at all. In the IPv6+firewall >case the new addresses are provided to the hosts and eventually the old >addresses time out -- and the internal TCP connection breaks. Ouch. Not if you have statically assigned IPv6 address space. What if you got a /48 from your ISP? Why would this break anything? If we ever get to have working PI address allocation this would not break even if you change ISPs. > > >/Benny > > > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 10:18:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19498 for ; Tue, 21 Oct 2003 10:18:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxKr-0007zf-2F for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 10:18:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LEI95t030721 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 10:18:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxKp-0007yI-W8 for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 10:18:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19438 for ; Tue, 21 Oct 2003 10:17:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABxKn-0003rf-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 10:18:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABxKn-0003rc-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 10:18:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxKk-0007ph-Bg; Tue, 21 Oct 2003 10:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxJx-0007cm-TP for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 10:17:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19395 for ; Tue, 21 Oct 2003 10:17:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABxJv-0003rR-00 for ipv6@ietf.org; Tue, 21 Oct 2003 10:17:11 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1ABxJv-0003rG-00 for ipv6@ietf.org; Tue, 21 Oct 2003 10:17:11 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h9LEGWO8028591; Tue, 21 Oct 2003 09:16:32 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 21 Oct 2003 09:15:43 -0500 Received: from [142.133.72.18] (142.133.72.18 [142.133.72.18]) by eammlex033.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 43LM1P75; Tue, 21 Oct 2003 10:19:29 -0400 Date: Tue, 21 Oct 2003 10:15:00 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: suresh.krishnan@ericsson.ca To: Jeroen Massar cc: "'Dan Lanciani'" , Subject: RE: IPv6 adoption behavior In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF830BD6282E@eammlex037.lmc.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >You are wrong :) They tasted the filth of being behind NAT's >and not being able to do a number of things including VoIP. I am no NAT apologist but I do not think this is entirely true. Skype runs amazingly well behind NATs. As long as NAT is an option people will find ways to twist applications to work with it. It is the application developer who feels the pain. Not the end user. Regards Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 10:21:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19692 for ; Tue, 21 Oct 2003 10:21:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxNt-0000WF-3z for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 10:21:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LELHjm001989 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 10:21:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxNs-0000W0-U2 for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 10:21:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19645 for ; Tue, 21 Oct 2003 10:21:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABxNq-0003vC-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 10:21:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABxNp-0003v9-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 10:21:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxNf-0000LB-9t; Tue, 21 Oct 2003 10:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxNJ-0000GG-NR for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 10:20:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19605 for ; Tue, 21 Oct 2003 10:20:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABxNH-0003uW-00 for ipv6@ietf.org; Tue, 21 Oct 2003 10:20:39 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ABxNF-0003u7-00 for ipv6@ietf.org; Tue, 21 Oct 2003 10:20:39 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 21 Oct 2003 07:20:50 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9LEK5jP027800; Tue, 21 Oct 2003 07:20:06 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-232.cisco.com [10.82.240.232]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADI27409; Tue, 21 Oct 2003 10:20:01 -0400 (EDT) Message-Id: <4.3.2.7.2.20031021101914.01e58370@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 21 Oct 2003 10:20:00 -0400 To: suresh.krishnan@ericsson.ca From: Ralph Droms Subject: RE: IPv6 adoption behavior Cc: Jeroen Massar , "'Dan Lanciani'" , In-Reply-To: References: <7B2A7784F4B7F0409947481F3F3FEF830BD6282E@eammlex037.lmc.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , How does Skype provide point-to-point connections through NAT without a centralized intermediary? - Ralph At 10:15 AM 10/21/2003 -0400, Suresh Krishnan wrote: > >You are wrong :) They tasted the filth of being behind NAT's > >and not being able to do a number of things including VoIP. > >I am no NAT apologist but I do not think this is entirely true. Skype runs >amazingly well behind NATs. As long as NAT is an option people will find >ways to twist applications to work with it. It is the application >developer who feels the pain. Not the end user. > >Regards >Suresh > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 10:28:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20047 for ; Tue, 21 Oct 2003 10:28:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxUc-0002Iu-A7 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 10:28:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LESEGK008850 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 10:28:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxUc-0002If-3I for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 10:28:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19995 for ; Tue, 21 Oct 2003 10:28:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABxUZ-000410-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 10:28:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABxUZ-00040u-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 10:28:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxUQ-00026P-0E; Tue, 21 Oct 2003 10:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxTo-0001yo-I3 for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 10:27:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19915 for ; Tue, 21 Oct 2003 10:27:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABxTm-0003za-00 for ipv6@ietf.org; Tue, 21 Oct 2003 10:27:22 -0400 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1ABxTh-0003zV-00 for ipv6@ietf.org; Tue, 21 Oct 2003 10:27:21 -0400 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id F019D830F; Tue, 21 Oct 2003 16:27:14 +0200 (CEST) From: "Jeroen Massar" To: Cc: "'Dan Lanciani'" , Subject: RE: IPv6 adoption behavior Date: Tue, 21 Oct 2003 16:27:10 +0200 Organization: Unfix Message-ID: <006a01c397df$69c2a150$210d640a@unfix.org> 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.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Ralph Droms [mailto:rdroms@cisco.com] wrote: > How does Skype provide point-to-point connections > through NAT without a centralized intermediary? See inline. Suresh Krishnan [mailto:suresh.krishnan@ericsson.ca] wrote: > >You are wrong :) They tasted the filth of being behind NAT's > >and not being able to do a number of things including VoIP. > > I am no NAT apologist but I do not think this is entirely > true. Skype runs amazingly well behind NATs. > As long as NAT is an option people will find > ways to twist applications to work with it. It is the application > developer who feels the pain. Not the end user. Skype "works" because it acts like an end to end program. It connects from a client to the server. The server has a public un-NATted IP. There are no IP's being passed in the packets apparently like in FTP etc. Thus there is no problem either. If both users are behind NAT's the packets get redirected via other hosts 'close' to those hosts using a overlay network above the internet.. named KaZaA in this case. Same can be done with Teredo and other overlay methods. Actually at the time of the start of the 6bone when everything was tunneled IPv6 this actually was the case. This is not end to end though, it is a workaround around NAT. Do we want that every application developer to start working around it? I don't want to. One is also depending on, not your upstream, but on third parties to route your packets inside the KaZaA network. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP5VCPSmqKFIzPnwjEQItmACbBmE9p7M363O7K68g5AolCT/7X3wAoJpV lf14PxMz631+vvYogICR7RKo =0NaJ -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 10:31:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20298 for ; Tue, 21 Oct 2003 10:31:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxXT-0003Jv-Ob for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 10:31:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LEV8d4012432 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 10:31:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxXQ-0003EG-Jt for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 10:31:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20237 for ; Tue, 21 Oct 2003 10:30:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABxXO-00045R-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 10:31:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABxXN-00045O-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 10:31:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxXL-00039q-De; Tue, 21 Oct 2003 10:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxX5-00035I-Tz for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 10:30:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20218 for ; Tue, 21 Oct 2003 10:30:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABxX3-00044v-00 for ipv6@ietf.org; Tue, 21 Oct 2003 10:30:45 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABxX2-00044s-00 for ipv6@ietf.org; Tue, 21 Oct 2003 10:30:45 -0400 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA28327 for ; Tue, 21 Oct 2003 15:30:42 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA29884 for ; Tue, 21 Oct 2003 15:30:42 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h9LEUg130595 for ipv6@ietf.org; Tue, 21 Oct 2003 15:30:42 +0100 Date: Tue, 21 Oct 2003 15:30:41 +0100 From: Tim Chown To: ipv6@ietf.org Subject: Re: IPv6 adoption behavior Message-ID: <20031021143041.GM27817@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , At 10:15 AM 10/21/2003 -0400, Suresh Krishnan wrote: >>You are wrong :) They tasted the filth of being behind NAT's >>and not being able to do a number of things including VoIP. > >I am no NAT apologist but I do not think this is entirely true. Skype runs >amazingly well behind NATs. As long as NAT is an option people will find >ways to twist applications to work with it. It is the application >developer who feels the pain. Not the end user. But if I want a VoIP communication from me (behind a NAT) to some user behind a NAT, not using a 3rd party "location" server, how does v4 deliver, without the receiving user having the pain of port forwarding configuration on their NAT? How do I do the same in v4 where I want end-to-end encryption on the application? Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 10:51:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21508 for ; Tue, 21 Oct 2003 10:51:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxqZ-0007xY-9m for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 10:50:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LEotqq030596 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 10:50:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxqZ-0007xP-2h for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 10:50:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21417 for ; Tue, 21 Oct 2003 10:50:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABxqW-0004Ri-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 10:50:52 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABxqW-0004Rf-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 10:50:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxpj-0007hN-T2; Tue, 21 Oct 2003 10:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxpP-0007d6-Vv for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 10:49:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21282 for ; Tue, 21 Oct 2003 10:49:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABxpN-0004QB-00 for ipv6@ietf.org; Tue, 21 Oct 2003 10:49:41 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1ABxpM-0004Pq-00 for ipv6@ietf.org; Tue, 21 Oct 2003 10:49:41 -0400 Subject: RE: IPv6 adoption behavior MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Oct 2003 07:49:04 -0700 Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: IPv6 adoption behavior Thread-Index: AcOX4JaIxe4YIKcVR8aBrIDJC8NlWwAAQCzA From: "Michel Py" To: "Tim Chown" , Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Tim Chown wrote: > But if I want a VoIP communication from me (behind a NAT) to > some user behind a NAT, not using a 3rd party "location" server, > how does v4 deliver, without the receiving user having the pain > of port forwarding configuration on their NAT? There are several methods today; uPNP for example. Besides, not using a 3rd party location server for VOIP does not make a lot of sense. Looking at SIP as an example, yes you can initiate a communication directly to the IP address, but it is much more convenient to register with a directory that almost everyone will end up doing it anyway, NAT traversal or not. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 10:52:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21603 for ; Tue, 21 Oct 2003 10:52:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxrk-00007b-Se for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 10:52:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LEq8Xd000461 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 10:52:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxrk-00007M-MI for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 10:52:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21564 for ; Tue, 21 Oct 2003 10:51:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABxri-0004Ua-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 10:52:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABxrh-0004UX-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 10:52:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxre-0008TN-Ir; Tue, 21 Oct 2003 10:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxTO-0001oR-C9 for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 10:26:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19881 for ; Tue, 21 Oct 2003 10:26:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABxTM-0003yv-00 for ipv6@ietf.org; Tue, 21 Oct 2003 10:26:56 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1ABxTL-0003yO-00 for ipv6@ietf.org; Tue, 21 Oct 2003 10:26:55 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h9LEQFO8000677; Tue, 21 Oct 2003 09:26:15 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 21 Oct 2003 09:25:26 -0500 Received: from [142.133.72.18] (142.133.72.18 [142.133.72.18]) by eammlex033.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 43LM1P9S; Tue, 21 Oct 2003 10:29:12 -0400 Date: Tue, 21 Oct 2003 10:24:43 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: suresh.krishnan@ericsson.ca To: Ralph Droms cc: suresh.krishnan@ericsson.ca, Jeroen Massar , "'Dan Lanciani'" , Subject: RE: IPv6 adoption behavior In-Reply-To: <4.3.2.7.2.20031021101914.01e58370@flask.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, 21 Oct 2003, Ralph Droms wrote: >How does Skype provide point-to-point connections through NAT without a >centralized intermediary? > >- Ralph There is no centralized intermediary. But skype uses other non-NATted non-firewalled peers to route calls between two NATted FWed endpoints. Regards Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 11:12:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22666 for ; Tue, 21 Oct 2003 11:12:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByBK-0005TX-Pc for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 11:12:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LFCM9S021041 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 11:12:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByBK-0005TI-Kc for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 11:12:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22627 for ; Tue, 21 Oct 2003 11:12:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AByBJ-0004nb-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 11:12:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AByBJ-0004nY-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 11:12:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByAy-0005Fo-Ep; Tue, 21 Oct 2003 11:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByAR-000573-2b for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 11:11:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22572 for ; Tue, 21 Oct 2003 11:11:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AByAO-0004n2-00 for ipv6@ietf.org; Tue, 21 Oct 2003 11:11:24 -0400 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AByAN-0004mi-00 for ipv6@ietf.org; Tue, 21 Oct 2003 11:11:23 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id h9LF2dpI007516; Tue, 21 Oct 2003 17:02:39 +0200 Received: from sverresborg.uninett.no (localhost.localdomain [127.0.0.1]) by sverresborg.uninett.no (8.12.8/8.12.9) with ESMTP id h9LF2dR7030238; Tue, 21 Oct 2003 17:02:39 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id h9LF2d73030237; Tue, 21 Oct 2003 17:02:39 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 21 Oct 2003 17:02:39 +0200 From: Stig Venaas To: Michel Py Cc: Tim Chown , ipv6@ietf.org Subject: Re: IPv6 adoption behavior Message-ID: <20031021150239.GB30159@sverresborg.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, Oct 21, 2003 at 07:49:04AM -0700, Michel Py wrote: > > Tim Chown wrote: > > But if I want a VoIP communication from me (behind a NAT) to > > some user behind a NAT, not using a 3rd party "location" server, > > how does v4 deliver, without the receiving user having the pain > > of port forwarding configuration on their NAT? > > There are several methods today; uPNP for example. Besides, not using a > 3rd party location server for VOIP does not make a lot of sense. Looking > at SIP as an example, yes you can initiate a communication directly to > the IP address, but it is much more convenient to register with a > directory that almost everyone will end up doing it anyway, NAT > traversal or not. But there is a big difference between using a 3rd party directory, and passing data through an intermediary. That is, you might very well have end-to-end connectivity, but use a directory to locate the other end-point. Stig -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 11:21:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23177 for ; Tue, 21 Oct 2003 11:21:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByJy-0008Jr-0t for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 11:21:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LFLHBQ031973 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 11:21:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByJx-0008Jc-OS for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 11:21:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23106 for ; Tue, 21 Oct 2003 11:21:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AByJw-0004w6-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 11:21:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AByJw-0004w3-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 11:21:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByJi-000885-M5; Tue, 21 Oct 2003 11:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByIu-0007ph-Ig for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 11:20:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23031 for ; Tue, 21 Oct 2003 11:20:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AByIt-0004ui-00 for ipv6@ietf.org; Tue, 21 Oct 2003 11:20:11 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AByIs-0004uU-00 for ipv6@ietf.org; Tue, 21 Oct 2003 11:20:10 -0400 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA29855 for ; Tue, 21 Oct 2003 16:20:08 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA03160 for ; Tue, 21 Oct 2003 16:20:08 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h9LFK7m32430 for ipv6@ietf.org; Tue, 21 Oct 2003 16:20:07 +0100 Date: Tue, 21 Oct 2003 16:20:07 +0100 From: Tim Chown To: ipv6@ietf.org Subject: Re: IPv6 adoption behavior Message-ID: <20031021152007.GE30701@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <20031021150239.GB30159@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031021150239.GB30159@sverresborg.uninett.no> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, Oct 21, 2003 at 05:02:39PM +0200, Stig Venaas wrote: > But there is a big difference between using a 3rd party directory, and > passing data through an intermediary. That is, you might very well have > end-to-end connectivity, but use a directory to locate the other > end-point. Indeed. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 11:22:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23234 for ; Tue, 21 Oct 2003 11:22:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByKj-0000JW-Au for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 11:22:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LFM343000975 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 11:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByKh-0000Bn-Ag for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 11:22:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23200 for ; Tue, 21 Oct 2003 11:21:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AByKg-0004xi-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 11:22:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AByKf-0004xb-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 11:22:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByKf-00008U-Sq; Tue, 21 Oct 2003 11:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByJz-0008KR-He for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 11:21:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23102 for ; Tue, 21 Oct 2003 11:21:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AByJv-0004vz-00 for ipv6@ietf.org; Tue, 21 Oct 2003 11:21:15 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1AByJv-0004vJ-00 for ipv6@ietf.org; Tue, 21 Oct 2003 11:21:15 -0400 Subject: RE: IPv6 adoption behavior Date: Tue, 21 Oct 2003 08:20:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: IPv6 adoption behavior Thread-Index: AcOX5YE4L5yfPbtOTni6nruCjKyArgAAJDsg From: "Michel Py" To: "Stig Venaas" Cc: "Tim Chown" , Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Stig Venaas wrote: > But there is a big difference between using a 3rd party directory, > and passing data through an intermediary. That is, you might very > well have end-to-end connectivity, but use a directory to locate > the other end-point. Indeed. But the difference is big technically, which the end user does care about. As of today, there are several SIP directories that are jockeying for market share, some offering the service for free. For these guys, offering an automatic NAT traversal mechanism integrated with the directory is a big plus, as there is a large potential customer base that uses NAT. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 11:35:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23653 for ; Tue, 21 Oct 2003 11:35:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByXQ-0003nR-9Q for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 11:35:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LFZCkE014592 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 11:35:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByXP-0003nH-Ml for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 11:35:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23607 for ; Tue, 21 Oct 2003 11:35:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AByXO-00055r-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 11:35:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AByXO-00055n-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 11:35:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByXF-0003c3-SV; Tue, 21 Oct 2003 11:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByWi-0003Qm-Of for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 11:34:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23567 for ; Tue, 21 Oct 2003 11:34:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AByWh-00054v-00 for ipv6@ietf.org; Tue, 21 Oct 2003 11:34:27 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AByWc-00054F-00 for ipv6@ietf.org; Tue, 21 Oct 2003 11:34:27 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h9LFXgO8018431; Tue, 21 Oct 2003 10:33:42 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 21 Oct 2003 10:32:53 -0500 Received: from [142.133.72.18] (142.133.72.18 [142.133.72.18]) by eammlex033.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 43LM1QJS; Tue, 21 Oct 2003 11:36:31 -0400 Date: Tue, 21 Oct 2003 11:32:02 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: suresh.krishnan@ericsson.ca To: Ralph Droms cc: Jeroen Massar , "'Dan Lanciani'" , Subject: RE: IPv6 adoption behavior In-Reply-To: <4.3.2.7.2.20031021101914.01e58370@flask.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, 21 Oct 2003, Ralph Droms wrote: >How does Skype provide point-to-point connections through NAT without a >centralized intermediary? > >- Ralph There is no centralized intermediary. But skype uses other non-NATted non-firewalled peers to route calls between two NATted FWed endpoints. There is no security concern as the traffic is e2e encrypted. Regards Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 13:39:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27740 for ; Tue, 21 Oct 2003 13:39:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0Sx-0004zh-Fz for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 13:38:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LHch5c019191 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 13:38:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0Sx-0004zS-4J for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 13:38:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27710 for ; Tue, 21 Oct 2003 13:38:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC0Su-0006Vu-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 13:38:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC0Su-0006Vr-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 13:38:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0RL-0003u8-6T; Tue, 21 Oct 2003 13:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0QM-0003R3-KZ for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 13:36:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27471 for ; Tue, 21 Oct 2003 13:35:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC0QK-0006Qi-00 for ipv6@ietf.org; Tue, 21 Oct 2003 13:36:00 -0400 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx with esmtp (Exim 4.12) id 1AC0QJ-0006Qf-00 for ipv6@ietf.org; Tue, 21 Oct 2003 13:35:59 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 87109BA40; Tue, 21 Oct 2003 13:35:59 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 21 Oct 2003 13:35:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 adoption behavior Date: Tue, 21 Oct 2003 13:35:58 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0512204A@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 adoption behavior Thread-Index: AcOXqq0cxCzmOTU2SteShnYX7wXyaQATuJKw From: "Bound, Jim" To: =?iso-8859-1?Q?M=E5ns_Nilsson?= , Cc: "Dan Lanciani" X-OriginalArrivalTime: 21 Oct 2003 17:35:59.0067 (UTC) FILETIME=[CA2662B0:01C397F9] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sorry all these vendors support IPv6 upgrades as part of OS releases: = Sun, IBM, HP, Microsoft, Cisco, Juniper, Windriver, and others. Yes = some router and embedded systems hardware will require next gen = hardware. But to say that IPv6 requires a hardware upgrade is = misleading and not true for most boxes deployed in the market today. /jim > -----Original Message----- > From: M=E5ns Nilsson [mailto:mansaxel@sunet.se]=20 > Sent: Tuesday, October 21, 2003 3:34 AM > To: ipv6@ietf.org > Cc: Dan Lanciani > Subject: Re: IPv6 adoption behavior >=20 >=20 >=20 >=20 > --On Monday, October 20, 2003 00:23:04 -0400 Dan Lanciani=20 > wrote: >=20 > > I strongly doubt that IPv6 will be available as a software-only=20 > > upgrade for any but the latest equipment. There is just too little=20 > > incentive for vendors (especially ones who have gone out of=20 > business=20 > > :) to support "legacy" hardware (where "legacy" seems to=20 > mean over six=20 > > months old). >=20 > My SparcStation 4 machines all run v6. They were built around=20 > 1995, iirc. We have a Cisco 7507 router in SUNET, bought=20 > around 1996, which runs v6.=20 >=20 > Do you need more examples?=20 >=20 > --=20 > M=E5ns Nilsson Systems Specialist > +46 70 681 7204 KTHNOC MN1334-RIPE >=20 > We're sysadmins. To us, data is a protocol-overhead. >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 14:08:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28572 for ; Tue, 21 Oct 2003 14:08:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0vb-0005Le-W4 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 14:08:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LI8Jx3020552 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 14:08:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0vb-0005LP-RK for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 14:08:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28517 for ; Tue, 21 Oct 2003 14:08:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC0vZ-0006tu-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 14:08:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC0vY-0006tq-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 14:08:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0vK-0005DP-IJ; Tue, 21 Oct 2003 14:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0vD-0005AG-E2 for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 14:07:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28502 for ; Tue, 21 Oct 2003 14:07:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC0vA-0006tM-00 for ipv6@ietf.org; Tue, 21 Oct 2003 14:07:52 -0400 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx with esmtp (Exim 4.12) id 1AC0v6-0006tJ-00 for ipv6@ietf.org; Tue, 21 Oct 2003 14:07:48 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id ADF83FEA8 for ; Tue, 21 Oct 2003 14:07:47 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 21 Oct 2003 14:07:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Comments: draft-savola-v6ops-transarch-01.txt Date: Tue, 21 Oct 2003 14:07:47 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA159@tayexc13.americas.cpqcorp.net> Thread-Topic: Comments: draft-savola-v6ops-transarch-01.txt Thread-Index: AcOX/jucABtFjxrRSUKK+/Btnfb/BQ== From: "Bound, Jim" To: X-OriginalArrivalTime: 21 Oct 2003 18:07:47.0318 (UTC) FILETIME=[3B8E6160:01C397FE] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This draft can become useful, but needs more WG discussion and I suggest we have that here and give Pekka input. Document needs spell checker for some wordsm, and sentence structure check. Also to mahy cliches used that convey no technical message to me as a reader. I think the document important but needs much more work here in the WG. Specific Comments: Robustness is also essential: the mechanism and the architecture must be reliable and robust, to encourage the adoption. Also, mechanisms must not be less robust than their IPv4 counterparts: quite the contrary. It is highly desirable to aim for building the architecture which does not depend on known-unreliable components (for example, certain operational modes of IPv4 NAT's); otherwise, the whole architecture is easily deemed unreliable. Confused on what is trying to be said regarding IPv4 counter parts? How can an IPv6/IPv4 transition mechanism have a counter part. I get the point but this needs word-smithing to tighten up the point for robustness. Also I don't think any mechanisms proposed in our history rely on IPv4 parts that do not work well? In absence of a plan, the transition must be made so that the future transition options will not be end-ran, and only "safe" transitionary actions are executed. For example, deploying dual-stack nodes with currently only IPv4 connectivity does not end-run any transitionary goals, but is an important step that must be done anyway. Not sure what end-ran or end-run defines?=20 What exactly does "safe transitonary actions" mean? I am having a hard time parsing the point of this paragraph?=20 Mechanisms: o Providing IPv6 connectivity o Protocol translation o Application-specific protocol interoperability (ie. ALG or proxy) Deployment models for IP nodes: o IPv4-only o Dual-stack with only IPv4 connectivity o Dual-stack w/ IPv4/6 connectivity o Dual-stack with only IPv6 connectivity o IPv6-only And services: o IPv4-only o Separate IPv4 and IPv6 o IPv4/6 o IPv6-only Each of the above should be their own section with descriptions in depth technically what they mean and imply to a transition architecture. Bullets are simply not enough in this case for a document labeled with the word "architecture" in it. I am willing to help with this offline as I can find the spare cycles. 2.3. Transition Mechanism Deployment Considerations There are a few very important questions which must be addressed in the cases where a transition mechanism deployment is deemed necessary. For example: o if I deploy IPv6-only service, whose burden is it to enable its use by all clients I wish to make it accessible to? o if I deploy IPv6-only nodes, or dual-stack nodes with only IPv6 connectivity, whose burden is it to enable them to access all the services they want? o how much easier would it be to go for dual-stack approach instead? The intuitive answer to both of these would appear to be: "if you really want to shoot yourself in the foot, do not blame the person who sold you the gun -- or at least get prepared for a big hospital bill." Could we get technical or architecture statements to replace the above please :--) The desire to go straight to IPv6-only seems to be mainly caused by a dream of fast transition especially in some more evolved networks. However, this seems counter-productive. Important. My impression is the hot button for this draft is that nodes and networks will best be served by dual IPv4 and IPv6 layers being supported, not that the draft is against IPv6 applications being deployed or IPv6 gradually becoming dominant for network operations over time. I think this point is very important to be clear on in this work. /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 14:10:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28724 for ; Tue, 21 Oct 2003 14:10:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0xa-00065b-UB for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 14:10:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LIAMqU023390 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 14:10:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0xa-000652-CS for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 14:10:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28685 for ; Tue, 21 Oct 2003 14:10:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC0xX-0006wY-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 14:10:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC0xX-0006wU-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 14:10:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0xL-0005u0-PI; Tue, 21 Oct 2003 14:10:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0x4-0005is-0n for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 14:09:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28652 for ; Tue, 21 Oct 2003 14:09:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC0x1-0006vr-00 for ipv6@ietf.org; Tue, 21 Oct 2003 14:09:47 -0400 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by ietf-mx with esmtp (Exim 4.12) id 1AC0wr-0006vl-00 for ipv6@ietf.org; Tue, 21 Oct 2003 14:09:37 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 06B0510FA4 for ; Tue, 21 Oct 2003 14:09:37 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 21 Oct 2003 14:09:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments: draft-savola-v6ops-transarch-01.txt Date: Tue, 21 Oct 2003 14:09:36 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0512204F@tayexc13.americas.cpqcorp.net> Thread-Topic: Comments: draft-savola-v6ops-transarch-01.txt Thread-Index: AcOX/jucABtFjxrRSUKK+/Btnfb/BQAADRIw From: "Bound, Jim" To: X-OriginalArrivalTime: 21 Oct 2003 18:09:38.0397 (UTC) FILETIME=[7DC3B0D0:01C397FE] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable sorry wrong list. Please do not respond. /jim > -----Original Message----- > From: Bound, Jim [mailto:jim.bound@hp.com]=20 > Sent: Tuesday, October 21, 2003 2:08 PM > To: ipv6@ietf.org > Subject: Comments: draft-savola-v6ops-transarch-01.txt >=20 >=20 > This draft can become useful, but needs more WG discussion=20 > and I suggest we have that here and give Pekka input. =20 > Document needs spell checker for some wordsm, and sentence=20 > structure check. Also to mahy cliches used that convey no=20 > technical message to me as a reader. I think the document=20 > important but needs much more work here in the WG. >=20 > Specific Comments: >=20 > Robustness is also essential: the mechanism and the=20 > architecture must > be reliable and robust, to encourage the adoption. Also,=20 > mechanisms > must not be less robust than their IPv4 counterparts: quite the > contrary. It is highly desirable to aim for building the > architecture which does not depend on known-unreliable components > (for example, certain operational modes of IPv4 NAT's); otherwise, > the whole architecture is easily deemed unreliable. >=20 > Confused on what is trying to be said regarding IPv4 counter=20 > parts? How can an IPv6/IPv4 transition mechanism have a=20 > counter part. I get the point but this needs word-smithing=20 > to tighten up the point for robustness. Also I don't think=20 > any mechanisms proposed in our history rely on IPv4 parts=20 > that do not work well? >=20 > In absence of a plan, the transition must be made so that=20 > the future > transition options will not be end-ran, and only "safe"=20 > transitionary > actions are executed. For example, deploying dual-stack nodes with > currently only IPv4 connectivity does not end-run any transitionary > goals, but is an important step that must be done anyway. >=20 > Not sure what end-ran or end-run defines?=20 >=20 > What exactly does "safe transitonary actions" mean? >=20 > I am having a hard time parsing the point of this paragraph?=20 >=20 > Mechanisms: > o Providing IPv6 connectivity > o Protocol translation > o Application-specific protocol interoperability (ie.=20 > ALG or proxy) >=20 > Deployment models for IP nodes: > o IPv4-only > o Dual-stack with only IPv4 connectivity > o Dual-stack w/ IPv4/6 connectivity > o Dual-stack with only IPv6 connectivity > o IPv6-only >=20 > And services: > o IPv4-only > o Separate IPv4 and IPv6 > o IPv4/6 > o IPv6-only >=20 > Each of the above should be their own section with=20 > descriptions in depth technically what they mean and imply to=20 > a transition architecture. Bullets are simply not enough in=20 > this case for a document labeled with the word "architecture"=20 > in it. I am willing to help with this offline as I can find=20 > the spare cycles. >=20 > 2.3. Transition Mechanism Deployment Considerations >=20 > There are a few very important questions which must be addressed in > the cases where a transition mechanism deployment is deemed > necessary. For example: >=20 > o if I deploy IPv6-only service, whose burden is it to enable its > use by all clients I wish to make it accessible to? >=20 > o if I deploy IPv6-only nodes, or dual-stack nodes with only IPv6 > connectivity, whose burden is it to enable them to=20 > access all the > services they want? >=20 > o how much easier would it be to go for dual-stack approach > instead? >=20 > The intuitive answer to both of these would appear to be: "if you > really want to shoot yourself in the foot, do not blame the person > who sold you the gun -- or at least get prepared for a big hospital > bill." >=20 > Could we get technical or architecture statements to replace=20 > the above please :--) >=20 > The desire to go straight to IPv6-only seems to be mainly=20 > caused by a > dream of fast transition especially in some more evolved networks. > However, this seems counter-productive. >=20 > Important. My impression is the hot button for this draft is=20 > that nodes and networks will best be served by dual IPv4 and=20 > IPv6 layers being supported, not that the draft is against=20 > IPv6 applications being deployed or IPv6 gradually becoming=20 > dominant for network operations over time. I think this=20 > point is very important to be clear on in this work. >=20 > /jim >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 14:10:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28749 for ; Tue, 21 Oct 2003 14:10:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0xa-00065a-Tz for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 14:10:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LIAM6K023396 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 14:10:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0xa-00065B-Kn for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 14:10:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28688 for ; Tue, 21 Oct 2003 14:10:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC0xX-0006wb-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 14:10:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC0xW-0006wV-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 14:10:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0xI-0005m9-RT; Tue, 21 Oct 2003 14:10:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0wb-0005de-0D for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 14:09:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28604 for ; Tue, 21 Oct 2003 14:09:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC0wY-0006v6-00 for ipv6@ietf.org; Tue, 21 Oct 2003 14:09:18 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AC0wW-0006u6-00 for ipv6@ietf.org; Tue, 21 Oct 2003 14:09:16 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9LI8fL27006; Tue, 21 Oct 2003 11:08:41 -0700 X-mProtect: <200310211808> Nokia Silicon Valley Messaging Protection Received: from walnut2.iprg.nokia.com (205.226.9.199, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdQ6mvOd; Tue, 21 Oct 2003 11:08:40 PDT Message-Id: <4.3.2.7.2.20031021110715.02fee3c0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 21 Oct 2003 11:08:20 -0700 To: ipv6@ietf.org From: Bob Hinden Subject: Discussion on "IPv6 adoption behavior" Cc: Bob Hinden , Brian Haberman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , The chairs think that, while this has been an interesting discussion, it's isn't within the scope of the working group and suggest it be moved elsewhere. Lets focus our energy on completing the development of the IPv6 protocols and stop debating this issue. Regards, Bob Hinden & Brian Haberman IPv6 Chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 14:36:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29609 for ; Tue, 21 Oct 2003 14:36:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC1M2-0003Hn-VY for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 14:35:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LIZcJV012625 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 14:35:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC1M2-0003HY-RW for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 14:35:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29579 for ; Tue, 21 Oct 2003 14:35:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC1M0-0007Ht-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 14:35:36 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC1Lz-0007Hq-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 14:35:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC1LS-00034B-Rn; Tue, 21 Oct 2003 14:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC1KV-0002oL-8d for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 14:34:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29554 for ; Tue, 21 Oct 2003 14:33:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC1KS-0007H0-00 for ipv6@ietf.org; Tue, 21 Oct 2003 14:34:00 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AC1KR-0007Gw-00 for ipv6@ietf.org; Tue, 21 Oct 2003 14:33:59 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 51FCD13FCC for ; Tue, 21 Oct 2003 14:33:59 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05567-09; Tue, 21 Oct 2003 14:33:57 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 4E37B14000; Tue, 21 Oct 2003 14:33:57 -0400 (EDT) Date: Tue, 21 Oct 2003 14:27:22 -0400 From: Keith Moore To: ipv6@ietf.org Cc: moore@cs.utk.edu Subject: dubious premises: batch reply to "IPv6 adoption behavior" Message-Id: <20031021142722.5a5cbc32.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is one of my batch replies - but this time it's all on a single thread. I can't claim that this was deliberate - I went out of town for what was supposed to be a day trip, and was too ill to return for a couple of days. When I got back there were several dozen messages in this thread. It appears to me that many participants in this debate are working from one or more premises which I consider dubious: - IPv4 will eventually collapse due to address exhaustion, and/or - IPv4 will at some point become obsolete because of widespread adoption of IPv6, and/or - IPv4 will eventually be replaced by IPv6 It seems to me that the IPv4 protocol can continue to support the web (as we know it), email, and several other applications, almost indefinitely. In particular, apps that can reasonably be implemented with a relatively small number of "servers" in well-known, relatively stable locations are not significantly constrained by IPv4's addressing limitations. IPv6 will be used for other things - in particular when you need a network that supports large numbers of your own individually addressible devices. For many kinds of apps IPv6 is more efficient than IPv4. Yes, we may someday find ourselves at the point where IPv4 is nearly irrelevant because we can use IPv6 for everything for which we're using IPv4, and IPv6 has wider reach, and IPv4 is just unnecessary overhead. If and when that happens the IPv4 backbone will all but disappear fairly quickly (just like NJE/RSCS and UUCP and DECnets and X.400 networks did). We should certainly adapt our protocols so that they can use IPv6 (as we are doing) so when that day comes we will be able to reap the benefits of not running an extra network. But I don't view this as an urgent task. - IPv6 will only be adopted if/when it acquires the warts/features of IPv4 (like NAT) I believe this follows from the dubious notion that IPv6 has to "replace" IPv4. As long as people think of IPv6 as a drop-in replacement for IPv4, they'll want to solve the problems they had with IPv4 using the same techniques that were used in IPv4. But of course despite the efforts to make IPv6 semi-compatible with IPv4, and to allow it to be used with higher-layer protocols without significant changes, IPv6 is not a drop-in replacement for IPv4 - nor was this even possible to achieve. An alternative view is that IPv4 has a lot of limitations, both in the original design and in the way it evolved in practice, and there's merit in creating a new kind of network that works differently than IPv4. Many of us believe and/or hope that IPv6 will be more flexible and more universally usable than IPv4. But insisting that IPv6 inherit all of the warts of IPv4 (even while admitting that many of those warts were well-intentioned) is to defeat the utility of IPv6. This isn't a problem if you don't view IPv6 as having to replace IPv4, but instead, as a separate network that has its own characteristics and its own justifications. And precisely because deployment of IPv6 will progress more deliberately than that of IPv4, it will be easier to fix some of IPv6's problems in an architecturally sane fashion than was the case for IPv4. Note also that the view that IPv6 has to replace IPv4, warts and all, also implicitly assumes that most computers are going to continue to be as they are now - insecure, general-purpose, programmable, relatively immobile (this includes laptops) devices whose primary function is to interface a human to one or more networks of other humans and/or data. I don't see it this way at all. I believe that in 5-10 years typical Internet hosts will be: mobile phones/pdas, set-top boxes and audio/video terminals with those functions built-in, games, automobiles, power meters, traffic signals, surveillance cameras, door or window sensors, environmental monitors and controls, and transponders of various kinds. These will dwarf desktops in number. Even desktops may change significantly from the bulky, heat-producing, insecure, unreliable, expensive, maintenance-intensive, monopoly- controlled millstones around our necks that they are now. But even if the desktops continue to use IPv4 for traditional apps, that doesn't mean that there's no market for IPv6. - ISPs will change IPv6 prefixes arbitrarily ISPs don't change IPv4 prefixes arbitrarily. Rather, they use this as a means to differentiate between different levels of service. More and more ISPs offer static IPv4 addresses even to "consumer" customers - they just charge more money for it. Some ISPs choose to provide only the lowest level of service, but better levels of service are often available elsewhere. IPv6 might be seen as a higher level of service than IPv4 (and with more cost), just as actual IP access is a higher level of service than you get with some of the "free internet" providers that don't let you make arbitrary IP connections. To the extent that ISPs have incentives to change customers' IPv4 prefixes due to real or perceived IPv4 address shortages, they'll have fewer incentives to change customers' IPv6 prefixes. As long as there is a demand for stable prefixes, there will be ISPs willing to provide them. And since much of the incentive to employ IPv6 will be to address more devices, stable prefixes will be in wider demand for IPv6 than they were for IPv4. It's true that IPv6 has the built-in assumption that prefixes will change. This is really no less true for IPv4, given the limits on scalability for current routing mechanisms; the difference is that IPv6 actually has a migration strategy. At any rate, I fully expect prefix changes to be part of service agreements between ISPs and customers. - v6 NAT will emerge as the solution to real or perceived limitation of IPv6 For the forseeable future, if you can run your apps over NAT, you'll just use IPv4. Running IPv6+NAT is pointless and self-defeating. - The burden of coping with address changes should be on the applications. This is ridiculous. TCP can't cope with address changes, yet applications based on TCP are somehow expected to cope with address changes. What we need to do is to draw a line and define the degree to which applications are expected to cope with address changes, and to what degree the network is expected to keep addresses stable. We just need to pick a number - so that if an app needs to maintain a relationship with its peers lasting more than time T, it should be able to cope with address changes. We need to set this value high enough so that most apps don't need to build in the extra overhead required to make this work, and low enough that addresses can change quickly enough for the routing system to keep up with changes in network topology. - Apps have to decide whether to use IPv4 or IPv6; this is painful I believe apps fall into three classes: 1. apps that can use IPv4 or IPv6 with approximately equal ease - usually because there are only two peers involved in the application, and the choice of whether to use IPv4 or IPv6 for one pair of peers is independent of the choice for another pair. for instance, ssh. these apps should use the address that provides the best connectivity. this is little different than picking among several IPv4 addresses. 2. apps that tend toward IPv4 because they need to connect with an IPv4- based infrastructure which biases the choice of IPv4 vs. IPv6 by participating hosts. email and the web are good examples: if you want to be able to receive email, you'd better have an MX accessible via IPv4; if you want to send email to anyone, you'd better have a relay that can send SMTP over IPv4. if you want your web pages to be accessible, you'd better make them accessible via IPv4; if you want your web client to be able to access most web pages, you'd better make sure it at least has access to a proxy that can speak IPv4. 3. apps that tend toward IPv6 either because they need to connect with an IPv6-based infrastructure (e.g. they want to talk to cell phones or special-purpose devices that use v6), or because they need to avoid the limitations of IPv4+NAT. so I'll assert that for the first category of apps, choosing between IPv4 and IPv6 is just a slight variation on an old problem; and for the second two categories of apps there is a definite and fairly obvious preference between IPv4 and IPv6. the only wrinkle is that at some point in the future, some of the category 2 apps might need to move to category 3, and it might be useful to have a mechanism to tell them to do so. - having IPv6 + IPv4+NAT replace IPv4+NAT isn't very interesting on the contrary, it provides a MUCH more capable network without having to replace wires and fiber or (most) routers and hosts. IPv6 is the ultimate NAT traversal mechanism - MUCH cleaner and MUCH more flexible than RSIP, MIDCOM, or other hacks, and also extensible to many more networks and many more kinds of applications. -- Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 16:02:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05148 for ; Tue, 21 Oct 2003 16:02:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2hq-00024H-QV for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 16:02:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LK2EM6007933 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 16:02:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2hq-00022m-FJ for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 16:02:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05052 for ; Tue, 21 Oct 2003 16:02:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC2hm-0000et-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 16:02:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC2hl-0000en-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 16:02:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2fr-0000pk-3i; Tue, 21 Oct 2003 16:00:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2fB-0000Kw-JW for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 15:59:29 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04401; Tue, 21 Oct 2003 15:59:18 -0400 (EDT) Message-Id: <200310211959.PAA04401@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-jinchoi-ipv6-cra-00.txt Date: Tue, 21 Oct 2003 15:59:18 -0400 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Router Advertisement Issues for Movement Detection/ Detection of Network Attachment Author(s) : J. Choi, et. al. Filename : draft-jinchoi-ipv6-cra-00.txt Pages : 8 Date : 2003-10-21 This draft presents the Router Advertisement issues for Movement Detection/ Detection of Network Attachment. Based on [RFC-2461], the information contained in RA is inadequate for efficient Movement Detection due to inconsistency and incompleteness. This draft describes the problems concerning Movement Detection and investigates the possible solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jinchoi-ipv6-cra-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-jinchoi-ipv6-cra-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-jinchoi-ipv6-cra-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: <2003-10-21153755.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jinchoi-ipv6-cra-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-jinchoi-ipv6-cra-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-21153755.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 16:48:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05147 for ; Tue, 21 Oct 2003 16:02:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2hq-00024F-PX for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 16:02:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LK2EE2007931 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 16:02:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2hq-00022l-FG for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 16:02:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05054 for ; Tue, 21 Oct 2003 16:02:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC2hm-0000eu-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 16:02:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC2hl-0000eo-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 16:02:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2gi-0001DG-FS; Tue, 21 Oct 2003 16:01:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2fp-0000mE-Uj for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 16:00:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04544; Tue, 21 Oct 2003 15:59:58 -0400 (EDT) Message-Id: <200310211959.PAA04544@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-syam-ipv6-state-model-00.txt Date: Tue, 21 Oct 2003 15:59:58 -0400 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : State Model for IPv6 Interfaces Author(s) : S. Madanaplli, et. al. Filename : draft-syam-ipv6-state-model-00.txt Pages : 12 Date : 2003-10-21 This document specifies a generic flexible state model for IPv6 Interfaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-syam-ipv6-state-model-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-syam-ipv6-state-model-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-syam-ipv6-state-model-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: <2003-10-21153904.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-syam-ipv6-state-model-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-syam-ipv6-state-model-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-21153904.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 19:23:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18378 for ; Tue, 21 Oct 2003 19:23:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC5qE-00060n-FG for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 19:23:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LNN6KG023099 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 19:23:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC5qE-00060T-1l for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 19:23:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18303 for ; Tue, 21 Oct 2003 19:22:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC5qC-0004fH-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 19:23:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC5qB-0004fC-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 19:23:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC5pB-0005dX-Rr; Tue, 21 Oct 2003 19:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC5oK-0005JB-Jl for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 19:21:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18060; Tue, 21 Oct 2003 19:20:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC5oH-0004ah-00; Tue, 21 Oct 2003 19:21:06 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AC5oH-0004aG-00; Tue, 21 Oct 2003 19:21:05 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9LNKPN07741; Tue, 21 Oct 2003 16:20:25 -0700 X-mProtect: <200310212320> Nokia Silicon Valley Messaging Protection Received: from walnut2.iprg.nokia.com (205.226.9.199, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdWace2V; Tue, 21 Oct 2003 16:20:23 PDT Message-Id: <4.3.2.7.2.20031021161653.03732c40@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 21 Oct 2003 16:20:02 -0700 To: Margaret Wasserman , Thomas Narten From: Bob Hinden Subject: Request to Advance "MIB for the Transmission Control Protocol" Cc: ipv6@ietf.org, iesg-secretary@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Margaret, Thomas, The chairs of the IPv6 working group, on behalf of the working group, request that the following document be published as a Proposed Standard: Title : Management Information Base for the Transmission Control Protocol (TCP) Author(s) : B. Fenner et al. Filename : draft-ietf-ipv6-rfc2012-update-04.txt Pages : 25 Date : 2003-9-15 A working group last call for this document was completed on 16 July 2003. This draft resolves issues raised during the last call. Bob Hinden / Brian Haberman IPv6 Working Group Chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 19:27:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18730 for ; Tue, 21 Oct 2003 19:27:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC5u5-00073E-Q7 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 19:27:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LNR5CF027098 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 19:27:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC5u5-00072z-K6 for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 19:27:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18695 for ; Tue, 21 Oct 2003 19:26:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC5u3-0004o7-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 19:27:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC5u3-0004o4-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 19:27:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC5u2-0006yM-WB; Tue, 21 Oct 2003 19:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC5ts-0006um-OD for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 19:26:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18681 for ; Tue, 21 Oct 2003 19:26:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC5tr-0004nh-00 for ipv6@ietf.org; Tue, 21 Oct 2003 19:26:51 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AC5tp-0004nA-00 for ipv6@ietf.org; Tue, 21 Oct 2003 19:26:50 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9LNQIq13794 for ; Tue, 21 Oct 2003 16:26:18 -0700 X-mProtect: <200310212326> Nokia Silicon Valley Messaging Protection Received: from walnut2.iprg.nokia.com (205.226.9.199, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpd0FbGjg; Tue, 21 Oct 2003 16:26:15 PDT Message-Id: <4.3.2.7.2.20031021162302.02fee3c0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 21 Oct 2003 16:25:53 -0700 To: ipv6@ietf.org From: Bob Hinden Subject: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This is a IPv6 working group last call for comments on advancing the following document as an Proposed Standard: Title : Link Scoped IPv6 Multicast Addresses Author(s) : J. Park, et al. Filename : draft-ietf-ipv6-link-scoped-mcast-03.txt Pages : 5 Date : 2003-7-2 Please send substantive comments to the ipv6 mailing list, and minor editorial comments to the authors. This last call period will end on 4 November 2003. Bob Hinden / Brian Haberman -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 22:19:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23969 for ; Tue, 21 Oct 2003 22:19:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC8b2-0000Tr-Dk for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 22:19:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M2JaPV001841 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 22:19:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC8b2-0000Tc-9P for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 22:19:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23932 for ; Tue, 21 Oct 2003 22:19:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC8az-0006bX-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 22:19:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC8ay-0006bU-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 22:19:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC8aT-0000EW-6P; Tue, 21 Oct 2003 22:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC8Zu-0008VF-Jd for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 22:18:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23893 for ; Tue, 21 Oct 2003 22:18:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC8Zr-0006b9-00 for ipv6@ietf.org; Tue, 21 Oct 2003 22:18:23 -0400 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx with esmtp (Exim 4.12) id 1AC8Zq-0006aR-00 for ipv6@ietf.org; Tue, 21 Oct 2003 22:18:22 -0400 Received: from consulintel02 ([202.133.104.44]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 9-md50000000063.tmp for ; Wed, 22 Oct 2003 04:21:41 +0200 Message-ID: <008701c39843$04a32f60$7602a8c0@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <9C422444DE99BC46B3AD3C6EAFC9711B0512204A@tayexc13.americas.cpqcorp.net> Subject: Re: IPv6 adoption behavior Date: Wed, 22 Oct 2003 10:16:52 +0800 Organization: Consulintel 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 V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Wed, 22 Oct 2003 04:21:41 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 202.133.104.44 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id WAA23894 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Agree. Is misleading the same will be to say that to support IPv4 VPNs, y= ou need to change your routers. Most routers do not support VPNs, but even do, you can create the VPNs directly from the computers th= at sit inside the LANs. The same way you can create now IPv6 tunnels, regardless the routers don'= t support it. That's why we have some of the transition mechanisms ! Regards, Jordi ----- Original Message -----=20 From: "Bound, Jim" To: "M=E5ns Nilsson" ; Cc: "Dan Lanciani" Sent: Wednesday, October 22, 2003 1:35 AM Subject: RE: IPv6 adoption behavior Sorry all these vendors support IPv6 upgrades as part of OS releases: Sun= , IBM, HP, Microsoft, Cisco, Juniper, Windriver, and others. Yes some router and embedded systems hardware will require next = gen hardware. But to say that IPv6 requires a hardware upgrade is misleading and not true for most boxes deployed in the market = today. /jim > -----Original Message----- > From: M=E5ns Nilsson [mailto:mansaxel@sunet.se] > Sent: Tuesday, October 21, 2003 3:34 AM > To: ipv6@ietf.org > Cc: Dan Lanciani > Subject: Re: IPv6 adoption behavior > > > > > --On Monday, October 20, 2003 00:23:04 -0400 Dan Lanciani > wrote: > > > I strongly doubt that IPv6 will be available as a software-only > > upgrade for any but the latest equipment. There is just too little > > incentive for vendors (especially ones who have gone out of > business > > :) to support "legacy" hardware (where "legacy" seems to > mean over six > > months old). > > My SparcStation 4 machines all run v6. They were built around > 1995, iirc. We have a Cisco 7507 router in SUNET, bought > around 1996, which runs v6. > > Do you need more examples? > > --=20 > M=E5ns Nilsson Systems Specialist > +46 70 681 7204 KTHNOC MN1334-RIPE > > We're sysadmins. To us, data is a protocol-overhead. > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the use of the individ= ual(s) named above. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this infor= mation, including attached files, is prohibited. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 21 23:59:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26482 for ; Tue, 21 Oct 2003 23:59:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACA9e-0007ah-U8 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 23:59:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M3xQ3Q029173 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 23:59:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACA9e-0007aS-OM for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 23:59:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26459 for ; Tue, 21 Oct 2003 23:59:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACA9c-0007Ty-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 23:59:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACA9c-0007Tv-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 23:59:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACA9G-0007P1-F5; Tue, 21 Oct 2003 23:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACA8H-00072Q-AK for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 23:58:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26437 for ; Tue, 21 Oct 2003 23:57:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACA8E-0007T0-00 for ipv6@ietf.org; Tue, 21 Oct 2003 23:57:58 -0400 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1ACA8E-0007Sx-00 for ipv6@ietf.org; Tue, 21 Oct 2003 23:57:58 -0400 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id XAA24218; Tue, 21 Oct 2003 23:57:50 -0400 (EDT) Date: Tue, 21 Oct 2003 23:57:50 -0400 (EDT) From: Dan Lanciani Message-Id: <200310220357.XAA24218@ss10.danlan.com> To: ipv6@ietf.org Subject: Re: IPv6 adoption behavior Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Umm, since folks have decided to perpetuate this thread, I think I'm entitled to the following disclaimer. Let's see if I can make this sound all legal. :) My lack of response--in compliance with the chairs' decision to discontinue this obviously disturbing discussion--shall in no way be construed to imply agreement. Should the chairs wish to reopen any of the associated topics (or should anyone wish to consider them in some other forum of comparable scope) I'd be happy to try to clear up some of the misconceptions surrounding (but not limited to) how routing works, what NAT does, and who's upgrade analysis may be more "misleading." Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 02:51:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26715 for ; Wed, 22 Oct 2003 02:51:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACCpp-0003Bu-SA for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 02:51:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M6p9sk012264 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 02:51:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACCpp-0003Bb-8c for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 02:51:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26673 for ; Wed, 22 Oct 2003 02:50:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACCpl-0001Ah-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 02:51:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACCpl-0001Ae-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 02:51:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACCpj-00034y-9J; Wed, 22 Oct 2003 02:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACCpa-000319-RJ for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 02:50:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26669 for ; Wed, 22 Oct 2003 02:50:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACCpW-0001Ab-00 for ipv6@ietf.org; Wed, 22 Oct 2003 02:50:50 -0400 Received: from batch10.uni-muenster.de ([128.176.188.65]) by ietf-mx with esmtp (Exim 4.12) id 1ACCpW-0001AY-00 for ipv6@ietf.org; Wed, 22 Oct 2003 02:50:50 -0400 Received: from zivlnx01.uni-muenster.de (ZIVLNX01.UNI-MUENSTER.DE [128.176.188.24]) by batch10.uni-muenster.de (Postfix) with ESMTP id 0791A27B1; Wed, 22 Oct 2003 08:50:12 +0200 (MES) Received: from localhost (localhost.uni-muenster.de [127.0.0.1]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id BECAF312D3; Wed, 22 Oct 2003 08:50:10 +0200 (CEST) Received: from kummerog.uni-muenster.de (KUMMEROG.UNI-MUENSTER.DE [128.176.184.156]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id 0DA23312C9; Wed, 22 Oct 2003 08:50:10 +0200 (CEST) Subject: Re: IPv6 adoption behavior From: "Christian Strauf (JOIN)" To: Tim Chown Cc: ipv6@ietf.org In-Reply-To: <1066804980.9292.23.camel@kummerog.uni-muenster.de> References: <20031021143041.GM27817@login.ecs.soton.ac.uk> <1066804980.9292.23.camel@kummerog.uni-muenster.de> Content-Type: text/plain; charset=iso-8859-15 Organization: JOIN-Team, WWU-Muenster Message-Id: <1066805450.9289.28.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 22 Oct 2003 08:50:50 +0200 X-Virus-Scanned: by AMaViS 0.3.12pre7 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA26670 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sorry for posting this comment, I saw the IPv6 Chairs' mail too late. Christian --=20 JOIN - IP Version 6 in the WiN Christian Strauf A DFN project Westf=E4lische Wilhelms-Universit=E4t M=FC= nster http://www.join.uni-muenster.de Zentrum f=FCr Informationsverarbeitung Team: join@uni-muenster.de R=F6ntgenstrasse 9-13 Priv: strauf@uni-muenster.de D-48149 M=FCnster / Germany GPG-/PGP-Key-ID: 1DFAAA9A Fon: +49 251 83 31639, Fax: +49 251 83 31= 653 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 05:17:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00217 for ; Wed, 22 Oct 2003 05:17:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACF7b-0006R6-4i for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 05:17:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M9HciN024702 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 05:17:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACF7a-0006QL-PS for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 05:17:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00176 for ; Wed, 22 Oct 2003 05:17:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACF7X-0002Ue-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 05:17:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACF7X-0002Ua-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 05:17:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACF70-00068T-3t; Wed, 22 Oct 2003 05:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACF6h-000648-Pi for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 05:16:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00137 for ; Wed, 22 Oct 2003 05:16:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACF6e-0002To-00 for ipv6@ietf.org; Wed, 22 Oct 2003 05:16:40 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1ACF6d-0002TI-00 for ipv6@ietf.org; Wed, 22 Oct 2003 05:16:39 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9M9G9xA029612; Wed, 22 Oct 2003 02:16:09 -0700 (PDT) Received: from lillen (vpn-129-156-97-186.EMEA.Sun.COM [129.156.97.186]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9M9G6S01509; Wed, 22 Oct 2003 11:16:07 +0200 (MEST) Date: Wed, 22 Oct 2003 11:09:57 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses" To: Bob Hinden Cc: ipv6@ietf.org In-Reply-To: "Your message with ID" <4.3.2.7.2.20031021162302.02fee3c0@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , The document says: scop <= 2. The value of this multicast address is necessary to distinguish between an Interface ID-based multicast address and a unicast-prefix-based multicast address. If scop <= 2, the former MUST be used. That is, this document updates the [RFC 3306], which describes the latter. I'm trying to understand why the RFC 3306 are so broken for scope <=2 that they can not be used. While using the new address format for scope <= 2 would presumably be preferred I don't see why prohibiting (as the "MUST" above does) the use of RFC 3306 for those scopes. If prohibiting them is the right thing I think the document should state why. The example says: This is an example of an interface ID-based multicast address with link-local scope. For example in an Ethernet environment, if the link-local unicast address is FE80::12:34:56:78:90:AB, the multicast prefix of the host is FF32:0:1234:56FF:FE78:90AB::/96. For SSM, multicast address will be FF32::/96. Typo (I think): FE80::12:34:56:78:90:AB should be FE80::1234:5678:90AB and a better example would have a 64 bit iid (the above one has 16 leading zeros). Such as FE80::a12:34ff:fe56:7890 resulting in FF32:0:a12:34ff:fe56:7890::/96 Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 06:05:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01599 for ; Wed, 22 Oct 2003 06:05:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACFrE-0001xw-5h for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 06:04:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MA4mib007550 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 06:04:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACFrD-0001xh-V5 for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 06:04:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01536 for ; Wed, 22 Oct 2003 06:04:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACFr5-0002uP-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 06:04:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACFr4-0002uM-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 06:04:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACFqV-0001fP-Mt; Wed, 22 Oct 2003 06:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACFpy-0001WV-3u for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 06:03:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01493 for ; Wed, 22 Oct 2003 06:03:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACFpp-0002tG-00 for ipv6@ietf.org; Wed, 22 Oct 2003 06:03:21 -0400 Received: from [211.238.35.25] (helo=kisang.co.kr) by ietf-mx with smtp (Exim 4.12) id 1ACFpm-0002su-00 for ipv6@ietf.org; Wed, 22 Oct 2003 06:03:19 -0400 Received: (qmail 6346 invoked from network); 22 Oct 2003 10:16:01 -0000 Received: from unknown (HELO willnote) (211.238.35.62) by 0 with SMTP; 22 Oct 2003 10:16:01 -0000 From: "Jisuek.Lim" To: Subject: A host who has private IPv4 address can communicate with IPv6 host globaly by 6to4 tunnel Date: Wed, 22 Oct 2003 19:03:44 +0900 Message-ID: <000001c39883$c7471cd0$3c01a8c0@willnote> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C398CF.37304B70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C398CF.37304B70 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello all, I have a idea about communication method with 6to4 tunnel. Generally, we think a host who has private IPv4 address(because it is behind NAT device) can not communicate with IPv6 host globally by tunneling(6to4, config tunnel ..) But there is a way using 6to4 tunnel. When we config 6to4 config on a host(for example windows2000 station) we assign the host=92s IPv4 address to the host=92s 6to4 address(next to 2002:). And we know the host=92s IPv4 address shoud be public IPv4 address.=20 But, if we use the public IPv4 address which is on NAT device=92s = external interface to make the host=92s 6to4 address, the host can communicate = with IPv6 host globally using 6to4 tunnel and relay router. Following are do list. 1. Map the NAT device=92s public address(select one) to the = host=92s private address(configure on the NAT) 2. On the NAT device, make a policy which permit incomming traffic which has protocol number 41 to the host=92s private address 3. Change the NAT device=92s public IPv4 address(which you = selected) to hex. format. 4. Configure the host=92s 6to4 address using upper hex. 5. Add route table for 2002 traffic to tunnel interface, and ::/0 to relay router(relay router is provided by some orgnization) =20 And then,...try ping6 to any IPv6 address. following is the result of my own test. =20 C:\>ping6 6to4.ipv6.fh-regensburg.de Pinging 6to4.ipv6.fh-regensburg.de [2002:c25f:6cbf:1::1] with 32 bytes of data: =20 Reply from 2002:c25f:6cbf:1::1: bytes=3D32 time=3D330ms Reply from 2002:c25f:6cbf:1::1: bytes=3D32 time=3D329ms Reply from 2002:c25f:6cbf:1::1: bytes=3D32 time=3D329ms =20 C:\> C:\>ping6 www.kame.net =20 Pinging orange.kame.net [2001:200:0:8002:203:47ff:fea5:3085] with 32 bytes of data: =20 Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=3D32 time=3D117ms Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=3D32 time=3D72ms Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=3D32 time=3D68ms Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=3D32 time=3D71ms =20 C:\> =20 Following is my computer=92s IP config =20 C:\>ipconfig =20 Windows 2000 IP Configuration =20 Ethernet adapter :=20 =20 Connection-specific DNS Suffix . : IP Address. . . . . . . . . . . . : 192.168.1.60 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.1.254 =20 C:\> =20 as you know 192.168.1.60 is private address !! Try it. Thanks. Jisuek. Lim ------=_NextPart_000_0001_01C398CF.37304B70 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hello = all,

I have a = idea about communication method with 6to4 tunnel.

Generally, we think a host who has = private IPv4 address(because it is behind NAT device) = can not communicate with IPv6 host globally by tunneling(6to4, config tunnel ..) = But there is a way using 6to4 tunnel.

When we config 6to4 config on a host(for example windows2000 station) we assign the = host=92s IPv4 address to the host=92s 6to4 address(next to 2002:). And we = know the host=92s IPv4 address shoud be public IPv4 address. =

But, if we use the public IPv4 address = which is on NAT device=92s external interface to make the = host=92s 6to4 address, the host can communicate with IPv6 host globally using = 6to4 tunnel and relay router. Following are do = list.

1.       Map the NAT device=92s public address(select one) to the host=92s private address(configure on the = NAT)

2.       On the NAT device, make a policy which = permit incomming traffic which has protocol number 41 to the = host=92s private address

3.       Change the NAT = device=92s public IPv4 address(which you selected) to = hex. format.

4.       Configure the host=92s 6to4 address using upper hex.

5.       Add route table for 2002 traffic to = tunnel interface, and ::/0 to relay router(relay router is provided by some orgnization)

 

And then,...try ping6 to any IPv6 address. following is the = result of my own test.

 

C:\>ping6 = 6to4.ipv6.fh-regensburg.de

Pinging 6to4.ipv6.fh-regensburg.de [2002:c25f:6cbf:1::1] with 32 bytes of = data:

 

Reply from 2002:c25f:6cbf:1::1: bytes=3D32 = time=3D330ms

Reply from 2002:c25f:6cbf:1::1: bytes=3D32 = time=3D329ms

Reply from 2002:c25f:6cbf:1::1: bytes=3D32 = time=3D329ms

 

C:<= /span>\>

C:\>ping6 = www.kame.net

 

Pinging orange.kame.net [2001:200:0:8002:203:47ff:fea5:3085] with 32 bytes of = data:

 

Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=3D32 = time=3D117ms

Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=3D32 = time=3D72ms

Reply from = 2001:200:0:8002:203:47ff:fea5:3085: bytes=3D32 time=3D68ms

Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=3D32 = time=3D71ms

 

C:<= /span>\>

 

Following is my = computer=92s IP config

 

C:\>ipconfig

 

Windows 2000 IP = Configuration

 

Ethernet adapter = :

 

=A0=A0=A0=A0=A0=A0=A0 Connection-specific DNS Suffix=A0 = . :

=A0=A0=A0=A0=A0=A0=A0 IP Address. . . . . . . . . . . . : 192.168.1.60

=A0=A0=A0=A0=A0=A0=A0 Subnet Mask . . . . . . . . . . . : = 255.255.255.0

=A0=A0=A0=A0=A0=A0=A0 Default Gateway . . . . . . . . . : = 192.168.1.254

 

C:<= /span>\>

 

as<= /span> you know 192.168.1.60 is private address !!

Try it.

Thanks.

Jisuek. Lim

------=_NextPart_000_0001_01C398CF.37304B70-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 06:29:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02676 for ; Wed, 22 Oct 2003 06:29:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACGFE-0007yo-Fo for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 06:29:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MATax8030671 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 06:29:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACGFC-0007yY-80 for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 06:29:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02655 for ; Wed, 22 Oct 2003 06:29:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACGF8-0003JV-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 06:29:30 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACGF7-0003JS-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 06:29:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACGEg-0007pA-Jz; Wed, 22 Oct 2003 06:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACGEF-0007lE-To for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 06:28:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02644 for ; Wed, 22 Oct 2003 06:28:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACGEB-0003Im-00 for ipv6@ietf.org; Wed, 22 Oct 2003 06:28:31 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACGEB-0003Ij-00 for ipv6@ietf.org; Wed, 22 Oct 2003 06:28:31 -0400 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA19726 for ; Wed, 22 Oct 2003 11:28:31 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA07918 for ; Wed, 22 Oct 2003 11:28:31 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h9MASVE08365 for ipv6@ietf.org; Wed, 22 Oct 2003 11:28:31 +0100 Date: Wed, 22 Oct 2003 11:28:31 +0100 From: Tim Chown To: ipv6@ietf.org Subject: Re: A host who has private IPv4 address can communicate with IPv6 host globaly by 6to4 tunnel Message-ID: <20031022102831.GI6932@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <000001c39883$c7471cd0$3c01a8c0@willnote> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c39883$c7471cd0$3c01a8c0@willnote> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi, Yes, this will work. This technique is quite widely used, and is one reason for this draft: http://www.ietf.org/internet-drafts/draft-palet-v6ops-proto41-nat-01.txt Essentially you forward the protocol 41 from the NAT to the internal host. It is quite a popular "trick" with our students in their home DSL LANs. The problem is that this only works for one host within the NAT network, so if the NAT encompasses many sites, you're stuck. Cheers, Tim On Wed, Oct 22, 2003 at 07:03:44PM +0900, Jisuek.Lim wrote: > > Hello all, > > I have a idea about communication method with 6to4 tunnel. > > Generally, we think a host who has private IPv4 address(because it is > behind NAT device) can not communicate with IPv6 host globally by > tunneling(6to4, config tunnel ..) But there is a way using 6to4 > tunnel. > > When we config 6to4 config on a host(for example windows2000 station) > we assign the host's IPv4 address to the host's 6to4 address(next to > 2002:). And we know the host's IPv4 address shoud be public IPv4 > address. > > But, if we use the public IPv4 address which is on NAT device's > external interface to make the host's 6to4 address, the host can > communicate with IPv6 host globally using 6to4 tunnel and relay > router. Following are do list. > > 1. Map the NAT device's public address(select one) to the host's > private address(configure on the NAT) > > 2. On the NAT device, make a policy which permit incomming > traffic which has protocol number 41 to the host's private address > > 3. Change the NAT device's public IPv4 address(which you > selected) to hex. format. > > 4. Configure the host's 6to4 address using upper hex. > > 5. Add route table for 2002 traffic to tunnel interface, and > ::/0 to relay router(relay router is provided by some orgnization) > > > And then,...try ping6 to any IPv6 address. following is the result of > my own test. > > > C:\>ping6 6to4.ipv6.fh-regensburg.de > > Pinging 6to4.ipv6.fh-regensburg.de [2002:c25f:6cbf:1::1] with 32 bytes > of data: > > > Reply from 2002:c25f:6cbf:1::1: bytes=32 time=330ms > > Reply from 2002:c25f:6cbf:1::1: bytes=32 time=329ms > > Reply from 2002:c25f:6cbf:1::1: bytes=32 time=329ms > > > C:\> > > C:\>ping6 www.kame.net > > > Pinging orange.kame.net [2001:200:0:8002:203:47ff:fea5:3085] with 32 > bytes of data: > > > Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=117ms > > Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=72ms > > Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=68ms > > Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=71ms > > > C:\> > > > Following is my computer's IP config > > > C:\>ipconfig > > > Windows 2000 IP Configuration > > > Ethernet adapter : > > > Connection-specific DNS Suffix . : > > IP Address. . . . . . . . . . . . : 192.168.1.60 > > Subnet Mask . . . . . . . . . . . : 255.255.255.0 > > Default Gateway . . . . . . . . . : 192.168.1.254 > > > C:\> > > > as you know 192.168.1.60 is private address !! > > Try it. > > Thanks. > > Jisuek. Lim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 06:59:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03193 for ; Wed, 22 Oct 2003 06:59:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACGi2-0006xR-5h for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 06:59:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MAxMlX026731 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 06:59:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACGi1-0006x1-9y for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 06:59:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03130 for ; Wed, 22 Oct 2003 06:59:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACGhw-0003Xv-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 06:59:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACGhw-0003Xs-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 06:59:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACGhi-0006l2-0g; Wed, 22 Oct 2003 06:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACGhA-0006Xg-9G for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 06:58:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03122 for ; Wed, 22 Oct 2003 06:58:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACGh5-0003Wn-00 for ipv6@ietf.org; Wed, 22 Oct 2003 06:58:24 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1ACGh5-0003Wc-00 for ipv6@ietf.org; Wed, 22 Oct 2003 06:58:23 -0400 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h9MAvrV08366 for ; Wed, 22 Oct 2003 03:57:53 -0700 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h9MB09tX032431 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 22 Oct 2003 04:00:12 -0700 Message-ID: <3F96629C.1090809@innovationslab.net> Date: Wed, 22 Oct 2003 06:57:32 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is a IPv6 working group last call for comments on advancing the following document as an Proposed Standard: Title : Deprecating Site Local Addresses Author(s) : C. Huitema, B. Carpenter Filename : draft-ietf-ipv6-deprecate-site-local-01.txt Pages : 10 Date : 2003-10-13 Please send substantive comments to the ipv6 mailing list, and minor editorial comments to the authors. This last call period will end on 4 November 2003. Brian Haberman / Bob Hinden IPv6 W.G. Chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 07:07:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03473 for ; Wed, 22 Oct 2003 07:07:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACGpd-0000VM-Q7 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 07:07:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MB7D0m001932 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 07:07:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACGpd-0000Ut-6m for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 07:07:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03437 for ; Wed, 22 Oct 2003 07:07:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACGpY-0003eK-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 07:07:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACGpY-0003eH-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 07:07:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACGpT-0000Lp-9H; Wed, 22 Oct 2003 07:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACGp8-0000J4-0J for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 07:06:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03417 for ; Wed, 22 Oct 2003 07:06:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACGp3-0003dl-00 for ipv6@ietf.org; Wed, 22 Oct 2003 07:06:37 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1ACGp2-0003dS-00 for ipv6@ietf.org; Wed, 22 Oct 2003 07:06:36 -0400 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h9MB67V08757 for ; Wed, 22 Oct 2003 04:06:07 -0700 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h9MB8MtX000352 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 22 Oct 2003 04:08:26 -0700 Message-ID: <3F96648C.6050302@innovationslab.net> Date: Wed, 22 Oct 2003 07:05:48 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is a IPv6 working group last call for comments on advancing the following document as an Proposed Standard: Title : IPv6 Scoped Address Architecture Author(s) : S. Deering et al. Filename : draft-ietf-ipv6-scoping-arch-00.txt Pages : 22 Date : 2003-6-24 Please send substantive comments to the ipv6 mailing list, and minor editorial comments to the authors. This last call period will end on 4 November 2003. Brian Haberman / Bob Hinden IPv6 W.G. Chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 08:33:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05808 for ; Wed, 22 Oct 2003 08:33:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIAv-0003HD-Q0 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 08:33:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MCXHWb012582 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 08:33:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIAt-0003Gp-4g for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 08:33:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05755 for ; Wed, 22 Oct 2003 08:33:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACIAr-0004Tc-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 08:33:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACIAr-0004TY-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 08:33:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIAg-000312-5F; Wed, 22 Oct 2003 08:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIAK-0002sX-VC for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 08:32:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05727 for ; Wed, 22 Oct 2003 08:32:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACIAJ-0004TF-00 for ipv6@ietf.org; Wed, 22 Oct 2003 08:32:39 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1ACIAI-0004T8-00 for ipv6@ietf.org; Wed, 22 Oct 2003 08:32:39 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9MCWYPh023484; Wed, 22 Oct 2003 06:32:35 -0600 (MDT) Received: from lillen (vpn-129-156-97-186.EMEA.Sun.COM [129.156.97.186]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9MCWWS04378; Wed, 22 Oct 2003 14:32:32 +0200 (MEST) Date: Wed, 22 Oct 2003 14:26:24 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses" To: jspark@pec.etri.re.kr Cc: "'Erik Nordmark'" , "'Bob Hinden'" , ipv6@ietf.org In-Reply-To: "Your message with ID" <200310221138.h9MBcjJ5023218@pec.etri.re.kr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > In my memory, > IPv6 guys also agreed on our view during the 54th IETF meeting. > > I think .. > RFC3306 needs allocation server of 32bit goup ID > in order to support the uniqueness in the site. > This site is identified by network prefix. > > But, > Group ID Autoconfiguration in link-scope will be valuable > without help of allocation server. > Each node in our draft allocates group ID independently. I understand that link-scope has benefits over unicast-prefix for scope <=2. So saying "it is preferred to use ..." or "recommended" would seem ok. But saying "MUST" - meaning a prohibitation of using unicast-prefix - seems much to strong unless there are arguments that unicast-prefix is "broken" (not just "suboptimal") for those scopes. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 09:07:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07230 for ; Wed, 22 Oct 2003 09:07:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIht-0002aK-QE for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 09:07:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MD7LgT009929 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 09:07:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIht-0002Zw-8O for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 09:07:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07197 for ; Wed, 22 Oct 2003 09:07:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACIhr-0004tJ-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 09:07:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACIhr-0004tF-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 09:07:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIhZ-0002NB-Rb; Wed, 22 Oct 2003 09:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIgk-0002C5-Ne for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 09:06:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07170 for ; Wed, 22 Oct 2003 09:06:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACIgj-0004sd-00 for ipv6@ietf.org; Wed, 22 Oct 2003 09:06:09 -0400 Received: from [195.167.170.152] (helo=bowl.fysh.org ident=mail) by ietf-mx with esmtp (Exim 4.12) id 1ACIgh-0004sU-00 for ipv6@ietf.org; Wed, 22 Oct 2003 09:06:07 -0400 Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 1ACIgX-0004IG-00 for ; Wed, 22 Oct 2003 14:05:57 +0100 Date: Wed, 22 Oct 2003 14:05:57 +0100 To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Message-ID: <20031022130557.GB5583@fysh.org> References: <3F96659F.4040702@innovationslab.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F96659F.4040702@innovationslab.net> User-Agent: Mutt/1.3.28i From: Zefram Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Brian Haberman wrote: > Filename : draft-ietf-ipv6-unique-local-01.txt That should be draft-ietf-ipv6-unique-local-addr-01.txt. Section 3.1 is still written from the point of view of having no definitely determined format prefix, which is appropriate for discussion but not in a Proposed Standard. It should be changed to state exactly what prefix is to be used. I don't think anyone's objected to fc00::/7. Section 3.2: "The Global ID is split into two parts for each type of allocation." should be "The Global ID space is split into two parts, one for each type of allocation.". Section 3.2.2/3.2.3: I *think* I understand what is intended by the phrase "a functionally similar algorithm", but I think it would be worthwhile giving a second example algorithm, to give some idea of the latitude that is intended. My understanding is that "(ntpdate -qd localhost; ifconfig) | md5sum | cut -c1-10" would be an acceptable implementation, although it differs in many details from the algorithm of section 3.2.3. Section 3.2.4: the probabilities quoted such as "4.54**-11" are presumably intended to be "4.54*10^-11" and so on. All the top-leve section numbers have a ".0" appended that doesn't belong there. -zefram -- Andrew Main (Zefram) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 10:21:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11413 for ; Wed, 22 Oct 2003 10:21:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJrl-0003Jq-JL for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 10:21:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MELb3a012754 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 10:21:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJrl-0003Jc-Dz for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 10:21:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11382 for ; Wed, 22 Oct 2003 10:21:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACJrh-0005qD-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 10:21:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACJrh-0005qA-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 10:21:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJrD-00037q-4C; Wed, 22 Oct 2003 10:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJqI-0002tS-K7 for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 10:20:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11342 for ; Wed, 22 Oct 2003 10:19:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACJqG-0005pF-00 for ipv6@ietf.org; Wed, 22 Oct 2003 10:20:04 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACJqF-0005oe-00 for ipv6@ietf.org; Wed, 22 Oct 2003 10:20:03 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9MEJN915339 for ; Wed, 22 Oct 2003 17:19:24 +0300 Date: Wed, 22 Oct 2003 17:19:23 +0300 (EEST) From: Pekka Savola To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses" In-Reply-To: <4.3.2.7.2.20031021162302.02fee3c0@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi, On Tue, 21 Oct 2003, Bob Hinden wrote: > This is a IPv6 working group last call for comments on advancing the > following document as an Proposed Standard: > > Title : Link Scoped IPv6 Multicast Addresses > Author(s) : J. Park, et al. > Filename : draft-ietf-ipv6-link-scoped-mcast-03.txt > Pages : 5 > Date : 2003-7-2 [...] There are a large number of things to be said, but I'll just stick to two main points. I've never seen much use for this specification, and I do not believe this specification is useful as is. It should be replaced by Informational guidance how to use "vanilla" RFC3306 to generate the addresses the nodes want, or by the a specification of link-scoped multicast DAD. Further, as currently written, the addresses generated are from Source Specific Multicast range, rendering them practically useless for the purposes of the memo. 1) I've never seen a justified reason why this is useful. Apparently, the document aims to allow a node to generate unique link-scoped multicast addresses autonomously, without any user input, without a fear of collision or any additional mechanisms. First, there is no guarantee of uniqueness in the first place, as DAD on the IPv6 link-local unicast address was performed on the address, not the Interface-ID. In practice, the collisions should be very rare, though. Second, considering that there is no guaranteed uniqueness, what harm is there to generate the addresses as currently specified in RFC3306, like: - take the prefix of a link-local address (e.g. fe80::/64, or fe80::/10) - put it in RFC3306 address, like FF32:40:fe80:: or FF32:A:fe80::. this would leave 64 bits space to generate an address, assuming the group-id is 32. - the 64 bits () could be the interface ID of the link-local address, or something else completely, like a random number. Ergo, there seems to be zero need to specify an update for RFC3306, it can already provide for a mechanism to allocate the link-local multicast addresses. Third, if we want to go down this particular path, a better solution would probably be to create a generic "multicast DAD" mechanism to verify the uniqueness of a group either on a link, or within a multicast scope. If the applicability would be on the link, even unicast DAD mechanisms could be reused. 2) the current spec uses the reserved field in such a fashion that plen=0 and the other nodes not implementing this spec will interpret the link-local multicast addresses generated using this spec as SSM addresses. The problem with this is that the SSM implementations need to have new special code for the treatment of scope=2 and plen != 60. This will result in inconsistent behaviour, and is counter-productive. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 10:37:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12297 for ; Wed, 22 Oct 2003 10:37:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACK6z-0007EW-Nt for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 10:37:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MEbLGV027793 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 10:37:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACK6y-0007DY-Fh for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 10:37:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12272 for ; Wed, 22 Oct 2003 10:37:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACK6w-00068z-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 10:37:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACK6v-00068w-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 10:37:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACK6g-00074J-2E; Wed, 22 Oct 2003 10:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACK64-0006wU-5H for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 10:36:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12244 for ; Wed, 22 Oct 2003 10:36:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACK61-00068N-00 for ipv6@ietf.org; Wed, 22 Oct 2003 10:36:21 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACK60-00067i-00 for ipv6@ietf.org; Wed, 22 Oct 2003 10:36:21 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9MEZmn15754 for ; Wed, 22 Oct 2003 17:35:48 +0300 Date: Wed, 22 Oct 2003 17:35:47 +0300 (EEST) From: Pekka Savola To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Wed, 22 Oct 2003, Pekka Savola wrote: > - put it in RFC3306 address, like FF32:40:fe80:: or > FF32:A:fe80::. > this would leave 64 bits space to generate an address, assuming the > group-id is 32. > - the 64 bits () could be the interface ID of the link-local > address, or something else completely, like a random number. oops.. a miscalculation; this would leave (about) 48 bits for "stuff" rather than 64.. assuming the group-id would be 32, which it wouldn't need to be. regardless of that, the point seems valid: there seem to be little need for this spec. of course, the simplest way would be use the about 48 bits or 80 bits to randomly generate an address. The collision probability is insignificant. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 11:53:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15362 for ; Wed, 22 Oct 2003 11:53:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLHr-0002aF-Ln for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 11:52:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MFqdY2009925 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 11:52:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLHr-0002a0-HI for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 11:52:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15330 for ; Wed, 22 Oct 2003 11:52:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACLHq-00071z-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 11:52:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACLHp-00071w-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 11:52:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLHF-0002QT-Mj; Wed, 22 Oct 2003 11:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLH0-0002OK-1w for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 11:51:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15303 for ; Wed, 22 Oct 2003 11:51:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACLGy-00071K-00 for ipv6@ietf.org; Wed, 22 Oct 2003 11:51:44 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1ACLGy-00071D-00 for ipv6@ietf.org; Wed, 22 Oct 2003 11:51:44 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9MFpf5u008987; Wed, 22 Oct 2003 09:51:41 -0600 (MDT) Received: from lillen (vpn-129-156-97-186.EMEA.Sun.COM [129.156.97.186]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9MFpcS11430; Wed, 22 Oct 2003 17:51:39 +0200 (MEST) Date: Wed, 22 Oct 2003 17:51:37 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" To: Brian Haberman Cc: ipv6@ietf.org In-Reply-To: "Your message with ID" <3F96659F.4040702@innovationslab.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > This is a IPv6 working group last call for comments on advancing the > following document as an Proposed Standard: > > Title : Unique Local IPv6 Unicast Addresses > Author(s) : R. Hinden, B. Haberman > Filename : draft-ietf-ipv6-unique-local-01.txt I assume the last call is on the draft named draft-ietf-ipv6-unique-local-addr-01.txt > - In practice, applications may treat these address like global > scoped addresses. I don't see how this can be true in general. Here is an example using referrals; the three nodes involved are A, B, C. Node A and B are in the same site, have both local and global addresses, and C is in a different site. Node A and B are communicating using these local addresses. In particular, B contacted A using FQDN(A) and the naming system somehow so that they ended up communcating with local addresses. (My understanding is that part of the benefit of these local addresses is that local communication prefer using local addresses over global addresses.) As a result the only thing A knows about B is its local address AL(B). C contacts A using A's global address. Node A needs to refer C to communicate with B; it sends B's address (AL(B)) to see. But C can't reach that address since it is not in the same site. This type of problem doesn't appear when using global addresses even if each node has multiple global addresses. Thus I don't think the above statement and section 8 in the document are incorrect. The fundamental difference between unique local addresses and global addresses is that the former are permentently unreachable by design (except from the local domain) whereas the latter might be temporarily unreachable due to some failure. I believe this means that applications need to be aware of the difference between the two types. Hence not ready for proposed standard IMHO. BTW: what is the expected interaction between this and mobile IPv6? Is it different for mobile nodes that move within their home site, and mobile nodes which move outside their home site? Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 11:56:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15507 for ; Wed, 22 Oct 2003 11:56:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLLL-0003H1-CA for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 11:56:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MFuFlN012577 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 11:56:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLLL-0003Gm-5u for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 11:56:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15478 for ; Wed, 22 Oct 2003 11:56:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACLLJ-00075A-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 11:56:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACLLJ-000757-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 11:56:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLL8-0003A7-PH; Wed, 22 Oct 2003 11:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLKr-000381-2l for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 11:55:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15472 for ; Wed, 22 Oct 2003 11:55:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACLKp-000751-00 for ipv6@ietf.org; Wed, 22 Oct 2003 11:55:43 -0400 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx with esmtp (Exim 4.12) id 1ACLKo-00074L-00 for ipv6@ietf.org; Wed, 22 Oct 2003 11:55:43 -0400 Received: from consulintel02 ([202.133.104.44]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 13-md50000000087.tmp for ; Wed, 22 Oct 2003 17:58:53 +0200 Message-ID: <027c01c398b5$2a030790$c102a8c0@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <000001c39883$c7471cd0$3c01a8c0@willnote> <20031022102831.GI6932@login.ecs.soton.ac.uk> Subject: Re: A host who has private IPv4 address can communicate with IPv6 host globaly by 6to4 tunnel Date: Wed, 22 Oct 2003 23:57:10 +0800 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Wed, 22 Oct 2003 17:58:53 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 202.133.104.44 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In fact, it will be very good if you can tell me (private email to avoid brands/models here) what router or NAT box are you using, so I can include it in my survey. Same for other people that has used this ;-) Regards, Jordi PS: By the way, yes, you can use any of the computers after the NAT as the IPv6 router. I'm doing it right now, in my hotel room, and I see some other people using my IPv6 prefix, for free, being my laptop the router ! You can read the last draft (-02 waiting in the editors queue) and also this document http://www.euro6ix.org/documentation/euro6ix_co_upm-consulintel_wp4_ipv6_tunnels_nat_v1_6.pdf. ----- Original Message ----- From: "Tim Chown" To: Sent: Wednesday, October 22, 2003 6:28 PM Subject: Re: A host who has private IPv4 address can communicate with IPv6 host globaly by 6to4 tunnel > Hi, > > Yes, this will work. This technique is quite widely used, and is one > reason for this draft: > http://www.ietf.org/internet-drafts/draft-palet-v6ops-proto41-nat-01.txt > > Essentially you forward the protocol 41 from the NAT to the internal host. > > It is quite a popular "trick" with our students in their home DSL LANs. > > The problem is that this only works for one host within the NAT network, > so if the NAT encompasses many sites, you're stuck. > > Cheers, > Tim > > On Wed, Oct 22, 2003 at 07:03:44PM +0900, Jisuek.Lim wrote: > > > > Hello all, > > > > I have a idea about communication method with 6to4 tunnel. > > > > Generally, we think a host who has private IPv4 address(because it is > > behind NAT device) can not communicate with IPv6 host globally by > > tunneling(6to4, config tunnel ..) But there is a way using 6to4 > > tunnel. > > > > When we config 6to4 config on a host(for example windows2000 station) > > we assign the host's IPv4 address to the host's 6to4 address(next to > > 2002:). And we know the host's IPv4 address shoud be public IPv4 > > address. > > > > But, if we use the public IPv4 address which is on NAT device's > > external interface to make the host's 6to4 address, the host can > > communicate with IPv6 host globally using 6to4 tunnel and relay > > router. Following are do list. > > > > 1. Map the NAT device's public address(select one) to the host's > > private address(configure on the NAT) > > > > 2. On the NAT device, make a policy which permit incomming > > traffic which has protocol number 41 to the host's private address > > > > 3. Change the NAT device's public IPv4 address(which you > > selected) to hex. format. > > > > 4. Configure the host's 6to4 address using upper hex. > > > > 5. Add route table for 2002 traffic to tunnel interface, and > > ::/0 to relay router(relay router is provided by some orgnization) > > > > > > And then,...try ping6 to any IPv6 address. following is the result of > > my own test. > > > > > > C:\>ping6 6to4.ipv6.fh-regensburg.de > > > > Pinging 6to4.ipv6.fh-regensburg.de [2002:c25f:6cbf:1::1] with 32 bytes > > of data: > > > > > > Reply from 2002:c25f:6cbf:1::1: bytes=32 time=330ms > > > > Reply from 2002:c25f:6cbf:1::1: bytes=32 time=329ms > > > > Reply from 2002:c25f:6cbf:1::1: bytes=32 time=329ms > > > > > > C:\> > > > > C:\>ping6 www.kame.net > > > > > > Pinging orange.kame.net [2001:200:0:8002:203:47ff:fea5:3085] with 32 > > bytes of data: > > > > > > Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=117ms > > > > Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=72ms > > > > Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=68ms > > > > Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=71ms > > > > > > C:\> > > > > > > Following is my computer's IP config > > > > > > C:\>ipconfig > > > > > > Windows 2000 IP Configuration > > > > > > Ethernet adapter : > > > > > > Connection-specific DNS Suffix . : > > > > IP Address. . . . . . . . . . . . : 192.168.1.60 > > > > Subnet Mask . . . . . . . . . . . : 255.255.255.0 > > > > Default Gateway . . . . . . . . . : 192.168.1.254 > > > > > > C:\> > > > > > > as you know 192.168.1.60 is private address !! > > > > Try it. > > > > Thanks. > > > > Jisuek. Lim > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 12:00:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15713 for ; Wed, 22 Oct 2003 12:00:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLPK-00045Y-7l for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 12:00:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MG0MAG015710 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 12:00:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLPI-000453-N0 for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 12:00:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15636 for ; Wed, 22 Oct 2003 12:00:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACLPH-00078m-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 12:00:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACLPG-00078j-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 12:00:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLP6-0003xf-19; Wed, 22 Oct 2003 12:00:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLOs-0003uo-73 for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 11:59:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15609 for ; Wed, 22 Oct 2003 11:59:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACLOq-00078H-00 for ipv6@ietf.org; Wed, 22 Oct 2003 11:59:52 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACLOq-00078E-00 for ipv6@ietf.org; Wed, 22 Oct 2003 11:59:52 -0400 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA05186 for ; Wed, 22 Oct 2003 16:59:48 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA28535 for ; Wed, 22 Oct 2003 16:59:48 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h9MFxmn14206 for ipv6@ietf.org; Wed, 22 Oct 2003 16:59:48 +0100 Date: Wed, 22 Oct 2003 16:59:48 +0100 From: Tim Chown To: ipv6@ietf.org Subject: Re: A host who has private IPv4 address can communicate with IPv6 host globaly by 6to4 tunnel Message-ID: <20031022155948.GN9984@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <000001c39883$c7471cd0$3c01a8c0@willnote> <20031022102831.GI6932@login.ecs.soton.ac.uk> <027c01c398b5$2a030790$c102a8c0@consulintel.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <027c01c398b5$2a030790$c102a8c0@consulintel.es> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , The same also goes for tunnel brokers and other mechanisms using the proto41 forwarding. But this is a v6ops thing not ipv6 wg. tim On Wed, Oct 22, 2003 at 11:57:10PM +0800, JORDI PALET MARTINEZ wrote: > In fact, it will be very good if you can tell me (private email to avoid brands/models here) what router or NAT box are you using, > so I can include it in my survey. > > Same for other people that has used this ;-) > > Regards, > Jordi > > PS: By the way, yes, you can use any of the computers after the NAT as the IPv6 router. I'm doing it right now, in my hotel room, > and I see some other people using my IPv6 prefix, for free, being my laptop the router ! You can read the last draft (-02 waiting in > the editors queue) and also this document > http://www.euro6ix.org/documentation/euro6ix_co_upm-consulintel_wp4_ipv6_tunnels_nat_v1_6.pdf. > > ----- Original Message ----- > From: "Tim Chown" > To: > Sent: Wednesday, October 22, 2003 6:28 PM > Subject: Re: A host who has private IPv4 address can communicate with IPv6 host globaly by 6to4 tunnel > > > > Hi, > > > > Yes, this will work. This technique is quite widely used, and is one > > reason for this draft: > > http://www.ietf.org/internet-drafts/draft-palet-v6ops-proto41-nat-01.txt > > > > Essentially you forward the protocol 41 from the NAT to the internal host. > > > > It is quite a popular "trick" with our students in their home DSL LANs. > > > > The problem is that this only works for one host within the NAT network, > > so if the NAT encompasses many sites, you're stuck. > > > > Cheers, > > Tim > > > > On Wed, Oct 22, 2003 at 07:03:44PM +0900, Jisuek.Lim wrote: > > > > > > Hello all, > > > > > > I have a idea about communication method with 6to4 tunnel. > > > > > > Generally, we think a host who has private IPv4 address(because it is > > > behind NAT device) can not communicate with IPv6 host globally by > > > tunneling(6to4, config tunnel ..) But there is a way using 6to4 > > > tunnel. > > > > > > When we config 6to4 config on a host(for example windows2000 station) > > > we assign the host's IPv4 address to the host's 6to4 address(next to > > > 2002:). And we know the host's IPv4 address shoud be public IPv4 > > > address. > > > > > > But, if we use the public IPv4 address which is on NAT device's > > > external interface to make the host's 6to4 address, the host can > > > communicate with IPv6 host globally using 6to4 tunnel and relay > > > router. Following are do list. > > > > > > 1. Map the NAT device's public address(select one) to the host's > > > private address(configure on the NAT) > > > > > > 2. On the NAT device, make a policy which permit incomming > > > traffic which has protocol number 41 to the host's private address > > > > > > 3. Change the NAT device's public IPv4 address(which you > > > selected) to hex. format. > > > > > > 4. Configure the host's 6to4 address using upper hex. > > > > > > 5. Add route table for 2002 traffic to tunnel interface, and > > > ::/0 to relay router(relay router is provided by some orgnization) > > > > > > > > > And then,...try ping6 to any IPv6 address. following is the result of > > > my own test. > > > > > > > > > C:\>ping6 6to4.ipv6.fh-regensburg.de > > > > > > Pinging 6to4.ipv6.fh-regensburg.de [2002:c25f:6cbf:1::1] with 32 bytes > > > of data: > > > > > > > > > Reply from 2002:c25f:6cbf:1::1: bytes=32 time=330ms > > > > > > Reply from 2002:c25f:6cbf:1::1: bytes=32 time=329ms > > > > > > Reply from 2002:c25f:6cbf:1::1: bytes=32 time=329ms > > > > > > > > > C:\> > > > > > > C:\>ping6 www.kame.net > > > > > > > > > Pinging orange.kame.net [2001:200:0:8002:203:47ff:fea5:3085] with 32 > > > bytes of data: > > > > > > > > > Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=117ms > > > > > > Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=72ms > > > > > > Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=68ms > > > > > > Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=71ms > > > > > > > > > C:\> > > > > > > > > > Following is my computer's IP config > > > > > > > > > C:\>ipconfig > > > > > > > > > Windows 2000 IP Configuration > > > > > > > > > Ethernet adapter : > > > > > > > > > Connection-specific DNS Suffix . : > > > > > > IP Address. . . . . . . . . . . . : 192.168.1.60 > > > > > > Subnet Mask . . . . . . . . . . . : 255.255.255.0 > > > > > > Default Gateway . . . . . . . . . : 192.168.1.254 > > > > > > > > > C:\> > > > > > > > > > as you know 192.168.1.60 is private address !! > > > > > > Try it. > > > > > > Thanks. > > > > > > Jisuek. Lim > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 13:38:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19023 for ; Wed, 22 Oct 2003 13:38:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMvo-0008KP-Se for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 13:38:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MHc0Mk031999 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 13:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMvn-0008Jd-N0 for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 13:37:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18994 for ; Wed, 22 Oct 2003 13:37:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMvl-0000Kf-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 13:37:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACMvl-0000Kc-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 13:37:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMur-0007xS-V6; Wed, 22 Oct 2003 13:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMup-0007wP-2v for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 13:36:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18957 for ; Wed, 22 Oct 2003 13:36:46 -0400 (EDT) From: elizabeth.rodriguez@dothill.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMum-0000Js-00 for ipv6@ietf.org; Wed, 22 Oct 2003 13:36:56 -0400 Received: from mail.dothill.com ([155.254.128.7] helo=dothill.com) by ietf-mx with esmtp (Exim 4.12) id 1ACMul-0000Jp-00 for ipv6@ietf.org; Wed, 22 Oct 2003 13:36:56 -0400 Received: from exchange.artecon.com (exchange [206.6.182.75]) by dothill.com (8.12.9+Sun/8.12.5) with ESMTP id h9MHZSrT017423 for ; Wed, 22 Oct 2003 10:35:28 -0700 (PDT) Received: by exchange.artecon.com with Internet Mail Service (5.5.2653.19) id <42RVK50A>; Wed, 22 Oct 2003 10:25:59 -0700 Message-ID: <6E76A781C4D7D511A0C000105A209B59041B54AC@exchange.artecon.com> To: ipv6@ietf.org Subject: New IMSS WG; IPv6 over Fibre Channel Draft Date: Wed, 22 Oct 2003 10:25:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hello, I would like to announce a new IETF WG -- Internet and Management Support for Storage [IMSS] The charter follows below, but can also be found at http://www.ietf.org/html.charters/imss-charter.html The reason for this announcement on the IPv6 WG mailing list is because the first course of action for the working group is the working group last call for a draft initially reviewed in this working group: IPv6 over Fibre Channel. This draft has become the first official working group item, found at http://www.ietf.org/internet-drafts/draft-ietf-imss-ipv6-over-fibre-channel- 00.txt At the request of the IPv6 chairs, I will be keeping this WG apprised of the status of that draft. Please review this draft. Any discussion about this draft should occur on the IMSS mailing list. Assuming that no major holes are found in this draft, the IMSS working group plans on issuing a WG last call on this draft sometime in the next week or so. The IMSS WG last call announcement will be cross posted to this list at that time. To subscribe to IMSS, send email to imss-request@ietf.org with subject and body of 'subscribe'. IMSS will also be holding a session at IETF-58 in Minneapolis. Anyone interested in IMSS is welcome to attend. Thank you, Elizabeth Rodriguez IMSS chair ---- IPv6 over FC and IMSS WG announcements follow: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet and Management Support for Storage Working Group of the IETF. Title : IPv6 over Fibre Channel Author(s) : C. Desanti Filename : draft-ietf-imss-ipv6-over-fibre-channel-00.txt Pages : 24 Date : 2003-10-20 Fibre Channel (FC) is a high speed serial interface technology that supports several Upper Layer Protocols including Small Computer System Interface (SCSI) and IPv4, as specified in [IPFC]. 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-ietf-imss-ipv6-over-fibre-channel- 00.txt ----- A new IETF working group has been formed in the Operations and Management Area. For additional information, please contact the Area Directors or the WG Chairs. Internet and Management Support for Storage (imss) -------------------------------------------------- Current Status: Active Working Group Chair(s): Elizabeth Rodriguez Operations and Management Area Director(s): Randy Bush Bert Wijnen Operations and Management Area Advisor: Bert Wijnen Technical Advisor(s): Keith McCloghrie Margaret Wasserman David Black Mailing Lists: General Discussion: imss@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/imss Archive: http://www1.ietf.org/mail-archive/working-groups/imss/ Description of Working Group: Fibre Channel is a high speed network technology primarily used for storage networking (i.e., Storage Area Networks [SANs]). Two important aspects of Fibre Channel interact with the Internet: - Fibre Channel can encapsulate and carry IP protocol traffic - Fibre Channel devices can be managed via SNMP The Internet and Management Support for Storage WG (imss) is chartered to address two areas, specifically: - IPv4 over Fibre Channel has been specified in RFC 2625. A corresponding specification for IPv6 is needed. - An initial Fibre Channel Management MIB has been developed by the IP Storage (ips) WG; extensions are needed to encompass management of additional aspects of Fibre Channel, such as zoning. In the future, other storage related MIBs for other storage transports such as INCITS T10 Serial Attached SCSI (SAS) or SCSI command specific MIBs may be proposed. This group would work with the appropriate technical committee(s) in a manner similar to that described for INCITS T11 below. As Fibre Channel standardization is handled by the INCITS T11 Technical Committee (http://www.t11.org), a close working relationship with T11 is essential to the WG's success. In particular: - The IPv6 over Fibre Channel specification will be based on draft-desanti-ipv6-over-fibre-channel-02.txt. This draft was originally developed within a T11 study group and T11 has officially recommended this draft to the IETF. - The WG will not standardize management of Fibre Channel features ahead of their incorporation into appropriate T11 Fibre Channel standards. - The WG will work closely with T11, specifically Task Group T11.5, on the functionality and structure of the MIBs it develops for management of Fibre Channel. In addition to working closely with the INCITS T11 Technical Committee, this Working Group will work closely with IETF IPv6 Working Group as appropriate. In particular, the IPv6 Working Group will be kept informed on the progress and status of the IPv6 over Fibre Channel specification. The IMSS Working Group Last Call announcement will be cross-posted to the IPv6 WG mailing list. Goals and Milestones: Dec 03 Submit IPv6 over Fibre Channel draft to IESG for consideration as Proposed Standard Aug 04 Work with T11.5 to determine what additional Fibre Channel MIBs are needed. Oct 04 Submit Fibre Channel Domain Manager MIB to IESG for consideration as Proposed Standard Oct 04 Submit Fibre Channel Name Server MIB to IESG for consideration as Proposed Standard Jan 05 Submit Extensions for Fibre Channel Interfaces MIB to IESG for consideration as Proposed Standard Jan 05 Review working group charter and determine what additional work, if any, should be undertaken by working group. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 15:00:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21901 for ; Wed, 22 Oct 2003 15:00:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACOD8-0000RF-16 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 14:59:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MIxvkF001679 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 14:59:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACOD7-0000Qz-QM for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 14:59:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21850 for ; Wed, 22 Oct 2003 14:59:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACOD4-0001Df-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 14:59:54 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACOD4-0001Dc-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 14:59:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACOCD-0008V3-J4; Wed, 22 Oct 2003 14:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACOC9-0008TC-EU for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 14:58:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21822 for ; Wed, 22 Oct 2003 14:58:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACOC6-0001Cm-00 for ipv6@ietf.org; Wed, 22 Oct 2003 14:58:54 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1ACOC5-0001Cj-00 for ipv6@ietf.org; Wed, 22 Oct 2003 14:58:53 -0400 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9MIwked002226; Wed, 22 Oct 2003 20:58:46 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org From: Iljitsch van Beijnum Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Date: Wed, 22 Oct 2003 20:58:50 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.604) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 22 okt 2003, at 17:51, Erik Nordmark wrote: >> - In practice, applications may treat these address like >> global scoped addresses. > I don't see how this can be true in general. > Here is an example using referrals; the three nodes involved are A, B, > C. Node A and B are in the same site, have both local and global > addresses, and C is in a different site. > Node A and B are communicating using these local addresses. > In particular, B contacted A using FQDN(A) and the naming system > somehow so that they ended up communcating with local addresses. (My > understanding is that part of the benefit of these local addresses is > that local communication prefer using local addresses over global > addresses.) Yes, but how??? A simple method would be to check the first 48 bits of the IP addresses that are suspected of having "local" reachability. But this doesn't allow for the merging of two sites, which was presented as a rather prominent requirement during the site local wars (or at least the part I got to witness). I don't believe two-faced DNS is a solution, because then the DNS server must know all the information the hosts are apparently unaware of, and know the exact reachability details of each possible pair of hosts to boot. I expect both internal information to leak out and internal hosts to be presented with external information only in many situations. A solution could be giving hosts access to local routing information. Is this something we want? Or do we drop the site merger without renumbering thing and work on renumbering instead? Note that these problems don't disappear once we sprinkle them with magic loc/id separation powder: it's still entirely possible for the system to choose a locator that doesn't work. But at least this is a problem that can be corrected somewhere lower (below the application) in the stack and optimized there, rather than dump the problem on applications and hope those will do the right thing after TCP times out. > The fundamental difference between unique local addresses and global > addresses is that the former are permentently unreachable by design > (except from the local domain) whereas the latter might be temporarily > unreachable due to some failure. > I believe this means that applications need to be aware of the > difference between the two types. > Hence not ready for proposed standard IMHO. There is another problem: the global routability of these addresses is completely ambiguous. First the draft says "the scope is global". Then "don't expect them to be routable" and finally "filter them". This is no good. Today, there is no difference between addresses that are unroutable by design, and addresses that are unroutable because of limitations in the routing system. But as the routing system evolves, this is subject to change. Suppose we build a locator/identifier separation mechanism, and some people start using these addresses as stable identifiers, while others use them as local-only addresses. This is going to create a huge mess as part of this address space must now (still) be filtered, while another part must be allowed through _everywhere_ in the world. So my question is: are unique local IPv6 unicast addresses unroutable by design yes or no? Iljitsch van Beijnum -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 16:10:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25698 for ; Wed, 22 Oct 2003 16:10:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPIv-0003Se-33 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 16:10:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MKA0q9013284 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 16:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPIu-0003SB-Bw for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 16:10:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25659 for ; Wed, 22 Oct 2003 16:09:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACPIs-00023S-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 16:09:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACPIs-00023P-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 16:09:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPHy-000354-9M; Wed, 22 Oct 2003 16:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPHh-0002ys-Fi for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 16:08:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25632 for ; Wed, 22 Oct 2003 16:08:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACPHf-00022a-00 for ipv6@ietf.org; Wed, 22 Oct 2003 16:08:43 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1ACPHe-00022T-00 for ipv6@ietf.org; Wed, 22 Oct 2003 16:08:42 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9MK8ePh004799; Wed, 22 Oct 2003 14:08:41 -0600 (MDT) Received: from lillen (vpn-129-156-97-186.EMEA.Sun.COM [129.156.97.186]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9MK8cS22199; Wed, 22 Oct 2003 22:08:38 +0200 (MEST) Date: Wed, 22 Oct 2003 22:08:35 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" To: Brian Haberman Cc: ipv6@ietf.org In-Reply-To: "Your message with ID" <3F9665EC.4010508@innovationslab.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > A simple method would be to check the first 48 bits of the IP addresses > that are suspected of having "local" reachability. But this doesn't > allow for the merging of two sites, which was presented as a rather > prominent requirement during the site local wars (or at least the part > I got to witness). Good point. > I don't believe two-faced DNS is a solution, because then the DNS > server must know all the information the hosts are apparently unaware > of, and know the exact reachability details of each possible pair of > hosts to boot. I expect both internal information to leak out and > internal hosts to be presented with external information only in many > situations. > > A solution could be giving hosts access to local routing information. > Is this something we want? Or do we drop the site merger without > renumbering thing and work on renumbering instead? At least having a mechanism to provide hosts with a list of which local prefixes are likely to be routable wouldn't be hard. But how many such prefixes is it reasonable to assume that the most basic nodes will support? (If I read between the lines about the claimed security befits of local addresses in the hain/templin draft it seems like it is the simple small devices that supposedly benefit most from unique local addresses, but those might also not want to store a hundered such prefixes.) Things brings us to the semantics of the "local only" communication when there are both site mergers (with two or more local prefixes denoting the same site) as well as having private interconnection of sites; which prefixes should be included in the "local only" type of filter in each host? > Note that these problems don't disappear once we sprinkle them with > magic loc/id separation powder: it's still entirely possible for the > system to choose a locator that doesn't work. But at least this is a > problem that can be corrected somewhere lower (below the application) > in the stack and optimized there, rather than dump the problem on > applications and hope those will do the right thing after TCP times > out. Agreed. I haven't yet thought about the utility of locator locators with locatior/identifier separation. Perhaps they would be useful since they can survive flash cutover renumbering (when DNS can't be updated in time) but they might not provide benefits for controlled renumbering. > So my question is: are unique local IPv6 unicast addresses unroutable > by design yes or no? I'll let others answer that question. What I see in the draft is language like: - Not possible to route Local IPv6 prefixes on the global Internet with current routing technology. Consequentially, it is necessary to have the default behavior of site border routers to filter these addresses. This sure reads like folks would like them to be globally routable and that there are just some minor technical issues with the current routing technology that prevents that (hah!). Sure looks like a slippery slope to me. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 16:35:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26978 for ; Wed, 22 Oct 2003 16:35:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPhY-0001l1-1a for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 16:35:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MKZSw1006749 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 16:35:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPhX-0001km-Qr for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 16:35:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26938 for ; Wed, 22 Oct 2003 16:35:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACPhV-0002Ld-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 16:35:26 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACPhV-0002LY-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 16:35:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPh8-0001ZR-5b; Wed, 22 Oct 2003 16:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPgW-0001Tl-Lq for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 16:34:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26875 for ; Wed, 22 Oct 2003 16:34:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACPgU-0002KV-00 for ipv6@ietf.org; Wed, 22 Oct 2003 16:34:22 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1ACPgT-0002KS-00 for ipv6@ietf.org; Wed, 22 Oct 2003 16:34:22 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9MKYJ5u018629; Wed, 22 Oct 2003 14:34:20 -0600 (MDT) Received: from lillen (vpn-129-156-97-186.EMEA.Sun.COM [129.156.97.186]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9MKYHS27853; Wed, 22 Oct 2003 22:34:18 +0200 (MEST) Date: Wed, 22 Oct 2003 22:34:15 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" To: Brian Haberman Cc: ipv6@ietf.org In-Reply-To: "Your message with ID" <3F9665EC.4010508@innovationslab.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Overall I support this document, but there are two things that have me concerned. 1. The document talks about a replacement in section 2 and section 5. While finding replacement for what folks perceived as being benefit with site local addresses is useful (and perhaps even required), the text in this draft seems to lock us down into replacement that consist of defining some new address format. I find this odd since the the WG has discussed partial replacement solutions (for instance, draft-zill-ipv6wg-zone-prefixlen-00.txt) which do not involve defining a new address format. Does this document indeed intend to prevent the WG from working on replacement solutions which do not define a new addressing format? That would seem silly thus I suggest the text be reworked a bit to make this more clear. 2. Section 2 talks of only two categories of issues but I think there is a 3rd one: "moving the problem to the application space". The text in section 2.1 talks of only one aspect of this (having to deal with scope ids in the application). draft-wasserman-ipv6-sl-impact-02.txt in section 3.7 has additional issues relating to: - Two-party client/server applications that exchange IP addresses at the application layer. - Multi-party applications that exchange IP addresses at the application layer. Thus in particular the last two paragraphs in section 3.7 in draft-wasserman-ipv6-sl-impact-02.txt seems to be missing from this draft and I think they need to be included to make sure important aspects of the issues are not forgotten as we move forward. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 18:28:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01869 for ; Wed, 22 Oct 2003 18:28:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACRSR-0007yF-Ml for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 18:28:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MMRxT3030635 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 18:27:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACRSR-0007y2-Gu for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 18:27:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01824 for ; Wed, 22 Oct 2003 18:27:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACRSO-0003PP-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 18:27:56 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACRSN-0003PM-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 18:27:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACRRV-0007gH-DE; Wed, 22 Oct 2003 18:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACRRG-0007cG-Lj for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 18:26:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01762 for ; Wed, 22 Oct 2003 18:26:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACRR8-0003Oo-00 for ipv6@ietf.org; Wed, 22 Oct 2003 18:26:38 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1ACRR7-0003Ol-00 for ipv6@ietf.org; Wed, 22 Oct 2003 18:26:37 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 752D514259; Wed, 22 Oct 2003 18:26:36 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19796-13; Wed, 22 Oct 2003 18:26:32 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id AE0A414258; Wed, 22 Oct 2003 18:26:32 -0400 (EDT) Date: Wed, 22 Oct 2003 18:26:12 -0400 From: Keith Moore To: Brian Haberman Cc: moore@cs.utk.edu, ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Message-Id: <20031022182612.53c8afe7.moore@cs.utk.edu> In-Reply-To: <3F96659F.4040702@innovationslab.net> References: <3F96659F.4040702@innovationslab.net> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Summary: - I do not think it is appropriate to publish this document as Proposed Standard at this time. - I believe the structure of these addresses and means of assigning prefixes are basically sound. However, I have several problems with sections 7 on. - I would support publication of this document as Experimental if it were revised to include only the sections on address structure and assignment of prefixes, and omit the sections describing how the authors expect these addresses to be *used* either in DNS or by applications. ---------------------------------------------------------------------- > 7.0 DNS Issues > > AAAA records for Local IPv6 addresses SHOULD NOT be installed in > the global DNS. Trying to impose scope on DNS is not technically sound. Applications, (including but not limited to DNS) are not aware of scope boundaries and will leak addresses (including DNS query results) across those scope boundaries. Applications operating across scope boundaries need a consistent view of DNS in order to function properly. > If Local IPv6 address are configured in the global DNS, no harm is > done because they are unique and will not create any confusion. > They may not be reachable, but this is a property that is common to > all types of global IPv6 unicast addresses. > > For future study names with Local IPv6 addresses may be resolved > inside of the site using dynamic naming systems such as Multicast > DNS. Multicast DNS is a very dubious concept which should not be endorsed by this document. In particular, it suffers from the same severe technical flaw (among others) that this section does - that it is acceptable for DNS (or a combined system consisting of DNS and mDNS) to present different views of an RRset or zone to different portions of the network, when applications quite reasonably expect DNS to be consistent (modulo skew between different versions of a zone at different servers). > 8.0 Application and Higher Level Protocol Issues > > Application and other higher level protocols can treat Local IPv6 > addresses in the same manner as other types of global unicast > addresses. No special handling is required. I do not believe this to be the case; or at the very least, this is a gross oversimplification for the case of apps that do referrals (for instance, any app that uses DNS). Some apps will need to choose an address that functions across all peers; use of local addresses would fail more often than globals. Some apps are intended for local use only and are less tolerant of prefix changes; these apps will want to use local addresses in preference to globals. But even this is an oversimplification. > This type of addresses > may not be reachable, but that is no different from other types of > IPv6 global unicast addresses. Yes it is different, because the reasons for lack of reachability are different. When an app cannot reach peer using a global address, it's reasonable to assume that this is either due to administrative prohibition or a temporary routing or link failure. (Administrative prohibitions should be signalled with ICMP messages so that the app can distinguish between these two cases; the fact that router/firewall configurations often botch this doesn't justify propagation of that error.) > Applications need to be able to > handle multiple addresses that may or may not be reachable any > point in time. This is also an oversimplification. It's certainly not a reasonable statement as written, because there are too many cases where expecting an application to cope with multiple addresses is either onerous (as in expecting every application to implement its own route advertisement, routing, and message forwarding) or infeasable (as in expecting apps to route messages between pairs of hosts that may not have any signal path between them). A more realistic statement is that applications need to be able to distinguish between cases where the application can reasonably do the job (because the network provides adequate connectivity) and cases where the application cannot reasonably do the job (because, for whatever reason, the network fails to provide adequate connectivity). And if the connectivity isn't adequate, this needs to be described as a consequence of network configuration - not a failure of the application. > In most cases this complexity should be hidden in APIs. It is naive to assume that this complexity can be hidden in APIs, at least given facilities currently in the network, because the decision of which kind of address to use requires information that is not available to the hosts. The apps can supply hints as to their preferences, but reasonable decisions require knowledge of both network topology (e.g. which addresses are reachable from which parts of the network) and the topology of the application (where are the current and future peers that are part of the application located?) > From a host's perspective this difference shows up as different > reachability than global unicast and could be handled by default > that way. In some cases it is better for nodes and applications to > treat them differently from global unicast addresses. A starting > point might be to give them preference over global unicast, but > fall back to global unicast if a particular destination is found to > be unreachable. This is not a reasonable strategy for many, perhaps most, applications. It makes assumptions about application behavior that aren't generally true, and may be even less valid in the future. > Much of this behavior can be controlled by how they are > allocated to nodes and put into the DNS. It is not reasonable to make assumptions about applications' use of DNS; in particular, it's not reasonable to assume that the scope in which a DNS query was made is the same scope in which the results will be used. > Note that the address selection mechanisms of [ADDSEL], and in > particular the policy override mechanism replacing default address > selection, are expected to be used on a site where Local IPv6 > addresses are configured. Address selection by itself is woefully inadequate, and it cannot be made adequate given either the existing APIs or the information that is currently available to hosts about either the app or the network. ---------------------------------------------------------------------- The bottom line is this: >>> we don't understand how to make this work yet. <<< where "this" is having hosts advertise multiple addresses with varying reachability. The potential for "this" has always been there in IPv4, and it's been tried from time to time, but in general, it never has worked well. The difference is that whereas in IPv4 we could generally give each host a single address and make it reachable from all points of interest (modulo administrative prohibition), in IPv6 we're trying to insist that multiple addressing be used as a matter of course and to solve a variety of problems. In other words, we're insisting that something that has been tried many times and has never worked before, be made to work (presumably by pretending that the problem doesn't exist, or that it's somebody else's - the application writer's - problem). Basically this fails the "no known technical limitations" test. A document that defines formats for GUPIs and PUPIs is a good next step, but it is not sufficient. What we need to do is to set aside this document (i.e. assume that it's fine as is, though it might need tweaking later once we understand how to solve the real problems) and start actually trying to define a model that works. The model should consist of: - rules for assignment of addresses to hosts (i.e. when to assign locals, when to assign globals, or both) - mechanisms to propagate information about which addresses are usable that actually do follow scope (e.g. via ND/RA) - rules for selection of addresses (not merely address selection as it's currently thought of, but also considering things like substituting a locally-known alternative for a global address that is advertised in DNS or other referral mechanism) - rules for address referrals (including but not limited to DNS) As for what it means for the model to "work" I suggest the following: - it should be possible to associate a token (or a short list of tokens) with a host, so that the tokens can be used to unambiguously identify and reach that host, reliably and efficiently, from any location in the network, provided the host is reachable - an application in possession of such tokens should be able to quickly and reliably determine if failure to reach a host is due to administrative prohibition or lack of a routing arrangement (as opposed to a temporary condition such as a host or link failure) - this token or list of tokens should be suitable for advertising in DNS (probably but not necessarily AAAA records) or via other referral mechanisms - the binding between these tokens and their hosts should have sufficient lifetime to allow them to be cached and to rid hosts and most apps of the burden of dealing with changing bindings - the efficient and reliable use of those tokens or list of tokens to communicate with current and potential peers should rely only on information that is easily available to hosts and apps using them. - there should be a clear separation of function between application responsibility, host responsibility, and network responsibility. ---------------------------------------------------------------------- > In order for hosts to autoconfigure Local IPv6 addresses, routers > have to be configured to advertise Local IPv6 /64 prefixes in > router advertisements. Likewise, a DHCPv6 server must have been > configured to assign them. since when? none of my v6 boxes require DHCPv6, and that's a Good Thing. > In order for a node to learn the Local IPv6 address > of another node, the Local IPv6 address must have been installed in > the DNS. false. not all apps use DNS as a means of learning peers' addresses, nor do apps that do use DNS always use it exclusively. nor would it be desirable to impose that constraint. > For these reasons, it is straight forward to control their > usage in a site. this does not follow because it's based on a false premise. In general, I object to section 9 because it assumes (nay, imposes) split DNS, which is highly undesirable and also nonstandard. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 18:57:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03561 for ; Wed, 22 Oct 2003 18:57:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACRui-0006Tb-Mi for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 18:57:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MMvClJ024889 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 18:57:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACRui-0006TM-JF for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 18:57:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03507 for ; Wed, 22 Oct 2003 18:56:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACRuf-0003mq-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 18:57:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACRue-0003mn-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 18:57:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACRuY-0006Nx-5D; Wed, 22 Oct 2003 18:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACRuE-0006JU-5H for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 18:56:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03480; Wed, 22 Oct 2003 18:56:28 -0400 (EDT) Message-Id: <200310222256.SAA03480@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-soliman-ipv6-2461-bis-00.txt Date: Wed, 22 Oct 2003 18:56:28 -0400 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Neighbor Discovery for IP version 6 (IPv6) Author(s) : T. Narten, et. al. Filename : draft-soliman-ipv6-2461-bis-00.txt Pages : 86 Date : 2003-10-22 This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-soliman-ipv6-2461-bis-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-soliman-ipv6-2461-bis-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-soliman-ipv6-2461-bis-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: <2003-10-22183136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-soliman-ipv6-2461-bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-soliman-ipv6-2461-bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-22183136.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 19:10:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05001 for ; Wed, 22 Oct 2003 19:10:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACS7S-0001Lb-3q for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 19:10:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MNAM6v005176 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 19:10:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACS7R-0001LP-UN for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 19:10:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04965 for ; Wed, 22 Oct 2003 19:10:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACS7O-0004Aa-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 19:10:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACS7N-0004AX-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 19:10:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACS79-0001BF-EN; Wed, 22 Oct 2003 19:10:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACS6R-000146-4l for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 19:09:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04876 for ; Wed, 22 Oct 2003 19:09:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACS6M-000472-00 for ipv6@ietf.org; Wed, 22 Oct 2003 19:09:14 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ACS6L-00045w-00 for ipv6@ietf.org; Wed, 22 Oct 2003 19:09:13 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9MN8bC06688; Wed, 22 Oct 2003 16:08:37 -0700 X-mProtect: <200310222308> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4q1jQH; Wed, 22 Oct 2003 16:08:35 PDT Message-ID: <3F970F0D.8020007@iprg.nokia.com> Date: Wed, 22 Oct 2003 16:13:17 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: H.Soliman@flarion.com CC: ipv6@ietf.org Subject: Re: I-D ACTION:draft-soliman-ipv6-2461-bis-00.txt References: <200310222256.SAA03480@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Umm - perhaps add a "Changes since RFC 2461" section?? Fred ftemplin@iprg.nokia.com Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Neighbor Discovery for IP version 6 (IPv6) > Author(s) : T. Narten, et. al. > Filename : draft-soliman-ipv6-2461-bis-00.txt > Pages : 86 > Date : 2003-10-22 > >This document specifies the Neighbor Discovery protocol for IP >Version 6. IPv6 nodes on the same link use Neighbor Discovery to >discover each other's presence, to determine each other's link-layer >addresses, to find routers and to maintain reachability information >about the paths to active neighbors. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-soliman-ipv6-2461-bis-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-soliman-ipv6-2461-bis-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-soliman-ipv6-2461-bis-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 19:40:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07057 for ; Wed, 22 Oct 2003 19:40:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACSZs-0006cr-9o for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 19:39:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MNdieF025463 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 19:39:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACSZs-0006cc-4n for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 19:39:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07025 for ; Wed, 22 Oct 2003 19:39:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACSZq-0004qi-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 19:39:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACSZp-0004qf-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 19:39:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACSZC-0006PK-4z; Wed, 22 Oct 2003 19:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACSYb-0006JR-2w for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 19:38:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06994 for ; Wed, 22 Oct 2003 19:38:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACSYZ-0004qG-00 for ipv6@ietf.org; Wed, 22 Oct 2003 19:38:23 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1ACSYY-0004qD-00 for ipv6@ietf.org; Wed, 22 Oct 2003 19:38:22 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9MNcC4t003321; Wed, 22 Oct 2003 16:38:13 -0700 (PDT) Received: from naexfe02.na.qualcomm.com (naexfe02.qualcomm.com [129.46.51.214]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9MNcAFA006742; Wed, 22 Oct 2003 16:38:10 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by naexfe02.na.qualcomm.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Oct 2003 16:38:10 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6470.0 Subject: RE: I-D ACTION:draft-soliman-ipv6-2461-bis-00.txt Date: Wed, 22 Oct 2003 16:38:09 -0700 Message-ID: <17D8F6DF3ED94D40BD607380866D9B7F33D1B3@NAEX01.na.qualcomm.com> Thread-Topic: I-D ACTION:draft-soliman-ipv6-2461-bis-00.txt Thread-Index: AcOY7+rDb9acraFWQemPTThZIf71OAABRktg From: "Barany, Pete" To: Cc: X-OriginalArrivalTime: 22 Oct 2003 23:38:10.0473 (UTC) FILETIME=[8D7D8990:01C398F5] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I raised an issue awhile back regarding the Router Lifetime field and the AdvDefaultLifetime parameter and the wording of Section 4.2 in RFC 2461. I insert the e-mail below from Erik Nordmark discussing this. Would it be possible to consider changing the wording in Section 4.2 per the e-mail below? Thanks. Regards, Pete --> INSERT e-mail > What I mean to say is that the parameter AdvDefaultLifetime MUST be=20 > either zero or between MaxRtrAdvInterval and 9000 seconds (IPv6) per=20 > RFC 2461. Same thing for IPv4 per RFC 1256 (only the parameter is=20 > Advertisement Lifetime). The inconsistency (for lack of a better word) > is that the Router Lifetime field is 16 bits and if set to anything=20 > greater than 9000 seconds then this would violate the specifications.=20 > So, if it is set to 18.2 hours (e.g., for some wireless cellular=20 > links) it violates the specs. Thanks, now I understand your point. While the wording might be unfortunate and perhaps confusing, saying that 2^^16 seconds is 18.2 hours is correct. Even though the sender will not use more than 9000 seconds the protocol doesn't, and presumably shouldn't, have the receivers reject RAs with a router lifetime that is larger per the "consevative in what you send;=20 liberal in what you accept" principle. So if we change the sentence in 4.2 from: The maximum value corresponds to 18.2 hours. to The field can contain values up to 65535 and receivers should handle any value, while the sending rules in section 6 limit the lifetime to 9000 seconds. would that be better? Erik --> END INSERT e-mail ------------------------- -----Original Message----- From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, October 22, 2003 3:56 PM Cc: ipv6@ietf.org Subject: I-D ACTION:draft-soliman-ipv6-2461-bis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Neighbor Discovery for IP version 6 (IPv6) Author(s) : T. Narten, et. al. Filename : draft-soliman-ipv6-2461-bis-00.txt Pages : 86 Date : 2003-10-22 =09 This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-soliman-ipv6-2461-bis-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-soliman-ipv6-2461-bis-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-soliman-ipv6-2461-bis-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. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 19:51:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07343 for ; Wed, 22 Oct 2003 19:51:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACSl7-0000R9-Ai for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 19:51:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MNpLgR001665 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 19:51:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACSl5-0000Q8-Nd for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 19:51:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07309 for ; Wed, 22 Oct 2003 19:51:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACSl3-0004wc-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 19:51:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACSl3-0004wZ-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 19:51:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACSko-0000Gy-4K; Wed, 22 Oct 2003 19:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACSk3-00007q-LW for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 19:50:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07294 for ; Wed, 22 Oct 2003 19:50:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACSk1-0004wG-00 for ipv6@ietf.org; Wed, 22 Oct 2003 19:50:13 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1ACSk0-0004wB-00 for ipv6@ietf.org; Wed, 22 Oct 2003 19:50:13 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HN600D9ONITHM@mailout2.samsung.com> for ipv6@ietf.org; Thu, 23 Oct 2003 08:49:41 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HN600GR8NHN2F@mailout2.samsung.com> for ipv6@ietf.org; Thu, 23 Oct 2003 08:49:00 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HN600J20NHN0J@mmp2.samsung.com> for ipv6@ietf.org; Thu, 23 Oct 2003 08:48:59 +0900 (KST) Date: Thu, 23 Oct 2003 08:49:16 +0900 From: Soohong Daniel Park Subject: RE: I-D ACTION:draft-soliman-ipv6-2461-bis-00.txt In-reply-to: <3F970F0D.8020007@iprg.nokia.com> To: "'Fred Templin'" , H.Soliman@flarion.com Cc: ipv6@ietf.org Message-id: <00ab01c398f7$1ad61e50$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Agreed... It's so heavy to find out what is updated... Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On > Behalf Of Fred Templin > Sent: Thursday, October 23, 2003 8:13 AM > To: H.Soliman@flarion.com > Cc: ipv6@ietf.org > Subject: Re: I-D ACTION:draft-soliman-ipv6-2461-bis-00.txt > > > Umm - perhaps add a "Changes since RFC 2461" section?? > > Fred > ftemplin@iprg.nokia.com > > > Internet-Drafts@ietf.org wrote: > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > > > Title : Neighbor Discovery for IP version 6 (IPv6) > > Author(s) : T. Narten, et. al. > > Filename : draft-soliman-ipv6-2461-bis-00.txt > > Pages : 86 > > Date : 2003-10-22 > > > >This document specifies the Neighbor Discovery protocol for > IP Version > >6. IPv6 nodes on the same link use Neighbor Discovery to > discover each > >other's presence, to determine each other's link-layer addresses, to > >find routers and to maintain reachability information about > the paths > >to active neighbors. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-soliman-ipv6-2461-b is-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-soliman-ipv6-2461-bis-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-soliman-ipv6-2461-bis-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 20:58:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11694 for ; Wed, 22 Oct 2003 20:58:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACToB-000752-I0 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 20:58:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N0wZrA027215 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 20:58:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACToB-00074s-Dk for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 20:58:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11661 for ; Wed, 22 Oct 2003 20:58:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACTo8-0006EK-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 20:58:32 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACTo8-0006EH-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 20:58:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACTne-0006kd-EM; Wed, 22 Oct 2003 20:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACTnC-0006at-HH for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 20:57:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11632 for ; Wed, 22 Oct 2003 20:57:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACTn9-0006Do-00 for ipv6@ietf.org; Wed, 22 Oct 2003 20:57:32 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ACTn9-0006DW-00 for ipv6@ietf.org; Wed, 22 Oct 2003 20:57:31 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9N0uxi03247; Wed, 22 Oct 2003 17:56:59 -0700 X-mProtect: <200310230056> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdtYbC60; Wed, 22 Oct 2003 17:56:58 PDT Message-ID: <3F972875.4070601@iprg.nokia.com> Date: Wed, 22 Oct 2003 18:01:41 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: H.Soliman@flarion.com CC: Fred Templin , ipv6@ietf.org Subject: Re: I-D ACTION:draft-soliman-ipv6-2461-bis-00.txt References: <200310222256.SAA03480@ietf.org> <3F970F0D.8020007@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hesham, I note the following differences between this document and RFC 2461: 1. Two new author names added in upper l.h. corner of P. 1; date and document I-D name are changed on same page. 2. The term "Standards Track" is removed from the bottom of all pages. 3. Various whitespace and indentation differences; some indentations hamper readability, including: a. middle of P. 7, the term "random delay seed" is embedded in the text body instead of as hanging text. b. top of P. 17, under "Source Address", the trailing word "or" is truncated to "o". c. State table in appendix C is unreadable. 4. Two new author names/addresses added to bottom of p. 77. 5. The table of contents no longer matches up with the document page numbers. The above were all of the differences I was able to note. Did I miss something? Fred ftemplin@iprg.nokia.com > Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Neighbor Discovery for IP version 6 (IPv6) >> Author(s) : T. Narten, et. al. >> Filename : draft-soliman-ipv6-2461-bis-00.txt >> Pages : 86 >> Date : 2003-10-22 >> >> This document specifies the Neighbor Discovery protocol for IP >> Version 6. IPv6 nodes on the same link use Neighbor Discovery to >> discover each other's presence, to determine each other's link-layer >> addresses, to find routers and to maintain reachability information >> about the paths to active neighbors. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-soliman-ipv6-2461-bis-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-soliman-ipv6-2461-bis-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-soliman-ipv6-2461-bis-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 21:49:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13095 for ; Wed, 22 Oct 2003 21:49:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACUb9-0005xq-KR for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 21:49:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N1nBoT022920 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 21:49:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACUb9-0005xb-Ee for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 21:49:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13069 for ; Wed, 22 Oct 2003 21:49:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACUb6-0006gy-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 21:49:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACUb5-0006gv-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 21:49:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACUb0-0005qT-LH; Wed, 22 Oct 2003 21:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACUa4-0005XI-QL for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 21:48:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13000 for ; Wed, 22 Oct 2003 21:47:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACUa1-0006gW-00 for ipv6@ietf.org; Wed, 22 Oct 2003 21:48:01 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ACUa1-0006fx-00 for ipv6@ietf.org; Wed, 22 Oct 2003 21:48:01 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RDAZW>; Wed, 22 Oct 2003 21:51:49 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922DFE@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Barany, Pete'" , Soliman Hesham Cc: ipv6@ietf.org Subject: RE: I-D ACTION:draft-soliman-ipv6-2461-bis-00.txt Date: Wed, 22 Oct 2003 21:51:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Pete, Thanks for the pointer, I'll add that to the issues list which I'll send very shortly. Hesham > -----Original Message----- > From: Barany, Pete [mailto:pbarany@qualcomm.com] > Sent: Wednesday, October 22, 2003 7:38 PM > To: H.Soliman@flarion.com > Cc: ipv6@ietf.org > Subject: RE: I-D ACTION:draft-soliman-ipv6-2461-bis-00.txt > > > I raised an issue awhile back regarding the Router Lifetime field and > the AdvDefaultLifetime parameter and the wording of Section > 4.2 in RFC > 2461. I insert the e-mail below from Erik Nordmark discussing this. > Would it be possible to consider changing the wording in > Section 4.2 per > the e-mail below? Thanks. > > Regards, > > Pete > > --> INSERT e-mail > > > What I mean to say is that the parameter > AdvDefaultLifetime MUST be > > either zero or between MaxRtrAdvInterval and 9000 seconds > (IPv6) per > > RFC 2461. Same thing for IPv4 per RFC 1256 (only the parameter is > > Advertisement Lifetime). The inconsistency (for lack of a > better word) > > > is that the Router Lifetime field is 16 bits and if set to > anything > > greater than 9000 seconds then this would violate the > specifications. > > So, if it is set to 18.2 hours (e.g., for some wireless cellular > > links) it violates the specs. > > Thanks, now I understand your point. > > While the wording might be unfortunate and perhaps confusing, saying > that 2^^16 seconds is 18.2 hours is correct. Even though the > sender will > not use more than 9000 seconds the protocol doesn't, and presumably > shouldn't, have the receivers reject RAs with a router > lifetime that is > larger per the "consevative in what you send; > liberal in what you accept" principle. > > So if we change the sentence in 4.2 from: > The maximum value corresponds to 18.2 hours. > to > The field can contain values up to 65535 and receivers should > handle any value, while the sending rules in section 6 limit > the lifetime to 9000 seconds. > would that be better? > > Erik > > --> END INSERT e-mail > > ------------------------- > > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Wednesday, October 22, 2003 3:56 PM > Cc: ipv6@ietf.org > Subject: I-D ACTION:draft-soliman-ipv6-2461-bis-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Neighbor Discovery for IP version 6 (IPv6) > Author(s) : T. Narten, et. al. > Filename : draft-soliman-ipv6-2461-bis-00.txt > Pages : 86 > Date : 2003-10-22 > > This document specifies the Neighbor Discovery protocol for IP > Version 6. IPv6 nodes on the same link use Neighbor Discovery to > discover each other's presence, to determine each other's link-layer > addresses, to find routers and to maintain reachability information > about the paths to active neighbors. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-soliman-ipv6-2461-b is-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-soliman-ipv6-2461-bis-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-soliman-ipv6-2461-bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 21:54:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13324 for ; Wed, 22 Oct 2003 21:54:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACUg2-0007LS-Bv for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 21:54:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N1sEbT028228 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 21:54:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACUg2-0007LD-69 for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 21:54:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13283 for ; Wed, 22 Oct 2003 21:54:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACUfz-0006lq-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 21:54:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACUfx-0006lk-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 21:54:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACUfq-00078b-9h; Wed, 22 Oct 2003 21:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACUf4-00071A-QN for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 21:53:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13227 for ; Wed, 22 Oct 2003 21:53:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACUf1-0006ka-00 for ipv6@ietf.org; Wed, 22 Oct 2003 21:53:11 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ACUf1-0006k4-00 for ipv6@ietf.org; Wed, 22 Oct 2003 21:53:11 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RDA5C>; Wed, 22 Oct 2003 21:57:00 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922DFF@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Fred Templin'" Cc: ipv6@ietf.org Subject: RE: I-D ACTION:draft-soliman-ipv6-2461-bis-00.txt Date: Wed, 22 Oct 2003 21:56:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Fred and all, I didn't realise how efficient the secretariet will be. I was planning to send an email letting everyone know that I submitted 2461-bis as a personal draft and that NO changes were made (I'll note Fred's comments on the editorials and this should be fixed in the next rev). I'm sending an issues list shortly, I didn't update the document because there was no point in updating it before sending the issues and suggesting a resolution for each one. Unfortunately there was no time to do this before the submission deadline. Thanks, Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 22:07:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13967 for ; Wed, 22 Oct 2003 22:07:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACUst-00021m-IA for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 22:07:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N27VYn007780 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 22:07:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACUss-00021F-NE for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 22:07:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13897 for ; Wed, 22 Oct 2003 22:07:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACUsp-000708-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 22:07:27 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACUso-000705-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 22:07:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACUsP-0001gm-PB; Wed, 22 Oct 2003 22:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACUrt-0001ZV-3Y for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 22:06:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13803 for ; Wed, 22 Oct 2003 22:06:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACUrp-0006y9-00 for ipv6@ietf.org; Wed, 22 Oct 2003 22:06:25 -0400 Received: from pec.etri.re.kr ([129.254.114.50]) by ietf-mx with esmtp (Exim 4.12) id 1ACUro-0006xG-00 for ipv6@ietf.org; Wed, 22 Oct 2003 22:06:25 -0400 Received: from pec.etri.re.kr (mkshin.etri.re.kr [129.254.112.163]) by pec.etri.re.kr (8.12.10/8.12.10) with ESMTP id h9N2KbJ5027269 for ; Thu, 23 Oct 2003 11:20:37 +0900 (KST) Message-ID: <3F97378F.6D04D3F7@pec.etri.re.kr> Date: Thu, 23 Oct 2003 11:06:07 +0900 From: Myung-Ki Shin Organization: ETRI X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > In my memory, > > IPv6 guys also agreed on our view during the 54th IETF meeting. > > > > I think .. > > RFC3306 needs allocation server of 32bit goup ID > > in order to support the uniqueness in the site. > > This site is identified by network prefix. > > > > But, > > Group ID Autoconfiguration in link-scope will be valuable > > without help of allocation server. > > Each node in our draft allocates group ID independently. > > I understand that link-scope has benefits over unicast-prefix for scope <=2. > So saying "it is preferred to use ..." or "recommended" would seem ok. > But saying "MUST" - meaning a prohibitation of using unicast-prefix - > seems much to strong unless there are arguments that unicast-prefix > is "broken" (not just "suboptimal") for those scopes. ok, I think it is a good clarification. Thanks, Myung-Ki. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 22:10:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14087 for ; Wed, 22 Oct 2003 22:10:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACUvW-00030v-TD for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 22:10:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N2AEUA011582 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 22:10:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACUvW-00030j-KQ for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 22:10:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14060 for ; Wed, 22 Oct 2003 22:10:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACUvT-00073i-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 22:10:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACUvT-00073d-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 22:10:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACUvL-0002ns-1n; Wed, 22 Oct 2003 22:10:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACUuS-0002e9-IX for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 22:09:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14036 for ; Wed, 22 Oct 2003 22:08:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACUuP-000736-00 for ipv6@ietf.org; Wed, 22 Oct 2003 22:09:05 -0400 Received: from pec.etri.re.kr ([129.254.114.50]) by ietf-mx with esmtp (Exim 4.12) id 1ACUuO-000723-00 for ipv6@ietf.org; Wed, 22 Oct 2003 22:09:04 -0400 Received: from pec.etri.re.kr (mkshin.etri.re.kr [129.254.112.163]) by pec.etri.re.kr (8.12.10/8.12.10) with ESMTP id h9N2NGJ5027287 for ; Thu, 23 Oct 2003 11:23:17 +0900 (KST) Message-ID: <3F97382E.5D26E2C1@pec.etri.re.kr> Date: Thu, 23 Oct 2003 11:08:46 +0900 From: Myung-Ki Shin Organization: ETRI X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Pekka. Pekka Savola wrote: > There are a large number of things to be said, but I'll just stick to two > main points. I've never seen much use for this specification, and I do > not believe this specification is useful as is. As Erik said, I think that this draft has benefits over unicast-prefix for scope <=2. Each node can allocate group ID (32 bits) independently (without any user input, without a fear of collision or any additional mechanisms). > 1) I've never seen a justified reason why this is useful. Apparently, > the document aims to allow a node to generate unique link-scoped multicast > addresses autonomously, without any user input, without a fear of > collision or any additional mechanisms. > > First, there is no guarantee of uniqueness in the first place, as DAD on > the IPv6 link-local unicast address was performed on the address, not the > Interface-ID. In practice, the collisions should be very rare, though. I don't think so. DAD on the IPv6 link-local unicast address also guarantees the uniqueness of Interface-ID in the link-local unicast address. I beleive that there was a consensus on that (when the draft was published). > Second, considering that there is no guaranteed uniqueness, what harm is > there to generate the addresses as currently specified in RFC3306, like: > > - take the prefix of a link-local address (e.g. fe80::/64, or fe80::/10) > - put it in RFC3306 address, like FF32:40:fe80:: or > FF32:A:fe80::. > this would leave 64 bits space to generate an address, assuming the > group-id is 32. > - the 64 bits () could be the interface ID of the link-local > address, or something else completely, like a random number. As you said, this is wrong calculation :) > Third, if we want to go down this particular path, a better solution would > probably be to create a generic "multicast DAD" mechanism to verify the > uniqueness of a group either on a link, or within a multicast scope. If > the applicability would be on the link, even unicast DAD mechanisms could > be reused. I think "multicast DAD" is an another mechanism. I (and many folks) don't want to make a new mechanism for this goal (link-scoped). Link scoped multicast address is more simple and convenient. > 2) the current spec uses the reserved field in such a fashion that plen=0 > and the other nodes not implementing this spec will interpret the > link-local multicast addresses generated using this spec as SSM addresses. In unicast-prefix, to accomplish SSM, a node MUST: [RFC 3306] o Set P = 1. o Set plen = 0. o Set network prefix = 0. Thus, the "network prefix" should be mentioned to distinguished the conflict. In this draft, "Interface ID" of link-scoped mcast address != 0. I think this clarification should be added in current document. Thanks, Myung-Ki. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 22 23:21:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16244 for ; Wed, 22 Oct 2003 23:21:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACW1y-0008AB-OP for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 23:20:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N3Kw1B031373 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 23:20:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACW1y-00089w-Hk for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 23:20:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16195 for ; Wed, 22 Oct 2003 23:20:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACW1w-0007nU-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 23:20:56 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACW1w-0007nR-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 23:20:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACW15-0007uP-OV; Wed, 22 Oct 2003 23:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACW0h-0007o8-FT for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 23:19:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16131 for ; Wed, 22 Oct 2003 23:19:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACW0e-0007mo-00 for ipv6@ietf.org; Wed, 22 Oct 2003 23:19:36 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ACW0e-0007md-00 for ipv6@ietf.org; Wed, 22 Oct 2003 23:19:36 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RDA07>; Wed, 22 Oct 2003 23:19:04 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E01@ftmail.lab.flarion.com> From: Soliman Hesham To: ipv6@ietf.org Subject: RFC 2461- issue list Date: Wed, 22 Oct 2003 23:19:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Folks, This is what I found initially. Please let us know if there are any issues that should be added to the list. Please note that some of these issues might not necessarily be addressed in this revision if they require non-backward compatible changes. The main requirement here is to be backward compatible with our changes. If you wish to express opinions, questions or suggestions please start a separate thread with the issue's header in the subject field. Thanks, Hesham Issue 1: Mixed Host/Router behaviour by Pekka Savola, May 2001 http://www.wcug.wwu.edu/lists/ipng/200105/msg00068.html Erik Nordmark made a comment that the text could be clearer: http://www.wcug.wwu.edu/lists/ipng/200105/msg00077.html Issue 2: Check against the case of preferred lifetime > valid lifetime by jinmei, Dec 2002 http://www.atm.tut.fi/list-archive/ipng/msg07250.html This thread contained a possible updates on the router behavior of sending router advertisements: http://www.atm.tut.fi/list-archive/ipng/msg07402.html Issue 3: On-link assumptions in 2461 considered harmful. This issue was raised by Alain and documented in: draft-ietf-v6ops-onlinkassumption-00.txt draft-ietf-v6ops-v6onbydefault-00.txt Also see related issue in section 2.4 of: http://www.ctie.monash.edu.au/ipv6/draft-jinchoi-ipv6-cRA-00.txt Issue 4: Advertisement lifetime issues raised by Pete Barany Issue 5: Clarifying the use of the M and O flags (raised by Rolf and others during V6ops meeting in San Francisco) Issue 6: The prefix length field in the prefix option and its consistency with the fixed prefix size (64 bits) in RFC 3513. SEND issues: Issue 7: All the security discussions (e.g. assuming that AH or ESP can be added to the ND messages) will need to be put in the context of SEND. Issue 8: Security considerations section needs to consider issues in: draft-ietf-send-psreq-04 Issue 9: The chicken and egg problem for ND security using IKE as specified in: draft-arkko-icmpv6-ike-effects-02 and manual SAs issues addressed in: draft-arkko-manual-icmpv6-sas-02 MIP issues: Issue 10: Reducing MIN_DELAY_BETWEEN_RAS from 3 seconds to 50 ms as specified in MIPv6 (many emails on the MIP mailing list in October and November 2002) Issue 11: Eliminating the random delays required before sending an RS when a mobile node does a handover to a new link. The random delay imposed by 2461 significantly increases the movement detection time for mobile nodes Issue 12: Eliminating the random delays required in 2461 when a router sends a solicited RA. See : draft-mkhalil-ipv6-fastra-04.txt Issue 13: Impacts of the omission of a prefix option. section 2.2 in : http://www.ctie.monash.edu.au/ipv6/draft-jinchoi-ipv6-cRA-00.txt describes the impacts of omitting a prefix option from an RA on movement detection for mobile nodes. RFC 2461 does not require options to be present in every RA. Issue 14: Link ids required to aid with movement detection. see: http://www.ietf.org/internet-drafts/draft-pentland-mobileip-linkid-00.txt Finally, I recall (but not clearly) some discussions on the clarity of 2461 when it comes to multihomed hosts. But I haven't managed to find the relevant thread(s) in the archive. So if you have an issue to add please let me know. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 01:50:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20710 for ; Thu, 23 Oct 2003 01:50:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACYMl-0001M9-9W for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 01:50:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N5oZPo005210 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 01:50:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACYMl-0001Lx-1r for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 01:50:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20689 for ; Thu, 23 Oct 2003 01:50:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACYMh-0001dL-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 01:50:31 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACYMh-0001dI-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 01:50:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACYMF-00018H-24; Thu, 23 Oct 2003 01:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACYLz-00011G-A2 for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 01:49:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20678 for ; Thu, 23 Oct 2003 01:49:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACYLv-0001cz-00 for ipv6@ietf.org; Thu, 23 Oct 2003 01:49:43 -0400 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx with esmtp (Exim 4.12) id 1ACYLv-0001cw-00 for ipv6@ietf.org; Thu, 23 Oct 2003 01:49:43 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 8F5F3FCBD; Thu, 23 Oct 2003 01:49:44 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 23 Oct 2003 01:49:44 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-soliman-ipv6-2461-bis-00.tGoxt X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 23 Oct 2003 01:49:43 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA16E@tayexc13.americas.cpqcorp.net> Thread-Topic: I-D ACTION:draft-soliman-ipv6-2461-bis-00.tGoxt Thread-Index: AcOZC6irxBAP+MQySdC0PrjnIpQtAAAHPukg From: "Bound, Jim" To: "Fred Templin" , Cc: X-OriginalArrivalTime: 23 Oct 2003 05:49:44.0266 (UTC) FILETIME=[75A062A0:01C39929] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Process Issue: Not to Fred. > I note the following differences between this document and RFC 2461: >=20 > 1. Two new author names added in upper l.h. corner of P. 1; > date and document I-D name are changed on same page. I don't think so. This is a 90+ page document. Have Thomas and Erik stated they will not work the updates? We have been told to reduce authors on specs by IETF not add them. =20 Second I suggest not an update to 2461 but a new document highlighting new features and interpretation. =20 More in depth technical response once all is clear of the proposed work and change or if this is even a WG document. We have many precedents to add value to core specs in the IETF without whacking a core spec. This is a core spec the bar will be high to update it and I hope the WG supports that high bar. /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 02:14:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03420 for ; Thu, 23 Oct 2003 02:14:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACYji-0007BN-T1 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 02:14:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N6EIUe027610 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 02:14:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACYji-0007BF-JE for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 02:14:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03367 for ; Thu, 23 Oct 2003 02:14:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACYje-0001rz-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 02:14:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACYje-0001rw-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 02:14:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACYjS-00073w-4c; Thu, 23 Oct 2003 02:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACYiy-0006yS-K6 for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 02:13:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03253 for ; Thu, 23 Oct 2003 02:13:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACYiu-0001qE-00 for ipv6@ietf.org; Thu, 23 Oct 2003 02:13:28 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACYiu-0001oZ-00 for ipv6@ietf.org; Thu, 23 Oct 2003 02:13:28 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9N6Cl931241; Thu, 23 Oct 2003 09:12:47 +0300 Date: Thu, 23 Oct 2003 09:12:46 +0300 (EEST) From: Pekka Savola To: Myung-Ki Shin cc: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses" In-Reply-To: <3F97382E.5D26E2C1@pec.etri.re.kr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Thu, 23 Oct 2003, Myung-Ki Shin wrote: [...] > As Erik said, I think that this draft has benefits over unicast-prefix for > scope <=2. > Each node can allocate group ID (32 bits) independently (without any user > input, without a fear of collision or any additional mechanisms). There is 32 bits worth of group ID to distinguish between the groups the different nodes use. There is about 48 bits to distinguish between the nodes on the same link. Don't you think this is already enough? There is no need to define precise external semantics (like embedding the interface ID) to what the addresses should include (i.e., the neighbor node doesn't need to know which address the other node would use for multicasting group-id X). It's just enough that they're reasonably unique. This can be done using a number of techniques, none of which warrant a Protocol Action from the IETF. > > First, there is no guarantee of uniqueness in the first place, as DAD on > > the IPv6 link-local unicast address was performed on the address, not the > > Interface-ID. In practice, the collisions should be very rare, though. > > I don't think so. > DAD on the IPv6 link-local unicast address also guarantees the uniqueness > of Interface-ID in the link-local unicast address. > I beleive that there was a consensus on that (when the draft was > published). No, I think it was specifically some form of consensus that DAD is not DIID. This is true in particular with unicast prefixes. This happens with link-local prefixes as well, if you use e.g. fe81::1 and fe80::1 on the same physical link but pointing to different nodes. (Btw, does the spec say the interface-ID must be taken from the link-local address? If not, it will have problems with manually configured global addresses..) > > Second, considering that there is no guaranteed uniqueness, what harm is > > there to generate the addresses as currently specified in RFC3306, like: > > > > - take the prefix of a link-local address (e.g. fe80::/64, or fe80::/10) > > - put it in RFC3306 address, like FF32:40:fe80:: or > > FF32:A:fe80::. > > this would leave 64 bits space to generate an address, assuming the > > group-id is 32. > > - the 64 bits () could be the interface ID of the link-local > > address, or something else completely, like a random number. > > As you said, this is wrong calculation :) .. but this doesn't nullify the usefulness of the algorithm. Just insert something probably unique (a random number, MAC-address, etc.) in the 48 bits and you're done. > > Third, if we want to go down this particular path, a better solution would > > probably be to create a generic "multicast DAD" mechanism to verify the > > uniqueness of a group either on a link, or within a multicast scope. If > > the applicability would be on the link, even unicast DAD mechanisms could > > be reused. > > I think "multicast DAD" is an another mechanism. > I (and many folks) don't want to make a new mechanism for this goal > (link-scoped). Agreed. > Link scoped multicast address is more simple and convenient. Inventing an address without additional specification would be even simpler. > > 2) the current spec uses the reserved field in such a fashion that plen=0 > > and the other nodes not implementing this spec will interpret the > > link-local multicast addresses generated using this spec as SSM addresses. > > In unicast-prefix, > to accomplish SSM, a node MUST: [RFC 3306] > > o Set P = 1. > o Set plen = 0. > o Set network prefix = 0. > > Thus, the "network prefix" should be mentioned to distinguished the > conflict. > In this draft, "Interface ID" of link-scoped mcast address != 0. > I think this clarification should be added in current document. If an SSM implementation checks for FF3x::/32 (as described in RFC 3306 section 6), and not for FF3x::/96 (as described in RFC 3306 section 7), but will not implement this specification, there will be lots of trouble. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 02:38:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04642 for ; Thu, 23 Oct 2003 02:38:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZ6w-0005eY-3g for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 02:38:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N6cHEJ021680 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 02:38:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZ6s-0005dE-QF for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 02:38:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04610 for ; Thu, 23 Oct 2003 02:38:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZ6p-0002Dd-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 02:38:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACZ6o-0002Da-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 02:38:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZ6g-0005Tq-OT; Thu, 23 Oct 2003 02:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZ60-00051b-3A for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 02:37:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04585 for ; Thu, 23 Oct 2003 02:37:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZ5w-0002Cw-00 for ipv6@ietf.org; Thu, 23 Oct 2003 02:37:16 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1ACZ5v-0002Cs-00 for ipv6@ietf.org; Thu, 23 Oct 2003 02:37:15 -0400 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9N6bBed010036 for ; Thu, 23 Oct 2003 08:37:11 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v604) Content-Transfer-Encoding: 7bit Message-Id: <579AE850-0523-11D8-A9F8-00039388672E@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ipv6@ietf.org From: Iljitsch van Beijnum Subject: "RFC 2461bis" issue: DNS configuration Date: Thu, 23 Oct 2003 08:37:15 +0200 X-Mailer: Apple Mail (2.604) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I haven't been on this list very long so I'm unaware of the reasons to revisit 2461 and I don't know whether the following issue has been discussed, but: Why is there no mechanism to learn DNS addresses through router advertisements? It is currently possible to attach a host to a link with one or more IPv6 routers and have the host automatically discover all the paramaters needed to connect to the IPv6 internet... except DNS servers. This is the absolute number one annoyance when running IPv6. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 02:48:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04994 for ; Thu, 23 Oct 2003 02:48:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZGS-00009q-SH for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 02:48:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N6m8GA000607 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 02:48:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZGS-00009i-BF for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 02:48:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04959 for ; Thu, 23 Oct 2003 02:47:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZGO-0002LS-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 02:48:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACZGO-0002LP-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 02:48:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZGM-000051-0u; Thu, 23 Oct 2003 02:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZFX-0008Nf-1a for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 02:47:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04940 for ; Thu, 23 Oct 2003 02:47:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZFT-0002Kr-00 for ipv6@ietf.org; Thu, 23 Oct 2003 02:47:07 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ACZFS-0002Ke-00 for ipv6@ietf.org; Thu, 23 Oct 2003 02:47:06 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RDBJN>; Thu, 23 Oct 2003 02:46:36 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E07@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Iljitsch van Beijnum'" , ipv6@ietf.org Subject: RE: "RFC 2461bis" issue: DNS configuration Date: Thu, 23 Oct 2003 02:46:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > I haven't been on this list very long so I'm unaware of the > reasons to > revisit 2461 and I don't know whether the following issue has been > discussed, but: > > Why is there no mechanism to learn DNS addresses through router > advertisements? > > It is currently possible to attach a host to a link with one or more > IPv6 routers and have the host automatically discover all the > paramaters needed to connect to the IPv6 internet... except DNS > servers. > > This is the absolute number one annoyance when running IPv6. => A couple of years ago there was a DT that compared several different ways of achieving this. The proposal you mentioned was one of those addressed. The DT settled on assigning 3 different site-local addresses that can be reserved for DNS servers. The solution was documented in a draft (I believe Itojun, Alain and Dave Thaler co-authored it). But this idea didn't get concensus in the WG and I think the draft is dead now but I'm not sure. DHCPv6 allows for DNS configuration in hosts among other things. Hesham > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 02:59:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05312 for ; Thu, 23 Oct 2003 02:59:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZRG-0003HX-DS for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 02:59:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N6xIjw012611 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 02:59:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZRG-0003HK-5A for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 02:59:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05279 for ; Thu, 23 Oct 2003 02:59:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZRC-0002SP-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 02:59:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACZRB-0002SM-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 02:59:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZR1-00039G-QG; Thu, 23 Oct 2003 02:59:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZQq-00036n-RT for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 02:58:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05254 for ; Thu, 23 Oct 2003 02:58:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZQm-0002RG-00 for ipv6@ietf.org; Thu, 23 Oct 2003 02:58:48 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1ACZQm-0002R1-00 for ipv6@ietf.org; Thu, 23 Oct 2003 02:58:48 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HN7008867D4AE@mailout2.samsung.com> for ipv6@ietf.org; Thu, 23 Oct 2003 15:58:17 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HN7004567CB0P@mailout2.samsung.com> for ipv6@ietf.org; Thu, 23 Oct 2003 15:57:47 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HN700DDT7CAKF@mmp2.samsung.com> for ipv6@ietf.org; Thu, 23 Oct 2003 15:57:46 +0900 (KST) Date: Thu, 23 Oct 2003 15:58:04 +0900 From: Soohong Daniel Park Subject: RE: "RFC 2461bis" issue: DNS configuration In-reply-to: <579AE850-0523-11D8-A9F8-00039388672E@muada.com> To: "'Iljitsch van Beijnum'" , ipv6@ietf.org Message-id: <011e01c39933$01b496e0$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hello This issue was discussed at the dnsop wg in vienna and is still work in progress... You can touch with below draft related this issue. http://www.ietf.org/internet-drafts/draft-jeong-dnsop-ipv6-dns-discovery -00.txt Related drafts http://www.ietf.org/internet-drafts/draft-jeong-nemo-ro-ndproxy-01.txt http://www.ietf.org/internet-drafts/draft-park-manet-dns-discovery-globa lv6-00.txt Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On > Behalf Of Iljitsch van Beijnum > Sent: Thursday, October 23, 2003 3:37 PM > To: ipv6@ietf.org > Subject: "RFC 2461bis" issue: DNS configuration > > > I haven't been on this list very long so I'm unaware of the > reasons to > revisit 2461 and I don't know whether the following issue has been > discussed, but: > > Why is there no mechanism to learn DNS addresses through router > advertisements? > > It is currently possible to attach a host to a link with one or more > IPv6 routers and have the host automatically discover all the > paramaters needed to connect to the IPv6 internet... except DNS > servers. > > This is the absolute number one annoyance when running IPv6. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 03:02:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05452 for ; Thu, 23 Oct 2003 03:02:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZTz-0004BS-C2 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 03:02:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N727Nc016076 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 03:02:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZTz-0004BD-1f for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 03:02:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05430 for ; Thu, 23 Oct 2003 03:01:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZTv-0002VS-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 03:02:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACZTu-0002VP-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 03:02:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZTu-00043s-5I; Thu, 23 Oct 2003 03:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZTP-0003xz-88 for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 03:01:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05399 for ; Thu, 23 Oct 2003 03:01:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZTL-0002UV-00 for ipv6@ietf.org; Thu, 23 Oct 2003 03:01:27 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1ACZTK-0002UM-00 for ipv6@ietf.org; Thu, 23 Oct 2003 03:01:26 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HN70089X7HKZF@mailout1.samsung.com> for ipv6@ietf.org; Thu, 23 Oct 2003 16:00:56 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HN7004FQ7GYMN@mailout1.samsung.com> for ipv6@ietf.org; Thu, 23 Oct 2003 16:00:35 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HN7006MW7GYXC@mmp1.samsung.com> for ipv6@ietf.org; Thu, 23 Oct 2003 16:00:34 +0900 (KST) Date: Thu, 23 Oct 2003 16:00:52 +0900 From: Soohong Daniel Park Subject: RE: "RFC 2461bis" issue: DNS configuration In-reply-to: <748C6D0A58C0F94CA63C198B6674697A01922E07@ftmail.lab.flarion.com> To: "'Soliman Hesham'" , "'Iljitsch van Beijnum'" , ipv6@ietf.org Message-id: <011f01c39933$659e2270$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hello Hesham >DHCPv6 allows for DNS configuration in hosts among other things. Please don't definitely say that. As I said, RA based DNS discovery is work in progress. Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 03:10:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05681 for ; Thu, 23 Oct 2003 03:10:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZbt-0006c3-VX for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 03:10:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N7AH5d025413 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 03:10:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZbt-0006bo-R1 for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 03:10:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05654 for ; Thu, 23 Oct 2003 03:10:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZbp-0002aK-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 03:10:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACZbp-0002aD-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 03:10:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZbf-0006RF-NS; Thu, 23 Oct 2003 03:10:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZb9-0006KS-14 for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 03:09:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05637 for ; Thu, 23 Oct 2003 03:09:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZb4-0002Zj-00 for ipv6@ietf.org; Thu, 23 Oct 2003 03:09:26 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1ACZb4-0002Zg-00 for ipv6@ietf.org; Thu, 23 Oct 2003 03:09:26 -0400 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9N79Med010431 for ; Thu, 23 Oct 2003 09:09:22 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v604) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ipv6@ietf.org From: Iljitsch van Beijnum Subject: "RFC 2461bis" issue: MTU handling Date: Thu, 23 Oct 2003 09:09:26 +0200 X-Mailer: Apple Mail (2.604) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm not sure this should go into a replacement specification for RFC 2461, but I'll bring it up anyway: Currently, routers can advertise an MTU for a link. That's nice. But what we really need is a way for hosts to find out the MTU each individual neighbor can handle. 100 Mbps and slower ethernet interfaces can typically handle only the standard 1500 byte ethernet MTU, while gigabit ethernet interfaces usually support a much larger MTU. However, in most cases hosts with different MTUs are present on the same subnet, so simply advertising a larger MTU wouldn't solve this. (Not that this would work anyway as hosts are instructed to only listen to MTU advertisements where the MTU is between 1280 and 1500 (for ethernet).) But if hosts can tell each other the MTU they support, each set of two hosts is always able to use the largest possible MTU between them. (This would also require a new link MTU option that conveys the maximum MTU the lower layer equipment supports. Switches have their own MTU and even some hubs start doing strange things when a larger than expected MTU is used.) BTW, some duplication seems to have crept into the document: variable MTU - a link that does not have a well-defined MTU (e.g., IEEE 802.5 token rings). Many links (e.g., Ethernet) have a standard MTU defined by the link- layer protocol or by the specific document describing how to run IP over the link layer. variable MTU - Neighbor Discovery allows routers to specify a MTU for the link, which all nodes then use. All nodes on a link must use the same MTU (or Maximum Receive Unit) in order for multicast to work properly. Otherwise when multicasting a sender, which can not know which nodes will receive the packet, could not determine a minimum packet size all receivers can process. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 03:14:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05850 for ; Thu, 23 Oct 2003 03:14:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZfa-0007db-IB for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 03:14:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N7E68C029353 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 03:14:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZfa-0007dM-4n for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 03:14:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05820 for ; Thu, 23 Oct 2003 03:13:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZfX-0002dZ-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 03:14:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACZfX-0002dW-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 03:14:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZfW-0007ZC-8C; Thu, 23 Oct 2003 03:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZek-0007Rr-Vh for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 03:13:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05806 for ; Thu, 23 Oct 2003 03:13:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZei-0002dB-00 for ipv6@ietf.org; Thu, 23 Oct 2003 03:13:12 -0400 Received: from coconut.itojun.org ([219.101.47.130]) by ietf-mx with esmtp (Exim 4.12) id 1ACZeh-0002d8-00 for ipv6@ietf.org; Thu, 23 Oct 2003 03:13:12 -0400 Received: by coconut.itojun.org (Postfix, from userid 1001) id E8E569A; Thu, 23 Oct 2003 16:13:11 +0900 (JST) To: iljitsch@muada.com Cc: ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: MTU handling In-Reply-To: Your message of "Thu, 23 Oct 2003 09:09:26 +0200" References: X-Mailer: Cue version 0.6 (031002-0709/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031023071311.E8E569A@coconut.itojun.org> Date: Thu, 23 Oct 2003 16:13:11 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > I'm not sure this should go into a replacement specification for RFC > 2461, but I'll bring it up anyway: > > Currently, routers can advertise an MTU for a link. That's nice. But > what we really need is a way for hosts to find out the MTU each > individual neighbor can handle. 100 Mbps and slower ethernet interfaces > can typically handle only the standard 1500 byte ethernet MTU, while > gigabit ethernet interfaces usually support a much larger MTU. > > However, in most cases hosts with different MTUs are present on the > same subnet, so simply advertising a larger MTU wouldn't solve this. > (Not that this would work anyway as hosts are instructed to only listen > to MTU advertisements where the MTU is between 1280 and 1500 (for > ethernet).) > > But if hosts can tell each other the MTU they support, each set of two > hosts is always able to use the largest possible MTU between them. > (This would also require a new link MTU option that conveys the maximum > MTU the lower layer equipment supports. Switches have their own MTU and > even some hubs start doing strange things when a larger than expected > MTU is used.) the assumption made in RFC2461 is that the link MTU is constant over the link, i guess. i don't think it is necessary to make MTU negotiable between peers, it would complicate too many things. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 03:15:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05977 for ; Thu, 23 Oct 2003 03:15:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZge-00088l-Rv for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 03:15:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N7FCIn031283 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 03:15:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZge-00088U-EP for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 03:15:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05905 for ; Thu, 23 Oct 2003 03:15:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZgc-0002fj-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 03:15:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACZgb-0002fg-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 03:15:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZgV-0007zF-J0; Thu, 23 Oct 2003 03:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZgE-0007wP-JQ for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 03:14:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05875 for ; Thu, 23 Oct 2003 03:14:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZgC-0002f0-00 for ipv6@ietf.org; Thu, 23 Oct 2003 03:14:44 -0400 Received: from coconut.itojun.org ([219.101.47.130]) by ietf-mx with esmtp (Exim 4.12) id 1ACZgB-0002eo-00 for ipv6@ietf.org; Thu, 23 Oct 2003 03:14:43 -0400 Received: by coconut.itojun.org (Postfix, from userid 1001) id 6158491; Thu, 23 Oct 2003 16:14:43 +0900 (JST) To: soohong.park@samsung.com Cc: H.Soliman@flarion.com, iljitsch@muada.com, ipv6@ietf.org Subject: RE: "RFC 2461bis" issue: DNS configuration In-Reply-To: Your message of "Thu, 23 Oct 2003 16:00:52 +0900" <011f01c39933$659e2270$b7cbdba8@daniel> References: <011f01c39933$659e2270$b7cbdba8@daniel> X-Mailer: Cue version 0.6 (031002-0709/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031023071443.6158491@coconut.itojun.org> Date: Thu, 23 Oct 2003 16:14:43 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > >DHCPv6 allows for DNS configuration in hosts among other things. > Please don't definitely say that. As I said, RA based DNS discovery > is work in progress. Hesham's statement does not reject RA-based DNS discovery, it seems to me. there's nothing wrong with the above-quoted line. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 03:19:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06110 for ; Thu, 23 Oct 2003 03:19:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZkS-00010h-OL for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 03:19:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N7J8VV003799 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 03:19:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZkR-0000wo-L8 for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 03:19:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06066 for ; Thu, 23 Oct 2003 03:18:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZkP-0002jK-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 03:19:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACZkO-0002jH-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 03:19:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZkM-0000qo-SE; Thu, 23 Oct 2003 03:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZjp-0000bC-RO for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 03:18:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06055 for ; Thu, 23 Oct 2003 03:18:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZjn-0002iy-00 for ipv6@ietf.org; Thu, 23 Oct 2003 03:18:27 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1ACZjm-0002ip-00 for ipv6@ietf.org; Thu, 23 Oct 2003 03:18:26 -0400 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9N7IJed010539; Thu, 23 Oct 2003 09:18:19 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922E07@ftmail.lab.flarion.com> References: <748C6D0A58C0F94CA63C198B6674697A01922E07@ftmail.lab.flarion.com> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <16BB6224-0529-11D8-A9F8-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org From: Iljitsch van Beijnum Subject: Re: "RFC 2461bis" issue: DNS configuration Date: Thu, 23 Oct 2003 09:18:24 +0200 To: Soliman Hesham X-Mailer: Apple Mail (2.604) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 23 okt 2003, at 8:46, Soliman Hesham wrote: >> Why is there no mechanism to learn DNS addresses through router >> advertisements? > => A couple of years ago there was a DT that compared several > different ways of achieving this. The proposal you mentioned > was one of those addressed. The DT settled on assigning > 3 different site-local addresses that can be reserved for > DNS servers. The solution was documented in a draft (I believe > Itojun, Alain and Dave Thaler co-authored it). But this idea > didn't get concensus in the WG and I think the draft is dead > now but I'm not sure. DHCPv6 allows for DNS configuration in > hosts among other things. Ok, I only have one word for this: unacceptable. I stronly suggest everyone who was against this to try running IPv6 for a few minutes. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 03:25:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06324 for ; Thu, 23 Oct 2003 03:25:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZqH-0002hN-JG for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 03:25:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N7P9e6010372 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 03:25:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZqH-0002hD-AT for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 03:25:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06273 for ; Thu, 23 Oct 2003 03:24:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZqE-0002nq-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 03:25:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACZqE-0002nn-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 03:25:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZqA-0002bS-SS; Thu, 23 Oct 2003 03:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZpA-00029i-Ro for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 03:24:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06186 for ; Thu, 23 Oct 2003 03:23:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZp8-0002mJ-00 for ipv6@ietf.org; Thu, 23 Oct 2003 03:23:58 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1ACZp7-0002mG-00 for ipv6@ietf.org; Thu, 23 Oct 2003 03:23:57 -0400 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9N7Nped010598; Thu, 23 Oct 2003 09:23:52 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20031023071311.E8E569A@coconut.itojun.org> References: <20031023071311.E8E569A@coconut.itojun.org> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org From: Iljitsch van Beijnum Subject: Re: "RFC 2461bis" issue: MTU handling Date: Thu, 23 Oct 2003 09:23:56 +0200 To: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Mailer: Apple Mail (2.604) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 23 okt 2003, at 9:13, Jun-ichiro itojun Hagino wrote: > the assumption made in RFC2461 is that the link MTU is constant > over the link, i guess. i don't think it is necessary to make > MTU negotiable between peers, it would complicate too many things. What would it complicate? Obviously nobody is going to force anyone to implement such an option; it would only be used between consenting hosts. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 03:40:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06898 for ; Thu, 23 Oct 2003 03:40:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACa54-0007mD-EB for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 03:40:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N7eQhw029893 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 03:40:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACa54-0007m4-84 for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 03:40:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06866 for ; Thu, 23 Oct 2003 03:40:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACa51-00031Q-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 03:40:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACa51-00031N-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 03:40:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACa4j-0007bz-Ru; Thu, 23 Oct 2003 03:40:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACa4K-0007WQ-T5 for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 03:39:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06851 for ; Thu, 23 Oct 2003 03:39:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACa4I-00030p-00 for ipv6@ietf.org; Thu, 23 Oct 2003 03:39:38 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACa4H-00030m-00 for ipv6@ietf.org; Thu, 23 Oct 2003 03:39:37 -0400 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id IAA22453 for ; Thu, 23 Oct 2003 08:39:37 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id IAA10366 for ; Thu, 23 Oct 2003 08:39:37 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h9N7dbN18334 for ipv6@ietf.org; Thu, 23 Oct 2003 08:39:37 +0100 Date: Thu, 23 Oct 2003 08:39:37 +0100 From: Tim Chown To: ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: DNS configuration Message-ID: <20031023073937.GB18135@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <748C6D0A58C0F94CA63C198B6674697A01922E07@ftmail.lab.flarion.com> <16BB6224-0529-11D8-A9F8-00039388672E@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16BB6224-0529-11D8-A9F8-00039388672E@muada.com> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Iljitsch, I agree. This has been discussed a lot on the dnsop list... there is currently no consensus about DHCPv6(Lite) vs RA-based discovery. It will be interesting to see what the Moonv6 work may have to say in this area, as the issue I'm sure will have been encountered there. There are still very few people working in networks where IPv6 transport DNS lookup is a requirement, hence this issue has seen slow progress. I am in the RA camp, but I agree DHCPv6 will be used for other things (e.g. NTP server), so in cases where a DHCPv6 server is present it will be able to be used for resolver discovery. But I believe we should have a RA based method also. The general thrust of the DHCPv6 camp argument is that in any situation where a router is configured to pass DNS info in a RA extension it could equally be configured to do so using DHCPv6 (Lite), or could forward to a DHCPv6 server using the DHCPv6 relay agent function. The second argument used by the DHCPv6 camp is that having two methods may lead to complexity, and problems in troubleshooting. The third is a fear of creeping featurism - where is the line over which you don't step for RA extensions? DNS resolver? Search path? NTP? But there are some clear advantages for the RA method, like the ability to multicast the information in a one-way message, where DHCPv6 must always rely on a client-server exchange. Both methods have security considerations. There seem to be a handful DHCPv6 implementations, but no stripped down DHCPv6 Lite implementations yet (the Lite version not maintaining state for IP leases etc). Tim On Thu, Oct 23, 2003 at 09:18:24AM +0200, Iljitsch van Beijnum wrote: > On 23 okt 2003, at 8:46, Soliman Hesham wrote: > > >>Why is there no mechanism to learn DNS addresses through router > >>advertisements? > > >=> A couple of years ago there was a DT that compared several > >different ways of achieving this. The proposal you mentioned > >was one of those addressed. The DT settled on assigning > >3 different site-local addresses that can be reserved for > >DNS servers. The solution was documented in a draft (I believe > >Itojun, Alain and Dave Thaler co-authored it). But this idea > >didn't get concensus in the WG and I think the draft is dead > >now but I'm not sure. DHCPv6 allows for DNS configuration in > >hosts among other things. > > Ok, I only have one word for this: unacceptable. > > I stronly suggest everyone who was against this to try running IPv6 for > a few minutes. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 03:51:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07308 for ; Thu, 23 Oct 2003 03:51:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACaFf-0002Q3-1v for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 03:51:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N7pMWL009293 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 03:51:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACaFd-0002Po-Sl for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 03:51:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07267 for ; Thu, 23 Oct 2003 03:51:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACaFb-0003Ak-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 03:51:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACaFa-0003Ah-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 03:51:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACaFL-0002G3-5E; Thu, 23 Oct 2003 03:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACaEj-00026l-Sz for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 03:50:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07251 for ; Thu, 23 Oct 2003 03:50:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACaEh-0003AE-00 for ipv6@ietf.org; Thu, 23 Oct 2003 03:50:23 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACaEg-0003A2-00 for ipv6@ietf.org; Thu, 23 Oct 2003 03:50:22 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9N7naR32526; Thu, 23 Oct 2003 10:49:36 +0300 Date: Thu, 23 Oct 2003 10:49:36 +0300 (EEST) From: Pekka Savola To: Jun-ichiro itojun Hagino cc: iljitsch@muada.com, Subject: Re: "RFC 2461bis" issue: MTU handling In-Reply-To: <20031023071311.E8E569A@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Thu, 23 Oct 2003, Jun-ichiro itojun Hagino wrote: [...] > the assumption made in RFC2461 is that the link MTU is constant > over the link, i guess. i don't think it is necessary to make > MTU negotiable between peers, it would complicate too many things. FWIW, I agree with this assumption. Really, if you want to put different MTU's on the same link and want to optimize it, use multiple links.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 04:28:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08327 for ; Thu, 23 Oct 2003 04:28:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACapg-0002iO-UD for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 04:28:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N8SaVY010435 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 04:28:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACapg-0002iE-KL for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 04:28:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08298 for ; Thu, 23 Oct 2003 04:28:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACapd-0003a8-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 04:28:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACapd-0003a5-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 04:28:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACaoA-0002G0-81; Thu, 23 Oct 2003 04:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACanW-00027M-PN for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 04:26:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08270 for ; Thu, 23 Oct 2003 04:26:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACanT-0003Z0-00 for ipv6@ietf.org; Thu, 23 Oct 2003 04:26:19 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1ACanT-0003Yx-00 for ipv6@ietf.org; Thu, 23 Oct 2003 04:26:19 -0400 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9N8QDed011343; Thu, 23 Oct 2003 10:26:14 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9342DB02-0532-11D8-A9F8-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: Jun-ichiro itojun Hagino , From: Iljitsch van Beijnum Subject: Re: "RFC 2461bis" issue: MTU handling Date: Thu, 23 Oct 2003 10:26:18 +0200 To: Pekka Savola X-Mailer: Apple Mail (2.604) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 23 okt 2003, at 9:49, Pekka Savola wrote: >> the assumption made in RFC2461 is that the link MTU is constant >> over the link, i guess. i don't think it is necessary to make >> MTU negotiable between peers, it would complicate too many things. > FWIW, I agree with this assumption. Really, if you want to put > different > MTU's on the same link and want to optimize it, use multiple links.. Could you people be any more dismissive if you tried? I wish I could sentence you both to three months NOC duty. See http://sd.wareonearth.com/~phil/net/jumbo/ for some links surrounding this issue. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 04:30:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08412 for ; Thu, 23 Oct 2003 04:30:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACarD-0003NV-5n for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 04:30:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N8UBSG012985 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 04:30:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACarC-0003NH-Ns for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 04:30:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08384 for ; Thu, 23 Oct 2003 04:30:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACar9-0003cU-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 04:30:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACar9-0003cR-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 04:30:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACar6-0003AZ-Ee; Thu, 23 Oct 2003 04:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACaqH-0002v8-2k for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 04:29:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08352 for ; Thu, 23 Oct 2003 04:29:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACaqD-0003bF-00 for ipv6@ietf.org; Thu, 23 Oct 2003 04:29:09 -0400 Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx with esmtp (Exim 4.12) id 1ACaqD-0003aG-00 for ipv6@ietf.org; Thu, 23 Oct 2003 04:29:09 -0400 Received: from gih505.telstra.net (dhcp2.potaroo.net [203.10.60.2]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h9N8SURc044738; Thu, 23 Oct 2003 18:28:35 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20031023182433.00b4ec48@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 23 Oct 2003 18:28:04 +1000 To: Brian Haberman , ipv6@ietf.org From: Geoff Huston Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" In-Reply-To: <3F96659F.4040702@innovationslab.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >Please send substantive comments to the ipv6 mailing list, and minor >editorial comments to the authors. This last call period will end on 5 >November 2003. I do not believe that this document is ready for Proposed Standard. My comments (both as suggested text corrections and as more substantive comments on content) are as follows: Section 3.2 ----------- "The centrally assigned global IDs have a much higher probability that they are unique" The intent of the central assignment function is to ensure uniqueness. Therefore the wording should be: "The centrally assigned global IDs are uniquely assigned" Also: "It is recommended that sites planning to use Local IPv6 addresses for extensive inter-site communication use a centrally assigned prefix as the possibility of any conflicts is lower." should be re-worded as: "It is recommended that sites planning to use Local IPv6 addresses for extensive inter-site communication use a centrally assigned prefix as there is no possibility of prefix assignment conflicts." Section 3.2.1 ------------- "This to ensure that there is not any relationship between allocations and to help clarify that these prefixes are not intended to be routed globally." Clumsy grammar and perhaps additional words are appropriate. Suggest change to: "This to ensure that there is no relationship between allocations and to help clarify that these prefixes are not intended to be routed globally by eliminating aggregation possibilities." Also: "This is easiest to accomplish if there is a single source of the assignments." and "One time non-refundable allocation fee in the order of 10 Euros (at January 1, 2004 exchange rates) per allocation." I question the validity of specifying a single source coupled with service fees in a document such as this. This appears to be creating regulatory issues of establishing a global monopoly coupled with price fixing. An alternate wording that may mitigate this to some extent is to change the second sentence to remove this item from requirements, and instead phrase this as a recommendation, namely: "It is recommended that the registry operate using a service regime of a single service fee per allocation bearing in mind that the service should be accessible and affordable to small sites in all parts of the world." Also: "The reason for the one time 10 Euro charge for each prefix is to provide a barrier to any hoarding of the these allocations but at the same time keep the cost low enough to not create a barrier to anyone needing one. The charge is one time to eliminate the need for an ongoing relationship with the allocation authority. The charge is non-refundable in order to keep overhead low." change to: "The reason for the per-prefix allocation service fee is to allow the service to operate on a financially sustainable basis. A service fee also creates an externality of a barrier to any hoarding of the these allocations. The fee should be low enough to not create a barrier to anyone needing one. The charge is one time to eliminate the need for an ongoing relationship with the allocation authority. The charge is non- refundable as the allocation is irrevocable." Also: "It is escrowed to insure there are no duplicate allocations and in case it is needed in the future (e.g., to resolve duplicate allocation disputes). add the case of a potential change in allocation registry operator. i.e. "It is escrowed to insure there are no duplicate allocations and in case it is needed in the future (e.g., to resolve duplicate allocation disputes, or to support a change of central allocation registry operator). Also: "This document directs the IANA, in section 13.0, to delegate the FC00::/8 prefix to an allocation authority to allocate centrally assigned /48 prefixes consistent with the requirements defined in this section." change requirements to requirements and recommendations "This document directs the IANA, in section 13.0, to delegate the FC00::/8 prefix to an allocation authority to allocate centrally assigned /48 prefixes consistent with the requirements and recommendations listed in this section." Section 3.3 ----------- "Rather, these prefixes are globally unique, and as such, their applicability exceeds the current site-local addresses." Should the word "current" be used in this context? Perhaps: "Rather, these prefixes are globally unique, and as such, their applicability exceeds the previously defined site-local addresses." Section 7.0 ----------- It may be worth mentioning that DNS systems should be configured to prevent queries relating to such addresses to be passed into the public DNS system. To quote the AS112 project home page: "Because most answers generated by the Internet's root name server system are negative, and many of those negative answers are in response to PTR queries for RFC1918 and other ambiguous addresses" (http://www.as112.net/) Section 13.0 ------------ "This allocation authority shall comply with the requirements described in section 3.2 of this document, including in particular the charging of a modest one-time fee, with any profit being used for the public good in connection with the Internet." It is noted that there are significant problems with this proposed approach to directions to IANA, particularly with the noted concept that this is a for-profit activity and IANA is, in effect, being directed to be in the position of selecting a global monopoly operator. The indeterminate nature of a fair, open and reasonable definition of "the public good" is also a problem in the context of these instructions to IANA. Some of the lessons learned from DNS administration over the past decade would indicate that this is not a sensible directive to pass to IANA, as it is unlikely to be reasonably implemented in this precise form. Additional Comments -------------------- draft-huston-ipv6-local-use-comments-01.txt contains a number of additional comments that are not addressed in this draft. In particular, section 5 of that draft raises issues concerning - the structure of an allocation fee being a form of monopoly rental. (a service fee would be more viable from a regulatory perspective) (section 5.1 of the comments draft) - the recording of allocations (section 5.4 of the comments draft) - reverse mapping of such addresses in ip6.arpa (section 5.5 of the comments draft) regards, Geoff Huston -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 04:39:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08690 for ; Thu, 23 Oct 2003 04:39:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACazy-0005Yi-Vn for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 04:39:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N8dEW9021362 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 04:39:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACazy-0005YT-Qk for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 04:39:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08660 for ; Thu, 23 Oct 2003 04:39:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACazv-0003iT-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 04:39:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACazv-0003iL-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 04:39:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACazl-0005PL-Nl; Thu, 23 Oct 2003 04:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACazc-0005NI-Mg for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 04:38:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08640 for ; Thu, 23 Oct 2003 04:38:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACazZ-0003hx-00 for ipv6@ietf.org; Thu, 23 Oct 2003 04:38:49 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1ACazY-0003hu-00 for ipv6@ietf.org; Thu, 23 Oct 2003 04:38:48 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9N8ckPh028767; Thu, 23 Oct 2003 02:38:47 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9N8ckS01467; Thu, 23 Oct 2003 10:38:46 +0200 (MEST) Date: Thu, 23 Oct 2003 10:38:45 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: RFC 2461- issue list To: Soliman Hesham Cc: ipv6@ietf.org In-Reply-To: "Your message with ID" <748C6D0A58C0F94CA63C198B6674697A01922E01@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , I have a high-level question first; is the intent to do these updates and recycle the document as a draft standard? Or to try to move it to full standard? If recycle at draft is the goal, are there documents (such as MIPv6) which contain extensions to the packet formats which should be folded into the base ND spec at this point in time? In addition to the MIP issues in your list there is (at least) the definition of the R bit in the prefix option, and the advertisement interval option. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 05:02:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09281 for ; Thu, 23 Oct 2003 05:02:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbMQ-0003DK-LM for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 05:02:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N92QPQ012348 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 05:02:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbMQ-0003Cu-2j for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 05:02:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09241 for ; Thu, 23 Oct 2003 05:02:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACbMM-0003wI-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 05:02:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACbMM-0003wF-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 05:02:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbM3-000336-2m; Thu, 23 Oct 2003 05:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACSsI-0001kN-Lw for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 19:58:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07507 for ; Wed, 22 Oct 2003 19:58:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACSsG-00050r-00 for ipv6@ietf.org; Wed, 22 Oct 2003 19:58:44 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1ACSsF-00050c-00 for ipv6@ietf.org; Wed, 22 Oct 2003 19:58:43 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9MNwX5u007703 for ; Wed, 22 Oct 2003 17:58:33 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HN600111NXKPI@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Wed, 22 Oct 2003 17:58:33 -0600 (MDT) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HN6003MMNXJM7@mail.sun.net> for ipv6@ietf.org; Wed, 22 Oct 2003 17:58:32 -0600 (MDT) Date: Wed, 22 Oct 2003 17:01:13 -0700 From: Alain Durand Subject: Re: I-D ACTION:draft-soliman-ipv6-2461-bis-00.txt In-reply-to: <3F970F0D.8020007@iprg.nokia.com> To: H.Soliman@flarion.com Cc: ipv6@ietf.org Message-id: <04497E55-04EC-11D8-AF0C-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT This document does not take into account the issues listed in draft-ietf-v6ops-onlinkassumption-00.txt and draft-ietf-v6ops-v6onbydefault-00.txt I guess you published your draft before I send you a note about those 2 new drafts? - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 05:10:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09544 for ; Thu, 23 Oct 2003 05:10:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbTq-0005LI-LT for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 05:10:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N9A6M7020537 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 05:10:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbTq-0005L9-5I for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 05:10:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09516 for ; Thu, 23 Oct 2003 05:09:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACbTm-000420-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 05:10:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACbTm-00041x-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 05:10:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbTl-0005G9-F7; Thu, 23 Oct 2003 05:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbSx-00057a-GO for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 05:09:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09511 for ; Thu, 23 Oct 2003 05:09:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACbSu-00041o-00 for ipv6@ietf.org; Thu, 23 Oct 2003 05:09:08 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1ACbSt-00041R-00 for ipv6@ietf.org; Thu, 23 Oct 2003 05:09:07 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9N98axA011282; Thu, 23 Oct 2003 02:08:37 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9N98ZS04362; Thu, 23 Oct 2003 11:08:35 +0200 (MEST) Date: Thu, 23 Oct 2003 11:08:32 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: "RFC 2461bis" issue: MTU handling To: Iljitsch van Beijnum Cc: ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > Currently, routers can advertise an MTU for a link. That's nice. But > what we really need is a way for hosts to find out the MTU each > individual neighbor can handle. 100 Mbps and slower ethernet interfaces > can typically handle only the standard 1500 byte ethernet MTU, while > gigabit ethernet interfaces usually support a much larger MTU. > > However, in most cases hosts with different MTUs are present on the > same subnet, so simply advertising a larger MTU wouldn't solve this. > (Not that this would work anyway as hosts are instructed to only listen > to MTU advertisements where the MTU is between 1280 and 1500 (for > ethernet).) > > But if hosts can tell each other the MTU they support, each set of two > hosts is always able to use the largest possible MTU between them. > (This would also require a new link MTU option that conveys the maximum > MTU the lower layer equipment supports. Switches have their own MTU and > even some hubs start doing strange things when a larger than expected > MTU is used.) This might be useful when the L2 doesn't have any MTU limitations. For instance, with IP over ATM the default MTU is 9k but AAL5 has a 16 bit length field (if I don't misremember). Thus a pair of nodes can agree to use e.g. 37.5k MTU. But for links where the L2 has tigher limits things are quite a bit more difficuly. Taking Ethernet as an example. Having two hosts say that they want to use a 9k MTU over Ethernet is fine as long as the bridges/switches on the path all support that. But how can the hosts know that? Even if the hosts can determine this (send a 9k packet and see if it gets through?), what happens when an addition Ethernet switch or wire comes up (or goes away) and spanning tree changes the L2 path between those two hosts so that the packets no longer go through the same set of bridges/switches? If one would want to pursue this I think the best way would be for IEEE 802 to define a "frame size discovery" protocol at L2 so that hosts can robustly determine the frame size a given destination MAC address and be notified when it changes. But since Ethernet jumboframes are non-standard (even though more and more commonly used it seems) and there is concern about the coverage of the Ethernet CRC for larger frames, the IEEE has been unvilling to look into this. Once you have such L2 capability then a ND option for "I can receive packets with this MTU" allowing the a larger value than the default link MTU, would make sense to me. But without the L2 capability it doesn't seem very useful. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 05:14:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09715 for ; Thu, 23 Oct 2003 05:14:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbXq-0006wx-Q9 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 05:14:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N9EEV9026709 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 05:14:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbXq-0006wi-7l for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 05:14:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09685 for ; Thu, 23 Oct 2003 05:14:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACbXm-000463-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 05:14:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACbXm-000460-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 05:14:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbXe-0006nM-VD; Thu, 23 Oct 2003 05:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbUJ-0005Vf-Ua for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 05:10:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09527 for ; Thu, 23 Oct 2003 05:10:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACbUG-00042O-00 for ipv6@ietf.org; Thu, 23 Oct 2003 05:10:32 -0400 Received: from web80601.mail.yahoo.com ([66.218.79.90]) by ietf-mx with smtp (Exim 4.12) id 1ACbUF-00041v-00 for ipv6@ietf.org; Thu, 23 Oct 2003 05:10:31 -0400 Message-ID: <20031023082727.59458.qmail@web80601.mail.yahoo.com> Received: from [211.253.241.189] by web80601.mail.yahoo.com via HTTP; Thu, 23 Oct 2003 01:27:27 PDT Date: Thu, 23 Oct 2003 01:27:27 -0700 (PDT) From: Jaehoon Jeong Subject: Re: "RFC 2461bis" issue: DNS configuration To: ipv6@ietf.org Cc: paul@etri.re.kr MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi all, There is another draft for RA-based DNS Discovery. http://www.ietf.org/internet-drafts/draft-jeong-hmipv6-dns-optimization-01.txt I am one of RA-camp :-), but I agree DHCPv6 is useful in many cases. However, in wireless networks, such as HMIPv6, NEMO and MANET connected to the Internet, RA-based DNS Discovery is indeed useful. Thanks. /Jaehoon Paul Jeong ----- Original Message ----- From: "Soohong Daniel Park" > > Hello > > This issue was discussed at the dnsop wg in vienna > and is still work in progress... > > You can touch with below draft related this issue. > http://www.ietf.org/internet-drafts/draft-jeong-dnsop-ipv6-dns-discovery > -00.txt > Related drafts > http://www.ietf.org/internet-drafts/draft-jeong-nemo-ro-ndproxy-01.txt > http://www.ietf.org/internet-drafts/draft-park-manet-dns-discovery-globa > lv6-00.txt __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 05:41:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10300 for ; Thu, 23 Oct 2003 05:41:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbyN-0004ZB-5x for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 05:41:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N9fd4Z017547 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 05:41:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbyM-0004Yw-WD for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 05:41:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10269 for ; Thu, 23 Oct 2003 05:41:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACbyJ-0004M9-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 05:41:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACbyJ-0004M5-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 05:41:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbxo-0004QX-LI; Thu, 23 Oct 2003 05:41:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbxL-0004Lp-15 for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 05:40:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10246 for ; Thu, 23 Oct 2003 05:40:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACbxH-0004LU-00 for ipv6@ietf.org; Thu, 23 Oct 2003 05:40:31 -0400 Received: from kirk.rvdp.org ([80.126.101.63]) by ietf-mx with esmtp (Exim 4.12) id 1ACbxG-0004LR-00 for ipv6@ietf.org; Thu, 23 Oct 2003 05:40:30 -0400 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6p3/8.11.6) id h9N9eTc05011 for ipv6@ietf.org; Thu, 23 Oct 2003 11:40:29 +0200 (CEST) Date: Thu, 23 Oct 2003 11:40:29 +0200 From: Ronald van der Pol To: ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: DNS configuration Message-ID: <20031023094029.GC4588@rvdp.org> References: <748C6D0A58C0F94CA63C198B6674697A01922E07@ftmail.lab.flarion.com> <16BB6224-0529-11D8-A9F8-00039388672E@muada.com> <20031023073937.GB18135@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031023073937.GB18135@login.ecs.soton.ac.uk> User-Agent: Mutt/1.4.1i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Thu, Oct 23, 2003 at 08:39:37 +0100, Tim Chown wrote: > Iljitsch, I agree. This has been discussed a lot on the dnsop list... > there is currently no consensus about DHCPv6(Lite) vs RA-based discovery. This keeps popping up and we don't seem to be converging. Just before reading this thread I contacted some people about trying DHCPv6 on the MSP IETF network. I have no strong preference (yet) for either DHCPv6 or RA. Let's just give DHCPv6 a try. What do you think of this idea? > There seem to be a handful DHCPv6 implementations, but no stripped down > DHCPv6 Lite implementations yet (the Lite version not maintaining state > for IP leases etc). I tried KAME's dhcp6[sc]. It seems to work. Don't you consider this a stripped down DHCPv6 implementation? The client code is not very big, setup is easy and it even compiles and works on my MacOSX iBook. rvdp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 06:04:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11102 for ; Thu, 23 Oct 2003 06:04:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACcKQ-0001gu-4V for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 06:04:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NA4P55006462 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 06:04:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACcKP-0001g9-SG for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 06:04:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11072 for ; Thu, 23 Oct 2003 06:04:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACcKL-0004eF-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 06:04:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACcKL-0004eC-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 06:04:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACcK2-0001VN-Pi; Thu, 23 Oct 2003 06:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACcJK-0001Nw-HF for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 06:03:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11031 for ; Thu, 23 Oct 2003 06:03:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACcJG-0004dQ-00 for ipv6@ietf.org; Thu, 23 Oct 2003 06:03:14 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACcJF-0004dN-00 for ipv6@ietf.org; Thu, 23 Oct 2003 06:03:13 -0400 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA27584 for ; Thu, 23 Oct 2003 11:03:13 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA20076 for ; Thu, 23 Oct 2003 11:03:13 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h9NA3Cj21267 for ipv6@ietf.org; Thu, 23 Oct 2003 11:03:12 +0100 Date: Thu, 23 Oct 2003 11:03:12 +0100 From: Tim Chown To: ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: DNS configuration Message-ID: <20031023100312.GD20049@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <748C6D0A58C0F94CA63C198B6674697A01922E07@ftmail.lab.flarion.com> <16BB6224-0529-11D8-A9F8-00039388672E@muada.com> <20031023073937.GB18135@login.ecs.soton.ac.uk> <20031023094029.GC4588@rvdp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031023094029.GC4588@rvdp.org> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Thu, Oct 23, 2003 at 11:40:29AM +0200, Ronald van der Pol wrote: > On Thu, Oct 23, 2003 at 08:39:37 +0100, Tim Chown wrote: > > > Iljitsch, I agree. This has been discussed a lot on the dnsop list... > > there is currently no consensus about DHCPv6(Lite) vs RA-based discovery. > > This keeps popping up and we don't seem to be converging. Just before > reading this thread I contacted some people about trying DHCPv6 on the > MSP IETF network. I have no strong preference (yet) for either DHCPv6 > or RA. Let's just give DHCPv6 a try. > > What do you think of this idea? Based on the "running code" maxim, sure :) > > There seem to be a handful DHCPv6 implementations, but no stripped down > > DHCPv6 Lite implementations yet (the Lite version not maintaining state > > for IP leases etc). > > I tried KAME's dhcp6[sc]. It seems to work. Don't you consider this a > stripped down DHCPv6 implementation? > > The client code is not very big, setup is easy and it even compiles and > works on my MacOSX iBook. I'll take a look. Thanks. Note my view is that we will have DHCPv6 for DNS resolver discovery; to suggest otherwise is rather futile and counter-productive. However I think the RA method has environments where it may be suited. SO we should run with DHCPv6 tests now for this, and if we discover scenarios where the fit is not good we push to fix that, and RA method may be an answer. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 06:11:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11444 for ; Thu, 23 Oct 2003 06:11:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACcQv-0003Gh-Sq for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 06:11:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NAB9fI012560 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 06:11:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACcQv-0003GU-D8 for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 06:11:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11397 for ; Thu, 23 Oct 2003 06:10:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACcQr-0004lZ-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 06:11:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACcQr-0004lW-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 06:11:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACcQo-0003BL-DN; Thu, 23 Oct 2003 06:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACcQJ-000367-No for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 06:10:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11393 for ; Thu, 23 Oct 2003 06:10:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACcQF-0004lH-00 for ipv6@ietf.org; Thu, 23 Oct 2003 06:10:27 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACcQE-0004kL-00 for ipv6@ietf.org; Thu, 23 Oct 2003 06:10:27 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9NA9mk02303; Thu, 23 Oct 2003 13:09:48 +0300 Date: Thu, 23 Oct 2003 13:09:48 +0300 (EEST) From: Pekka Savola To: Jaehoon Jeong cc: ipv6@ietf.org, Subject: Re: "RFC 2461bis" issue: DNS configuration In-Reply-To: <20031023082727.59458.qmail@web80601.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi, Could we drop this thread here? :-) IMHO, it's no use to try chase down this particular rathole in *this* working group as well. Just state that the discovery/configuration of DNS is outside of the scope of this specification. Additions can be defined separately in DNSOP or other WGs if need be. On Thu, 23 Oct 2003, Jaehoon Jeong wrote: > There is another draft for RA-based DNS Discovery. > http://www.ietf.org/internet-drafts/draft-jeong-hmipv6-dns-optimization-01.txt > I am one of RA-camp :-), but I agree DHCPv6 is useful > in many cases. > However, in wireless networks, such as HMIPv6, NEMO > and MANET connected to the Internet, > RA-based DNS Discovery is indeed useful. > Thanks. > > /Jaehoon Paul Jeong > > ----- Original Message ----- > From: "Soohong Daniel Park" > > > > Hello > > > > This issue was discussed at the dnsop wg in vienna > > and is still work in progress... > > > > You can touch with below draft related this issue. > > > http://www.ietf.org/internet-drafts/draft-jeong-dnsop-ipv6-dns-discovery > > -00.txt > > Related drafts > > > http://www.ietf.org/internet-drafts/draft-jeong-nemo-ro-ndproxy-01.txt > > > http://www.ietf.org/internet-drafts/draft-park-manet-dns-discovery-globa > > lv6-00.txt > > > __________________________________ > Do you Yahoo!? > The New Yahoo! Shopping - with improved product search > http://shopping.yahoo.com > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 06:50:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12557 for ; Thu, 23 Oct 2003 06:50:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACd31-0001Ti-S7 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 06:50:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NAoVHr005681 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 06:50:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACd31-0001TY-HJ for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 06:50:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12520 for ; Thu, 23 Oct 2003 06:50:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACd2x-0005EM-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 06:50:27 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACd2p-0005EH-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 06:50:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACd2Z-0001Kn-RV; Thu, 23 Oct 2003 06:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACd1y-0001Dl-EH for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 06:49:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12501 for ; Thu, 23 Oct 2003 06:49:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACd1u-0005De-00 for ipv6@ietf.org; Thu, 23 Oct 2003 06:49:22 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ACd1t-0005DV-00 for ipv6@ietf.org; Thu, 23 Oct 2003 06:49:21 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 23 Oct 2003 03:49:58 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9NAmmjP025762 for ; Thu, 23 Oct 2003 03:48:49 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-294.cisco.com [10.82.225.38]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADJ95025; Thu, 23 Oct 2003 06:48:49 -0400 (EDT) Message-Id: <4.3.2.7.2.20031023063909.00b99b88@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Oct 2003 06:48:44 -0400 To: ipv6@ietf.org From: Ralph Droms Subject: Re: "RFC 2461bis" issue: DNS configuration In-Reply-To: <20031023073937.GB18135@login.ecs.soton.ac.uk> References: <16BB6224-0529-11D8-A9F8-00039388672E@muada.com> <748C6D0A58C0F94CA63C198B6674697A01922E07@ftmail.lab.flarion.com> <16BB6224-0529-11D8-A9F8-00039388672E@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , The Cisco IOS DHCPv6 server does both stateless DHCP and PD. The two functions can be configured independently, so stateless DHCP can be configured with just a couple of CLI commands. Of course, the PD code is still in the IOS footprint... The primary problem at this point is deploy a client in hosts that can use stateless DHCP. In any event, I agree with what Pekka wrote in a followup: >At 01:09 PM 10/23/2003 +0300, Pekka Savola wrote: >Hi, > >Could we drop this thread here? :-) > >IMHO, it's no use to try chase down this particular rathole in *this* >working group as well. > >Just state that the discovery/configuration of DNS is outside of the scope >of this specification. Additions can be defined separately in DNSOP or >other WGs if need be. - Ralph At 08:39 AM 10/23/2003 +0100, Tim Chown wrote: >There seem to be a handful DHCPv6 implementations, but no stripped down >DHCPv6 Lite implementations yet (the Lite version not maintaining state >for IP leases etc). > >Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 06:57:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12775 for ; Thu, 23 Oct 2003 06:57:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACd9Q-0002ve-2z for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 06:57:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NAv7ua011253 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 06:57:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACd9P-0002vQ-JQ for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 06:57:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12729 for ; Thu, 23 Oct 2003 06:56:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACd9L-0005IY-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 06:57:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACd9K-0005IV-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 06:57:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACd9K-0002nr-8r; Thu, 23 Oct 2003 06:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACd8V-0002em-Iy for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 06:56:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12717 for ; Thu, 23 Oct 2003 06:55:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACd8R-0005I8-00 for ipv6@ietf.org; Thu, 23 Oct 2003 06:56:07 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1ACd8Q-0005I5-00 for ipv6@ietf.org; Thu, 23 Oct 2003 06:56:06 -0400 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9NAu2ed013012; Thu, 23 Oct 2003 12:56:02 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <80FD8028-0547-11D8-A9F8-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: "" From: Iljitsch van Beijnum Subject: Re: "RFC 2461bis" issue: MTU handling Date: Thu, 23 Oct 2003 12:56:07 +0200 To: Pekka Savola X-Mailer: Apple Mail (2.604) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 23 okt 2003, at 12:12, Pekka Savola wrote: > Yes, and...? > Even if you don't want a separate physical infrastructure, defining a > VLAN is trivial. Yes, and setting up a new TCP session is even more trivial. But somehow people see the value of writing a 150 page specification to do mobility. Six months NOC duty, graveyard shift. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 07:12:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13237 for ; Thu, 23 Oct 2003 07:12:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACdNy-0006Ec-IS for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 07:12:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NBCARW023944 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 07:12:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACdNx-0006E7-Ql for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 07:12:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13203 for ; Thu, 23 Oct 2003 07:11:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACdNx-0005Vf-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 07:12:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACdNx-0005Vc-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 07:12:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACdNo-000699-9s; Thu, 23 Oct 2003 07:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACdNj-00067U-UJ for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 07:11:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13188 for ; Thu, 23 Oct 2003 07:11:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACdNf-0005V0-00 for ipv6@ietf.org; Thu, 23 Oct 2003 07:11:51 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1ACdNe-0005Ux-00 for ipv6@ietf.org; Thu, 23 Oct 2003 07:11:50 -0400 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9NBBked013187; Thu, 23 Oct 2003 13:11:46 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org From: Iljitsch van Beijnum Subject: Re: "RFC 2461bis" issue: MTU handling Date: Thu, 23 Oct 2003 13:11:50 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.604) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 23 okt 2003, at 11:08, Erik Nordmark wrote: [Having hosts discover and use a larger than standard MTU between them] > This might be useful when the L2 doesn't have any MTU limitations. > For instance, with IP over ATM the default MTU is 9k but AAL5 has a 16 > bit length field (if I don't misremember). Thus a pair of nodes can > agree to use e.g. 37.5k MTU. Isn't the MTU for IP over ATM something around 4500 bytes? And ATM is mostly a point-to-point protocol where hosts with a larger MTU are restricted by the need to be compatible with hosts with a regular MTU isn't relevant. > But for links where the L2 has tigher limits things are quite a bit > more difficuly. Taking Ethernet as an example. Having two hosts say > that they want to use a 9k MTU over Ethernet is fine as long as the > bridges/switches on the path all support that. Yes, this is an important limitation. > But how can the hosts know that? The simple solution would be for routers to announce the maximum packet size to be used on a subnet. > Even if the hosts can determine this (send a 9k packet and see if it > gets through?), what happens when an addition Ethernet switch or wire > comes up (or goes away) and spanning tree changes the L2 path between > those two hosts so that the packets no longer go through the same set > of bridges/switches? In theory it should be possible to create some kind of layer 2 PMTUD. But in practice I would expect operators to simply limit the MTU for the full subnet to the minimum of the MTUs supported by all switches on the subnet. > If one would want to pursue this I think the best way would be for > IEEE 802 to define a "frame size discovery" protocol at L2 so that > hosts can robustly determine the frame size a given destination > MAC address and be notified when it changes. Such a capability would enhance a layer 3 neighbor MTU management capability, but it isn't required. Operators can simply have routers annouce an upper limit on the MTU that may be used on a subnet. This doesn't impede the best case scenario where all the switches support a good sized MTU. Since the number of switches per subnet is typically much smaller than the number of hosts per subnet, getting all switches to support jumboframes is significantly simpler than getting all hosts to do the same. > But since Ethernet jumboframes are non-standard (even though more and > more commonly used it seems) and there is concern about the coverage > of the Ethernet CRC for larger frames, the IEEE has been unvilling to > look into this. Well we use a non-(IEEE-)standard way to encapsulate IP in ethernet frames (Ethernet II rather than 802.3) so we're not without precedent here. I'm not a math or physics guy, but I'm not necessarily convinced by the CRC arguments. The ethernet CRC is pretty strong, it's not going to immediately break down at 9000 bytes or so, especially not in wired networks with very low bit error rates. And if the IEEE picks this up there is no reason they can't drop in a stronger CRC. As for the TCP/UDP checksum... yes, this is a problem (even at 1500 or ~4500 bytes that many IP over xxx RFCs specify) but why would the IEEE care? > Once you have such L2 capability then a ND option for "I can receive > packets with this MTU" allowing the a larger value than the default > link MTU, would make sense to me. But without the L2 capability it > doesn't seem very useful. But what would be the usefulness of such a layer 2 feature if higher layers don't take advantage of it? I think it's the other way around: having the layer 3 feature is useful in itself, when we have this the layer 2 feature is a nice bonus. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 08:11:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15052 for ; Thu, 23 Oct 2003 08:11:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACeJS-00019C-1G for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 08:11:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NCBXfE004409 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 08:11:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACeJR-000192-EL for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 08:11:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14992 for ; Thu, 23 Oct 2003 08:11:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACeJQ-0006Eg-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 08:11:32 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACeJP-0006Ed-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 08:11:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACeIw-0000zL-GE; Thu, 23 Oct 2003 08:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACeII-0000sK-07 for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 08:10:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14965 for ; Thu, 23 Oct 2003 08:10:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACeIG-0006E6-00 for ipv6@ietf.org; Thu, 23 Oct 2003 08:10:20 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1ACeIG-0006E2-00 for ipv6@ietf.org; Thu, 23 Oct 2003 08:10:20 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h9NC9lUP015879; Thu, 23 Oct 2003 05:09:48 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9NC9lS00993; Thu, 23 Oct 2003 14:09:47 +0200 (MEST) Date: Thu, 23 Oct 2003 14:09:44 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: "RFC 2461bis" issue: MTU handling To: Iljitsch van Beijnum Cc: Erik Nordmark , ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > Such a capability would enhance a layer 3 neighbor MTU management > capability, but it isn't required. Operators can simply have routers > annouce an upper limit on the MTU that may be used on a subnet. This > doesn't impede the best case scenario where all the switches support a > good sized MTU. Since the number of switches per subnet is typically > much smaller than the number of hosts per subnet, getting all switches > to support jumboframes is significantly simpler than getting all hosts > to do the same. Ah - now I get where you are going with this. From my "host perspective" it is the switches lack of support which is the main problem - but you are right that the inverse problem also exists. So one approach would be something like having a router advertisement option that asserts "trust us; the L2 can in fact support 9k" resulting in individual hosts deciding to send out an option with their NS/NA saying "I can support receiving 9k". Note that this is different than the default MTU being 9k - since not all hosts support the larger MTU everybody would still need to use the default 1500 MTU for sending broadcast and multicast packets on the link. This still has the operational issue of what happens when I need extra ports in my office and I get a cheap 4-port hub; neither the IT department nor my hosts knows that this box is present and it might not support jumboframes. One way to cope with this particular topology, but no other topologies of varying frame size switches, would be for the host to exchange a 9k packet with the router before deciding that it should declare itself 9k capable. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 08:12:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15110 for ; Thu, 23 Oct 2003 08:12:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACeK0-0001UL-N8 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 08:12:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NCC8SB005717 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 08:12:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACeJw-0001SG-Hw for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 08:12:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15048 for ; Thu, 23 Oct 2003 08:11:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACeJv-0006Fm-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 08:12:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACeJv-0006Fj-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 08:12:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACeJu-0001MY-8R; Thu, 23 Oct 2003 08:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACeEQ-0008MY-Om for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 08:06:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14855 for ; Thu, 23 Oct 2003 08:06:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACeEP-0006BG-00 for ipv6@ietf.org; Thu, 23 Oct 2003 08:06:21 -0400 Received: from smtp3.clb.oleane.net ([213.56.31.19]) by ietf-mx with esmtp (Exim 4.12) id 1ACeEO-0006At-00 for ipv6@ietf.org; Thu, 23 Oct 2003 08:06:21 -0400 Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp3.clb.oleane.net with SMTP id h9NC5mTa020070 for ; Thu, 23 Oct 2003 14:05:48 +0200 Message-ID: <021a01c3995e$686aa160$0601a8c0@www.oleane.com> From: "Peter Lewis" To: Subject: New Mobile Technologies Forum Date: Thu, 23 Oct 2003 14:08:45 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0217_01C3996F.2BB7EF00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_0217_01C3996F.2BB7EF00 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The New Mobile Technologies Forum will be taking place in 5 weeks from = the 2nd to the 5th of December 2003 at the Hotel Sofitel Paris Bercy - = France.=20 The Forum includes the IP Based Cellular Networks'03 Conference, the = Deploying IPv6 Networks'03 Conference and the Ultra Wide Band Summit'03. = (http://www.upperside.fr/newmobtech/newmobtech03intro.htm)=20 We remind you that you can benefit from different Team passes. For more details and to register please visit: = http://www.upperside.fr/newmobtech/newmobtech03term.htm ------=_NextPart_000_0217_01C3996F.2BB7EF00 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The = New Mobile=20 Technologies Forum will be taking place in 5 weeks=20 from the 2nd to the 5th of December 2003 at the = Hotel=20 Sofitel Paris Bercy - France.=20
The Forum = includes the IP Based Cellular Networks'03 = Conference,=20 the Deploying = IPv6=20 Networks'03 Conference and the Ultra=20 Wide Band Summit'03. (http://= www.upperside.fr/newmobtech/newmobtech03intro.htm)=20
We remind you that you can = benefit=20 from different Team passes.
For more details and to = register=20 please visit: http://w= ww.upperside.fr/newmobtech/newmobtech03term.htm<= /DIV>
------=_NextPart_000_0217_01C3996F.2BB7EF00-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 10:21:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24998 for ; Thu, 23 Oct 2003 10:21:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACgKn-0001mK-Ak for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 10:21:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NEL5v3006835 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 10:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACgKn-0001m8-2q for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 10:21:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24937 for ; Thu, 23 Oct 2003 10:20:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACgKk-00013K-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 10:21:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACgKk-00013H-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 10:21:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACgJo-0001cu-Ek; Thu, 23 Oct 2003 10:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACgIr-0001VX-Py for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 10:19:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24748 for ; Thu, 23 Oct 2003 10:18:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACgIp-00010I-00 for ipv6@ietf.org; Thu, 23 Oct 2003 10:19:03 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ACgIo-0000yp-00 for ipv6@ietf.org; Thu, 23 Oct 2003 10:19:03 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RDCKX>; Thu, 23 Oct 2003 10:18:16 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E0A@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Erik Nordmark'" Cc: ipv6@ietf.org Subject: RE: RFC 2461- issue list Date: Thu, 23 Oct 2003 10:18:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , A few important points there. I'm not sure I have the answers for all, but here is my understanding: > I have a high-level question first; is the intent to do these updates > and recycle the document as a draft standard? > Or to try to move it to full standard? => My understanding was that the new RFC would still be in DS, but I could be wrong. It'd be good if the chairs shed some light on this. > > If recycle at draft is the goal, are there documents (such as MIPv6) > which contain extensions to the packet formats which should be folded > into the base ND spec at this point in time? > > In addition to the MIP issues in your list there is (at least) the > definition of the R bit in the prefix option, and the advertisement > interval option. => Right. So I'm not sure if the goal is to include all the ND extensions in other specs, again it would be good to get some feedback on this point. I assumed that extensions would be done anyway in other specs as deemed necessary. So, if this assumption is agreeable then the work should be limited to clarifying points in the spec or solving problems that were discovered by people while working with this version of ND. Do you think we should include these extensions? There is also the process issue on what can be added to a DS, given the requirements on moving from PS to DS (having every option interop tested and some level of deployment), which might stand in the way of adding new extensions from a PS/draft. Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 11:34:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29681 for ; Thu, 23 Oct 2003 11:34:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChTm-0008J2-UL for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 11:34:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NFYQ8O031927 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 11:34:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChTm-0008Is-Qn for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 11:34:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29652 for ; Thu, 23 Oct 2003 11:34:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AChTl-0002X6-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 11:34:26 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AChTl-0002X3-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 11:34:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChTP-0008Cn-C7; Thu, 23 Oct 2003 11:34:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChSY-0007ya-1o for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 11:33:10 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29517; Thu, 23 Oct 2003 11:32:59 -0400 (EDT) Message-Id: <200310231532.LAA29517@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-bykim-ipv6-hpd-00.txt Date: Thu, 23 Oct 2003 11:32:58 -0400 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Hierarchical Prefix Delegation Protocol Author(s) : B. Kim, K. Lee, J. Park, H. Kim Filename : draft-bykim-ipv6-hpd-00.txt Pages : 12 Date : 2003-10-23 Stateless Autoconfiguration enables IPv6 hosts to send a request for a prefix, a network identifier to a router on the subnet. Using this ability a host can configure its IPv6 address. Likewise, by defining a way to request for a prefix to an upper level router, a router can get a prefix to be assigned to its subnet. This document describes a protocol for prefix delegation between routers. It allows routers get prefixes from its upstream routers, enabling the entire network and its belonging hosts autoconfigure their own addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bykim-ipv6-hpd-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-bykim-ipv6-hpd-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-bykim-ipv6-hpd-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: <2003-10-23111416.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bykim-ipv6-hpd-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-bykim-ipv6-hpd-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-23111416.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 12:04:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02719 for ; Thu, 23 Oct 2003 12:04:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChwN-0005gU-JU for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 12:04:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NG3xGx021844 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 12:03:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChwN-0005gF-EW for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 12:03:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02670 for ; Thu, 23 Oct 2003 12:03:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AChwK-0003SL-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 12:03:56 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AChwK-0003SI-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 12:03:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChvS-0005Vi-Gk; Thu, 23 Oct 2003 12:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChv5-0005Sq-SQ for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 12:02:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02589 for ; Thu, 23 Oct 2003 12:02:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AChv4-0003Pq-00 for ipv6@ietf.org; Thu, 23 Oct 2003 12:02:38 -0400 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx with esmtp (Exim 4.12) id 1AChv1-0003Ml-00 for ipv6@ietf.org; Thu, 23 Oct 2003 12:02:38 -0400 Received: from consulintel02 ([202.133.104.44]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 39-md50000000006.tmp for ; Thu, 23 Oct 2003 18:04:13 +0200 Message-ID: <02e501c3997f$12d2ff60$9402a8c0@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <200310231532.LAA29517@ietf.org> Subject: Re: I-D ACTION:draft-bykim-ipv6-hpd-00.txt Date: Fri, 24 Oct 2003 00:02:30 +0800 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Thu, 23 Oct 2003 18:04:13 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 202.133.104.44 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I think this is a very interesting document. In fact, we have been working in something similar for some time, but still not drafted it. Our case is a very good example, because we are working in a project (www.6power.org) that deploys IPv6 PLC networks. In our case, we may have different network configurations, with routers, bridges (PLC repeaters) and CPEs. The idea is to configure the OSS system, in some cases in a static way (with the subscriber parameters), some others automatically (but keeping the security to avoid non registered users to use the service). At this way, when the different devices are plugged into the power network, there is no need to do ANY configuration at the devices, as they will learn (or "create") an adequate network structure, all the way, until the CPE (that can be also a router, of course). The idea is to extend the auto-configuration capabilities for IPv6 to the complete network. Today we do an autoconfiguration at the PLC level already. This could provide one very good reason to deploy IPv6, specially in new networks, as will save a lot of resources in the setup and operation/maintenance. I think is a very good example of the utility of this document, and for sure we will be interested in cooperate on it, and most probably work on concrete implementations. Regards, Jordi ----- Original Message ----- From: To: Cc: Sent: Thursday, October 23, 2003 11:32 PM Subject: I-D ACTION:draft-bykim-ipv6-hpd-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Hierarchical Prefix Delegation Protocol > Author(s) : B. Kim, K. Lee, J. Park, H. Kim > Filename : draft-bykim-ipv6-hpd-00.txt > Pages : 12 > Date : 2003-10-23 > > Stateless Autoconfiguration enables IPv6 hosts to send a request for a prefix, a network identifier to a router on the subnet. Using this ability a host can configure its IPv6 address. Likewise, by defining a way to request for a prefix to an upper level router, a router can get a prefix to be assigned to its subnet. > > This document describes a protocol for prefix delegation between routers. It allows routers get prefixes from its upstream routers, enabling the entire network and its belonging hosts autoconfigure their own addresses. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bykim-ipv6-hpd-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-bykim-ipv6-hpd-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-bykim-ipv6-hpd-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. > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 12:48:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06664 for ; Thu, 23 Oct 2003 12:48:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACidP-0006DH-1a for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 12:48:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NGmR4x023882 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 12:48:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACidO-0006D7-TL for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 12:48:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06608 for ; Thu, 23 Oct 2003 12:48:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACidN-0004fV-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 12:48:25 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACidM-0004fS-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 12:48:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACicz-00061p-O7; Thu, 23 Oct 2003 12:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACicU-0005wQ-Mt for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 12:47:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06456 for ; Thu, 23 Oct 2003 12:47:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACicT-0004eZ-00 for ipv6@ietf.org; Thu, 23 Oct 2003 12:47:29 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1ACicS-0004eU-00 for ipv6@ietf.org; Thu, 23 Oct 2003 12:47:28 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:208:dff:fe40:3f37]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A8B9F1521E; Fri, 24 Oct 2003 01:47:23 +0900 (JST) Date: Fri, 24 Oct 2003 01:47:22 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Tim Chown Cc: ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: DNS configuration In-Reply-To: <20031023100312.GD20049@login.ecs.soton.ac.uk> References: <748C6D0A58C0F94CA63C198B6674697A01922E07@ftmail.lab.flarion.com> <16BB6224-0529-11D8-A9F8-00039388672E@muada.com> <20031023073937.GB18135@login.ecs.soton.ac.uk> <20031023094029.GC4588@rvdp.org> <20031023100312.GD20049@login.ecs.soton.ac.uk> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >>>>> On Thu, 23 Oct 2003 11:03:12 +0100, >>>>> Tim Chown said: >> > There seem to be a handful DHCPv6 implementations, but no stripped down >> > DHCPv6 Lite implementations yet (the Lite version not maintaining state >> > for IP leases etc). >> >> I tried KAME's dhcp6[sc]. It seems to work. Don't you consider this a >> stripped down DHCPv6 implementation? > I'll take a look. Thanks. You may also want to check the following URL http://www.kame.net/newsletter/20030411/ that describes how to use the DHCPv6 implementation as DNS resolver discovery. I agree with Pekka that we should drop this particular thread on this list, so I'm just going to give a pointer that might be useful. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 12:58:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06935 for ; Thu, 23 Oct 2003 12:58:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACimr-0007tr-9l for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 12:58:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NGwDAc030368 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 12:58:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACimr-0007tj-04 for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 12:58:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06908 for ; Thu, 23 Oct 2003 12:58:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACimp-0004lO-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 12:58:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACimo-0004lL-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 12:58:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACimf-0007m1-RL; Thu, 23 Oct 2003 12:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACiln-0007gT-De for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 12:57:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06899 for ; Thu, 23 Oct 2003 12:56:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACill-0004lD-00 for ipv6@ietf.org; Thu, 23 Oct 2003 12:57:05 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ACill-0004l3-00 for ipv6@ietf.org; Thu, 23 Oct 2003 12:57:05 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9NGuRo04183; Thu, 23 Oct 2003 09:56:27 -0700 X-mProtect: <200310231656> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd79GQ5i; Thu, 23 Oct 2003 09:56:25 PDT Message-ID: <3F980957.8060805@iprg.nokia.com> Date: Thu, 23 Oct 2003 10:01:11 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: MTU handling References: Content-Type: multipart/mixed; boundary="------------020300010308010003000300" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------020300010308010003000300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Iljitsch, An example use case is that on certain multiple-access wireless links the optimal MTU for a particular neighbor may be proportional to certain QoS metrics, e.g., the signal to noise ratio sensed at the receiver's MAC layer. I submitted a draft proposal back in January 2003 (attached below) that suggests one possible approach by allowing NA messages to include an MTU option (should I submit an update?). Another approach would be to allow different semantics for the interpretation of MTU options in RA messages based on the link type. Comments? Fred ftemplin@iprg.nokia.com Iljitsch van Beijnum wrote: > I'm not sure this should go into a replacement specification for RFC > 2461, but I'll bring it up anyway: > > Currently, routers can advertise an MTU for a link. That's nice. But > what we really need is a way for hosts to find out the MTU each > individual neighbor can handle. 100 Mbps and slower ethernet > interfaces can typically handle only the standard 1500 byte ethernet > MTU, while gigabit ethernet interfaces usually support a much larger MTU. > > However, in most cases hosts with different MTUs are present on the > same subnet, so simply advertising a larger MTU wouldn't solve this. > (Not that this would work anyway as hosts are instructed to only > listen to MTU advertisements where the MTU is between 1280 and 1500 > (for ethernet).) > > But if hosts can tell each other the MTU they support, each set of two > hosts is always able to use the largest possible MTU between them. > (This would also require a new link MTU option that conveys the > maximum MTU the lower layer equipment supports. Switches have their > own MTU and even some hubs start doing strange things when a larger > than expected MTU is used.) > > BTW, some duplication seems to have crept into the document: > > variable MTU - a link that does not have a well-defined MTU (e.g., > IEEE 802.5 token rings). Many links (e.g., > Ethernet) have a standard MTU defined by the link- > layer protocol or by the specific document > describing how to run IP over the link layer. > > variable MTU - Neighbor Discovery allows routers to specify a MTU > for the link, which all nodes then use. All nodes > on a link must use the same MTU (or Maximum > Receive Unit) in order for multicast to work > properly. Otherwise when multicasting a sender, > which can not know which nodes will receive the > packet, could not determine a minimum packet size > all receivers can process. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --------------020300010308010003000300 Content-Type: text/plain; name="ndiscmtu-00.txt" Content-Disposition: inline; filename="ndiscmtu-00.txt" Content-Transfer-Encoding: 7bit Network Working Group F. Templin Internet-Draft Nokia Expires: August 1, 2003 January 31, 2003 MTU Issues in IPv6 Neighbor Discovery draft-ietf-templin-ndiscmtu-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 1, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document discusses Maximum Transmission Unit (MTU) issues in IPv6 Neighbor Discovery and suggests minor augmentations to the existing specification to rectify the issues. 1. Introduction This document discusses Maximum Transmission Unit (MTU) issues in Neighbor Discovery for IP Version 6 (IPv6) [1]. It argues that the current specification is too restrictive in the use of MTU options, and that per-neighbor MTU values should be maintained in the conceptual Neighbor Cache. It finally proposes minor augmentations to the existing specification to rectify the issues. Templin Expires August 1, 2003 [Page 1] Internet-Draft MTU Issues in IPv6 Neighbor Discovery January 2003 2. Problem Statement ([1], section 4.6.4) defines a Maximum Transmission Unit (MTU) option type. In the current specification, the MTU option is sent only in Router Advertisement messages ([1], section 4.2) and interpreted by receivers as the MTU value for all nodes on the link to use. While this specification provides sufficient mechanism for many of the supported link types in ([1], section 2.2), it may lead to inefficiencies for other types, e.g., for certain variable MTU links. In particular, it may be desirable in some cases for a node to track independent MTU values for different neighbors on a link. For example, on certain multiple-access wireless links the optimal MTU for a particular neighbor may be proportional to the signal to noise ratio sensed at the receiver's MAC layer. In another example, constrained nodes on a link with large MTU may wish to receive smaller packets than more robust nodes. In these and other cases, maintaining independent per-neighbor MTUs for nodes on a link would yield significant efficiency advantages. 3. Proposed Changes In order to support per-neighbor MTUs, the following changes/ augmentations to RFC 2461 are proposed: 1. In ([1], section 4.6.4), add new text allowing the encoding of MTU options in Neighbor Acknowledgement messages. 2. In ([1], section 5.1), add a per-neighbor MTU field (NBR_MTU) in the Neighbor Cache data structure. 3. In ([1], section 6.3.2), add a new host variable, defined as follows: MaxLinkMTU The maximum MTU supported on the link. Default: LinkMTU. 4. In ([1], section 7.2.4), add new text allowing the encoding of MTU options in solicited Neighbor Advertisements." 5. In ([1], section 7.2.5), add new text requiring the value in MTU options received in Neighbor Advertisement messages be written into the NBR_MTU field in the Neighbor Cache entry. 6. In (([1], section 7.2.6), add new text allowing Unsolicited Neighbor Advertisements sent to the unicast address of a neighbor. Templin Expires August 1, 2003 [Page 2] Internet-Draft MTU Issues in IPv6 Neighbor Discovery January 2003 4. Operational Details When nodes implement the changes proposed above, Neighbor Advertisement messages containing MTU options provide a dynamic mechanism for receivers to inform senders of MTU changes. Documents that specify the operation of IPv6 over specific link layers (e.g., Ethernet, FDDI, etc.) provide details for the encoding of MTU options in Neighbor Advertisement messages. Receipt of an MTU option in the initial solicited Neighbor Advertisement provides an indication to the sender that the receiver implements the dynamic MTU mechanism. (Lack thereof conversely provides an indication that the receiver does not implement the dynamic MTU mechanism.) Using these proposed changes, MTU options received in Router Advertisements affect LinkMTU exactly as in the current specification. However, packetization and forwarding layers see an MTU of MaxLinkMTU when they examine the link. The relationship between the three MTU parameters is as follows: LinkMTU <= NbrMTU <= MaxLinkMTU Multicast destinations, and unicast destinations that use a next hop with no MTU support indicated in the Neighbor Cache, see an MTU of LinkMTU. 5. IANA Considerations TBD 6. Security considerations TBD 7. Acknowledgements TBD Normative References [1] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. Informative References Templin Expires August 1, 2003 [Page 3] Internet-Draft MTU Issues in IPv6 Neighbor Discovery January 2003 Author's Address Fred L. Templin Nokia 313 Fairchild Drive Mountain View, CA 94110 US Phone: +1 650 625 2331 EMail: ftemplin@iprg.nokia.com Templin Expires August 1, 2003 [Page 4] Internet-Draft MTU Issues in IPv6 Neighbor Discovery January 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Templin Expires August 1, 2003 [Page 5] Internet-Draft MTU Issues in IPv6 Neighbor Discovery January 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Templin Expires August 1, 2003 [Page 6] --------------020300010308010003000300-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 13:15:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07580 for ; Thu, 23 Oct 2003 13:15:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACj3K-0003FR-Rl for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 13:15:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NHFECa012479 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 13:15:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACj3K-0003FC-He for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 13:15:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07556 for ; Thu, 23 Oct 2003 13:15:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACj3I-0004zG-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 13:15:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACj3I-0004zD-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 13:15:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACj38-00039A-Rx; Thu, 23 Oct 2003 13:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACj2N-000315-I8 for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 13:14:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07548 for ; Thu, 23 Oct 2003 13:14:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACj2K-0004yS-00 for ipv6@ietf.org; Thu, 23 Oct 2003 13:14:12 -0400 Received: from smtp01.uc3m.es ([163.117.136.121] helo=smtp.uc3m.es) by ietf-mx with esmtp (Exim 4.12) id 1ACj2J-0004yH-00 for ipv6@ietf.org; Thu, 23 Oct 2003 13:14:11 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 3B37043737 for ; Thu, 23 Oct 2003 19:06:57 +0200 (CEST) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp01.uc3m.es (Postfix) with ESMTP id 2AB3499EFC for ; Thu, 23 Oct 2003 19:06:57 +0200 (CEST) From: Juan Rodriguez Hervella Organization: UC3M To: ipv6@ietf.org Subject: Re: A host who has private IPv4 address can communicate with IPv6 host globaly by 6to4 tunnel Date: Thu, 23 Oct 2003 19:07:11 +0200 User-Agent: KMail/1.5.4 References: <000001c39883$c7471cd0$3c01a8c0@willnote> <027c01c398b5$2a030790$c102a8c0@consulintel.es> <20031022155948.GN9984@login.ecs.soton.ac.uk> In-Reply-To: <20031022155948.GN9984@login.ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310231907.12921.jrh@it.uc3m.es> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Just to finish this thread, one more comment :) I think it should be much better if you upgrade your NAT to support the 6to4 mechanism, or even better, get rid of the NAT and ask for IPv6 native connectivity, try it, IPv6 will give you more addresses, sure :) Cheers. On Wednesday 22 October 2003 17:59, Tim Chown wrote: > The same also goes for tunnel brokers and other mechanisms using the > proto41 forwarding. But this is a v6ops thing not ipv6 wg. > > tim > > On Wed, Oct 22, 2003 at 11:57:10PM +0800, JORDI PALET MARTINEZ wrote: > > In fact, it will be very good if you can tell me (private email to avoid > > brands/models here) what router or NAT box are you using, so I can > > include it in my survey. > > > > Same for other people that has used this ;-) > > > > Regards, > > Jordi > > > > PS: By the way, yes, you can use any of the computers after the NAT as > > the IPv6 router. I'm doing it right now, in my hotel room, and I see some > > other people using my IPv6 prefix, for free, being my laptop the router ! > > You can read the last draft (-02 waiting in the editors queue) and also > > this document > > http://www.euro6ix.org/documentation/euro6ix_co_upm-consulintel_wp4_ipv6_ > >tunnels_nat_v1_6.pdf. > > > > ----- Original Message ----- > > From: "Tim Chown" > > To: > > Sent: Wednesday, October 22, 2003 6:28 PM > > Subject: Re: A host who has private IPv4 address can communicate with > > IPv6 host globaly by 6to4 tunnel > > > > > Hi, > > > > > > Yes, this will work. This technique is quite widely used, and is one > > > reason for this draft: > > > http://www.ietf.org/internet-drafts/draft-palet-v6ops-proto41-nat-01.tx > > >t > > > > > > Essentially you forward the protocol 41 from the NAT to the internal > > > host. > > > > > > It is quite a popular "trick" with our students in their home DSL LANs. > > > > > > The problem is that this only works for one host within the NAT > > > network, so if the NAT encompasses many sites, you're stuck. > > > > > > Cheers, > > > Tim > > > > > > On Wed, Oct 22, 2003 at 07:03:44PM +0900, Jisuek.Lim wrote: > > > > Hello all, > > > > > > > > I have a idea about communication method with 6to4 tunnel. > > > > > > > > Generally, we think a host who has private IPv4 address(because > > > > it is behind NAT device) can not communicate with IPv6 host > > > > globally by tunneling(6to4, config tunnel ..) But there is a > > > > way using 6to4 tunnel. > > > > > > > > When we config 6to4 config on a host(for example windows2000 > > > > station) we assign the host's IPv4 address to the host's 6to4 > > > > address(next to 2002:). And we know the host's IPv4 address > > > > shoud be public IPv4 address. > > > > > > > > But, if we use the public IPv4 address which is on NAT > > > > device's external interface to make the host's 6to4 address, > > > > the host can communicate with IPv6 host globally using 6to4 > > > > tunnel and relay router. Following are do list. > > > > > > > > 1. Map the NAT device's public address(select one) to the > > > > host's private address(configure on the NAT) > > > > > > > > 2. On the NAT device, make a policy which permit > > > > incomming traffic which has protocol number 41 to the host's private > > > > address > > > > > > > > 3. Change the NAT device's public IPv4 address(which > > > > you selected) to hex. format. > > > > > > > > 4. Configure the host's 6to4 address using upper hex. > > > > > > > > 5. Add route table for 2002 traffic to tunnel interface, > > > > and > > > > > > > > ::/0 to relay router(relay router is provided by some orgnization) > > > > > > > > And then,...try ping6 to any IPv6 address. following is the > > > > result of my own test. > > > > > > > > > > > > C:\>ping6 6to4.ipv6.fh-regensburg.de > > > > > > > > Pinging 6to4.ipv6.fh-regensburg.de [2002:c25f:6cbf:1::1] with 32 > > > > bytes of data: > > > > > > > > > > > > Reply from 2002:c25f:6cbf:1::1: bytes=32 time=330ms > > > > > > > > Reply from 2002:c25f:6cbf:1::1: bytes=32 time=329ms > > > > > > > > Reply from 2002:c25f:6cbf:1::1: bytes=32 time=329ms > > > > > > > > > > > > C:\> > > > > > > > > C:\>ping6 www.kame.net > > > > > > > > > > > > Pinging orange.kame.net [2001:200:0:8002:203:47ff:fea5:3085] > > > > with 32 bytes of data: > > > > > > > > > > > > Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=117ms > > > > > > > > Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=72ms > > > > > > > > Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=68ms > > > > > > > > Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=71ms > > > > > > > > > > > > C:\> > > > > > > > > > > > > Following is my computer's IP config > > > > > > > > > > > > C:\>ipconfig > > > > > > > > > > > > Windows 2000 IP Configuration > > > > > > > > > > > > Ethernet adapter : > > > > > > > > > > > > Connection-specific DNS Suffix . : > > > > > > > > IP Address. . . . . . . . . . . . : 192.168.1.60 > > > > > > > > Subnet Mask . . . . . . . . . . . : 255.255.255.0 > > > > > > > > Default Gateway . . . . . . . . . : 192.168.1.254 > > > > > > > > > > > > C:\> > > > > > > > > > > > > as you know 192.168.1.60 is private address !! > > > > > > > > Try it. > > > > > > > > Thanks. > > > > > > > > Jisuek. Lim > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > ********************************** > > Madrid 2003 Global IPv6 Summit > > Presentations and videos on line at: > > http://www.ipv6-es.com > > > > This electronic message contains information which may be privileged or > > confidential. The information is intended to be for the use of the > > individual(s) named above. If you are not the intended recipient be aware > > that any disclosure, copying, distribution or use of the contents of this > > information, including attached files, is prohibited. > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- JFRH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 13:26:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07985 for ; Thu, 23 Oct 2003 13:26:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjDy-0005OH-H4 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 13:26:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NHQEjS020715 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 13:26:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjDy-0005O2-D8 for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 13:26:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07966 for ; Thu, 23 Oct 2003 13:26:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACjDw-000574-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 13:26:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACjDw-000571-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 13:26:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjDn-0005JT-6X; Thu, 23 Oct 2003 13:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjDg-0005Hx-92 for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 13:25:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07956 for ; Thu, 23 Oct 2003 13:25:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACjDe-00056m-00 for ipv6@ietf.org; Thu, 23 Oct 2003 13:25:54 -0400 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx with esmtp (Exim 4.12) id 1ACjDd-00056U-00 for ipv6@ietf.org; Thu, 23 Oct 2003 13:25:53 -0400 Received: from consulintel02 ([202.133.104.44]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 22-md50000000009.tmp for ; Thu, 23 Oct 2003 19:29:06 +0200 Message-ID: <054301c3998a$edcabfd0$9402a8c0@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <000001c39883$c7471cd0$3c01a8c0@willnote> <027c01c398b5$2a030790$c102a8c0@consulintel.es> <20031022155948.GN9984@login.ecs.soton.ac.uk> <200310231907.12921.jrh@it.uc3m.es> Subject: Re: A host who has private IPv4 address can communicate with IPv6 host globaly by 6to4 tunnel Date: Fri, 24 Oct 2003 01:27:22 +0800 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Thu, 23 Oct 2003 19:29:06 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 202.133.104.44 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yes, but we know very well that most of the (cheap) router/NAT manufacturers will not implement 6to4 or any other IPv6 code until there is market to make business, so meanwhile we need to take advantages of any possible solutions. Regards, Jordi ----- Original Message ----- From: "Juan Rodriguez Hervella" To: Sent: Friday, October 24, 2003 1:07 AM Subject: Re: A host who has private IPv4 address can communicate with IPv6 host globaly by 6to4 tunnel > Just to finish this thread, one more comment :) > > I think it should be much better > if you upgrade your NAT to support the 6to4 mechanism, > or even better, get rid of the NAT and ask for IPv6 native > connectivity, try it, IPv6 will give you more addresses, sure :) > > Cheers. > > On Wednesday 22 October 2003 17:59, Tim Chown wrote: > > The same also goes for tunnel brokers and other mechanisms using the > > proto41 forwarding. But this is a v6ops thing not ipv6 wg. > > > > tim > > > > On Wed, Oct 22, 2003 at 11:57:10PM +0800, JORDI PALET MARTINEZ wrote: > > > In fact, it will be very good if you can tell me (private email to avoid > > > brands/models here) what router or NAT box are you using, so I can > > > include it in my survey. > > > > > > Same for other people that has used this ;-) > > > > > > Regards, > > > Jordi > > > > > > PS: By the way, yes, you can use any of the computers after the NAT as > > > the IPv6 router. I'm doing it right now, in my hotel room, and I see some > > > other people using my IPv6 prefix, for free, being my laptop the router ! > > > You can read the last draft (-02 waiting in the editors queue) and also > > > this document > > > http://www.euro6ix.org/documentation/euro6ix_co_upm-consulintel_wp4_ipv6_ > > >tunnels_nat_v1_6.pdf. > > > > > > ----- Original Message ----- > > > From: "Tim Chown" > > > To: > > > Sent: Wednesday, October 22, 2003 6:28 PM > > > Subject: Re: A host who has private IPv4 address can communicate with > > > IPv6 host globaly by 6to4 tunnel > > > > > > > Hi, > > > > > > > > Yes, this will work. This technique is quite widely used, and is one > > > > reason for this draft: > > > > http://www.ietf.org/internet-drafts/draft-palet-v6ops-proto41-nat-01.tx > > > >t > > > > > > > > Essentially you forward the protocol 41 from the NAT to the internal > > > > host. > > > > > > > > It is quite a popular "trick" with our students in their home DSL LANs. > > > > > > > > The problem is that this only works for one host within the NAT > > > > network, so if the NAT encompasses many sites, you're stuck. > > > > > > > > Cheers, > > > > Tim > > > > > > > > On Wed, Oct 22, 2003 at 07:03:44PM +0900, Jisuek.Lim wrote: > > > > > Hello all, > > > > > > > > > > I have a idea about communication method with 6to4 tunnel. > > > > > > > > > > Generally, we think a host who has private IPv4 address(because > > > > > it is behind NAT device) can not communicate with IPv6 host > > > > > globally by tunneling(6to4, config tunnel ..) But there is a > > > > > way using 6to4 tunnel. > > > > > > > > > > When we config 6to4 config on a host(for example windows2000 > > > > > station) we assign the host's IPv4 address to the host's 6to4 > > > > > address(next to 2002:). And we know the host's IPv4 address > > > > > shoud be public IPv4 address. > > > > > > > > > > But, if we use the public IPv4 address which is on NAT > > > > > device's external interface to make the host's 6to4 address, > > > > > the host can communicate with IPv6 host globally using 6to4 > > > > > tunnel and relay router. Following are do list. > > > > > > > > > > 1. Map the NAT device's public address(select one) to the > > > > > host's private address(configure on the NAT) > > > > > > > > > > 2. On the NAT device, make a policy which permit > > > > > incomming traffic which has protocol number 41 to the host's private > > > > > address > > > > > > > > > > 3. Change the NAT device's public IPv4 address(which > > > > > you selected) to hex. format. > > > > > > > > > > 4. Configure the host's 6to4 address using upper hex. > > > > > > > > > > 5. Add route table for 2002 traffic to tunnel interface, > > > > > and > > > > > > > > > > ::/0 to relay router(relay router is provided by some orgnization) > > > > > > > > > > And then,...try ping6 to any IPv6 address. following is the > > > > > result of my own test. > > > > > > > > > > > > > > > C:\>ping6 6to4.ipv6.fh-regensburg.de > > > > > > > > > > Pinging 6to4.ipv6.fh-regensburg.de [2002:c25f:6cbf:1::1] with 32 > > > > > bytes of data: > > > > > > > > > > > > > > > Reply from 2002:c25f:6cbf:1::1: bytes=32 time=330ms > > > > > > > > > > Reply from 2002:c25f:6cbf:1::1: bytes=32 time=329ms > > > > > > > > > > Reply from 2002:c25f:6cbf:1::1: bytes=32 time=329ms > > > > > > > > > > > > > > > C:\> > > > > > > > > > > C:\>ping6 www.kame.net > > > > > > > > > > > > > > > Pinging orange.kame.net [2001:200:0:8002:203:47ff:fea5:3085] > > > > > with 32 bytes of data: > > > > > > > > > > > > > > > Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=117ms > > > > > > > > > > Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=72ms > > > > > > > > > > Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=68ms > > > > > > > > > > Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=71ms > > > > > > > > > > > > > > > C:\> > > > > > > > > > > > > > > > Following is my computer's IP config > > > > > > > > > > > > > > > C:\>ipconfig > > > > > > > > > > > > > > > Windows 2000 IP Configuration > > > > > > > > > > > > > > > Ethernet adapter : > > > > > > > > > > > > > > > Connection-specific DNS Suffix . : > > > > > > > > > > IP Address. . . . . . . . . . . . : 192.168.1.60 > > > > > > > > > > Subnet Mask . . . . . . . . . . . : 255.255.255.0 > > > > > > > > > > Default Gateway . . . . . . . . . : 192.168.1.254 > > > > > > > > > > > > > > > C:\> > > > > > > > > > > > > > > > as you know 192.168.1.60 is private address !! > > > > > > > > > > Try it. > > > > > > > > > > Thanks. > > > > > > > > > > Jisuek. Lim > > > > > > > > -------------------------------------------------------------------- > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > > > -------------------------------------------------------------------- > > > > > > ********************************** > > > Madrid 2003 Global IPv6 Summit > > > Presentations and videos on line at: > > > http://www.ipv6-es.com > > > > > > This electronic message contains information which may be privileged or > > > confidential. The information is intended to be for the use of the > > > individual(s) named above. If you are not the intended recipient be aware > > > that any disclosure, copying, distribution or use of the contents of this > > > information, including attached files, is prohibited. > > > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -- > JFRH > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 14:44:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11857 for ; Thu, 23 Oct 2003 14:44:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACkRI-0003ep-DT for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 14:44:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NIi4UW013940 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 14:44:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACkRH-0003cl-VC for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 14:44:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11810 for ; Thu, 23 Oct 2003 14:43:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACkRF-0006LB-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 14:44:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACkRE-0006L8-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 14:44:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACkQH-0003MY-F3; Thu, 23 Oct 2003 14:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACkPm-0003HN-SC for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 14:42:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11686 for ; Thu, 23 Oct 2003 14:42:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACkPk-0006JC-00 for ipv6@ietf.org; Thu, 23 Oct 2003 14:42:28 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1ACkPj-0006J6-00 for ipv6@ietf.org; Thu, 23 Oct 2003 14:42:27 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h9NIffO8007538; Thu, 23 Oct 2003 13:41:42 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 23 Oct 2003 13:40:49 -0500 Received: from [142.133.72.18] (142.133.72.18 [142.133.72.18]) by eammlex033.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id VNTRW21N; Thu, 23 Oct 2003 14:44:36 -0400 Date: Thu, 23 Oct 2003 14:40:00 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: suresh.krishnan@ericsson.ca To: ipv6@ietf.org cc: Soliman Hesham Subject: RFC 2461-new issue? In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF830BD62867@eammlex037.lmc.ericsson.se> Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830CCE42C6-100000@eammlex037.lmc.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi, In section 4.2 of RFC 2461 regarding the RA message format the following is mentioned Reserved A 6-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. The mobile-ipv6 draft draft-ietf-mobileip-ipv6-24.txt mandates using the most significant bit of this field as a home agent bit(will be set to 1 if the router is also a MIPv6 HA on this link). I do not know what is the best way to solve this apparent contradiction. I see the following possible solutions (in no particular order) * Reduce the reserved field length in RFC2461bis to 5 bits * Change the MUSTs to SHOULDs in RFC2461bis * Put a note on RFC2461/RFC2461bis in the rfc-index saying it has been updated by the MIPv6 RFC(when it comes out) Regards Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 17:02:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18791 for ; Thu, 23 Oct 2003 17:02:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACmas-0000WT-FL for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 17:02:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NL26Un002006 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 17:02:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACmas-0000WH-9I for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 17:02:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18766 for ; Thu, 23 Oct 2003 17:01:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACmaq-0000XO-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 17:02:04 -0400 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1ACmao-0000XL-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 17:02:03 -0400 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1ACmao-0006xM-4o for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 17:02:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACmZt-0000FX-Ly; Thu, 23 Oct 2003 17:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACmZI-00007T-OV for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 17:00:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18636 for ; Thu, 23 Oct 2003 17:00:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACmZG-0000U6-00 for ipv6@ietf.org; Thu, 23 Oct 2003 17:00:26 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ACmZF-0000QS-00 for ipv6@ietf.org; Thu, 23 Oct 2003 17:00:25 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9NKxrk23182; Thu, 23 Oct 2003 13:59:53 -0700 X-mProtect: <200310232059> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdyXCIin; Thu, 23 Oct 2003 13:59:52 PDT Message-ID: <3F9841CC.5040303@iprg.nokia.com> Date: Thu, 23 Oct 2003 14:02:04 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: ipv6@ietf.org Subject: Re: RFC 2461- issue list References: <748C6D0A58C0F94CA63C198B6674697A01922E01@ftmail.lab.flarion.com> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922E01@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi Hesham, here is another issue. when a router includes a Prefix Information Option (section 4.6.2 of RFC 2461) in the Router Advertisement, and if the router has an address configured from that prefix, I suggest including the router's address in the 'Prefix' field. not just the prefix. the Prefix Length field will still indicate the prefix length and hosts should be able to figure out the prefix. we have had problems when two different interfaces of a router use the same link local address. some host implementations just check the source address and assume that the current router is still reachable even when they move between links attached to the two interfaces on the router. we came across this issue at Connectathon 2002. the following URL has some discussion on it http://www.piuha.net/~jarkko/publications/mipv6/issues/issue278.txt Mobile IPv6 already defines a Modified Prefix Information option where the router's address is present in the prefix field. I would like to see it in the Neighbor Discovery specification itself. having the global unicast address in the prefix field will help in movement detection. Vijay Soliman Hesham wrote: > Folks, > > This is what I found initially. Please let us know if > there are any issues that should be added to the list. > > Please note that some of these issues might not necessarily > be addressed in this revision if they require non-backward > compatible changes. The main requirement here is to be > backward compatible with our changes. > > If you wish to express opinions, questions or suggestions > please start a separate thread with the issue's header > in the subject field. > > Thanks, > Hesham > > Issue 1: Mixed Host/Router behaviour > by Pekka Savola, May 2001 > http://www.wcug.wwu.edu/lists/ipng/200105/msg00068.html > Erik Nordmark made a comment that the text could be clearer: > http://www.wcug.wwu.edu/lists/ipng/200105/msg00077.html > > > Issue 2: Check against the case of preferred lifetime > valid lifetime > by jinmei, Dec 2002 > http://www.atm.tut.fi/list-archive/ipng/msg07250.html > > This thread contained a possible updates on the router behavior of > sending router advertisements: > http://www.atm.tut.fi/list-archive/ipng/msg07402.html > > Issue 3: On-link assumptions in 2461 considered harmful. > This issue was raised by Alain and documented in: > draft-ietf-v6ops-onlinkassumption-00.txt > draft-ietf-v6ops-v6onbydefault-00.txt > Also see related issue in section 2.4 of: > http://www.ctie.monash.edu.au/ipv6/draft-jinchoi-ipv6-cRA-00.txt > > Issue 4: Advertisement lifetime issues raised by Pete Barany > > Issue 5: Clarifying the use of the M and O flags > (raised by Rolf and others during V6ops meeting > in San Francisco) > > Issue 6: The prefix length field in the prefix option > and its consistency with the fixed prefix size > (64 bits) in RFC 3513. > > > SEND issues: > > Issue 7: All the security discussions (e.g. assuming that AH > or ESP can be added to the ND messages) will need to > be put in the context of SEND. > > Issue 8: Security considerations section needs to consider issues > in: draft-ietf-send-psreq-04 > > Issue 9: The chicken and egg problem for ND security using IKE > as specified in: > draft-arkko-icmpv6-ike-effects-02 > > and manual SAs issues addressed in: > draft-arkko-manual-icmpv6-sas-02 > > MIP issues: > > Issue 10: Reducing MIN_DELAY_BETWEEN_RAS from 3 seconds > to 50 ms as specified in MIPv6 (many emails on the > MIP mailing list in October and November 2002) > > Issue 11: Eliminating the random delays required before sending > an RS when a mobile node does a handover to a new > link. The random delay imposed by 2461 significantly > increases the movement detection time for mobile nodes > > Issue 12: Eliminating the random delays required in 2461 when > a router sends a solicited RA. See : > draft-mkhalil-ipv6-fastra-04.txt > > Issue 13: Impacts of the omission of a prefix option. > section 2.2 in : > http://www.ctie.monash.edu.au/ipv6/draft-jinchoi-ipv6-cRA-00.txt > describes the impacts of omitting a prefix option from > an RA on movement detection for mobile nodes. RFC 2461 > does not require options to be present in every RA. > > Issue 14: Link ids required to aid with movement detection. > see: > http://www.ietf.org/internet-drafts/draft-pentland-mobileip-linkid-00.txt > > Finally, I recall (but not clearly) some discussions > on the clarity of 2461 when it comes to multihomed hosts. But > I haven't managed to find the relevant thread(s) in the > archive. So if you have an issue to add please let me know. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 18:05:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21151 for ; Thu, 23 Oct 2003 18:05:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACnZR-0007kT-VI for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 18:04:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NM4faS029784 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 18:04:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACnZR-0007kJ-Ku for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 18:04:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21075 for ; Thu, 23 Oct 2003 18:04:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACnZO-0001Fd-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 18:04:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACnZO-0001FZ-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 18:04:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACnYo-0007YF-1U; Thu, 23 Oct 2003 18:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACnY5-0007Sk-0B for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 18:03:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20935 for ; Thu, 23 Oct 2003 18:03:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACnY2-0001Ef-00 for ipv6@ietf.org; Thu, 23 Oct 2003 18:03:14 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1ACnY1-0001ES-00 for ipv6@ietf.org; Thu, 23 Oct 2003 18:03:13 -0400 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9NM31ed020466; Fri, 24 Oct 2003 00:03:02 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20031023073937.GB18135@login.ecs.soton.ac.uk> References: <748C6D0A58C0F94CA63C198B6674697A01922E07@ftmail.lab.flarion.com> <16BB6224-0529-11D8-A9F8-00039388672E@muada.com> <20031023073937.GB18135@login.ecs.soton.ac.uk> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org From: Iljitsch van Beijnum Subject: Re: "RFC 2461bis" issue: DNS configuration Date: Fri, 24 Oct 2003 00:03:06 +0200 To: Tim Chown X-Mailer: Apple Mail (2.604) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 23 okt 2003, at 9:39, Tim Chown wrote: > It will be interesting to see what the Moonv6 work may have to say in > this area, as the issue I'm sure will have been encountered there. > There are still very few people working in networks where IPv6 > transport DNS lookup is a requirement, hence this issue has seen slow > progress. I know, and in practice there won't be many hosts that run just IPv6. But what good is a new protocol if it can't stand on its own two feet and needs its predecessor to provide crucial functions? At least the new MacOS that's coming out tomorrow supports DNS transport over IPv6, making it possible to run IPv6-only. This is pretty cool. > I am in the RA camp, but I agree DHCPv6 will be used for other things > (e.g. NTP server), so in cases where a DHCPv6 server is present it > will be able to be used for resolver discovery. But I believe we > should have a RA based method also. A strong argument against using DHCPv6 would be that stateless autoconfiguration definately has the edge over DHCP so we can expect very many people to continue using autoconf even when DHCP implementations become available. Requiring DHCP in addition to stateless autoconf for just one thing that can also be done using mechanisms that autoconf uses would mean unnecessary complexity and delays. But it shouldn't be one or the other. We want/need both. > The general thrust of the DHCPv6 camp argument is that in any > situation where a router is configured to pass DNS info in a RA > extension it could equally be configured to do so using DHCPv6 (Lite), > or could forward to a DHCPv6 server using the DHCPv6 relay agent > function. I doubt that many people will be using DHCP servers with IPv6. The reason to use them in IPv4 is so you can have stable addresses across reboots. Stateless autoconfiguration already supports this much better than DHCP ever did. And let's not forget that autoconf has been available for years while DHCPv6 is just now becoming somewhat available. > The second argument used by the DHCPv6 camp is that having two methods > may lead to complexity, and problems in troubleshooting. That would be a good argument to kill DHCPv6 altogether. Having to run autoconf for the address and DHCP for nameservers is exactly the complexity we should avoid. > The third is a fear of creeping featurism - where is the line over > which you don't step for RA extensions? DNS resolver? Search path? > NTP? When was the last time your browser couldn't load a page because the NTP server wasn't found? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 19:08:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23751 for ; Thu, 23 Oct 2003 19:08:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACoZN-00015Q-3L for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 19:08:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NN8faV004170 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 19:08:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACoZM-00015B-Ux for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 19:08:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23691 for ; Thu, 23 Oct 2003 19:08:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACoZJ-0001nF-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 19:08:37 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACoZJ-0001nC-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 19:08:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACoYk-0000vH-6B; Thu, 23 Oct 2003 19:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACoYX-0000n2-Qj for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 19:07:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23602 for ; Thu, 23 Oct 2003 19:07:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACoYU-0001lc-00 for ipv6@ietf.org; Thu, 23 Oct 2003 19:07:46 -0400 Received: from albert.tavian.com ([66.149.217.205]) by ietf-mx with esmtp (Exim 4.12) id 1ACoYT-0001lX-00 for ipv6@ietf.org; Thu, 23 Oct 2003 19:07:45 -0400 Received: from localhost (doc@localhost) by albert.tavian.com (8.8.7/8.8.7) with ESMTP id QAA17093; Thu, 23 Oct 2003 16:07:38 -0700 Date: Thu, 23 Oct 2003 16:07:37 -0700 (PDT) From: Brian McGehee To: ipv6@ietf.org Subject: RE: "RFC 2461bis" issue: DNS configuration In-Reply-To: <011f01c39933$659e2270$b7cbdba8@daniel> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , A student in my IPv6 class this week made the comment regarding IPv6: "It seems like the paint isn't dry yet!" IPv6 needs stability and constant changes scare adopters away. I agree DNS should be a component of RA's. But I feel strongly that we need to stop making changes and show the industry we have stability. (i.e. Site-Local addressing) ...my 2cents... Brian McGehee ----------------------------- Native6, Inc. http://www.native6.com IPv6 Training and Consulting ----------------------------- On Thu, 23 Oct 2003, Soohong Daniel Park wrote: > Hello Hesham > > >DHCPv6 allows for DNS configuration in hosts among other things. > > Please don't definitely say that. As I said, RA based DNS discovery > is work in progress. > > > > > Regards > > Daniel (Soohong Daniel Park) > Mobile Platform Laboratory, SAMSUNG Electronics > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 20:25:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25884 for ; Thu, 23 Oct 2003 20:25:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACple-0004us-Hx for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 20:25:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O0PQ2u018895 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 20:25:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACple-0004ug-B0 for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 20:25:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25866 for ; Thu, 23 Oct 2003 20:25:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACplc-0002YO-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 20:25:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACplb-0002YL-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 20:25:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACplG-0004iR-Oy; Thu, 23 Oct 2003 20:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACpkq-0004XS-35 for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 20:24:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25848 for ; Thu, 23 Oct 2003 20:24:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACpkn-0002Xk-00 for ipv6@ietf.org; Thu, 23 Oct 2003 20:24:33 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1ACpkl-0002Xh-00 for ipv6@ietf.org; Thu, 23 Oct 2003 20:24:32 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:208:dff:fe40:3f37]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 72A4315214; Fri, 24 Oct 2003 09:24:30 +0900 (JST) Date: Fri, 24 Oct 2003 09:24:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Soliman Hesham Cc: ipv6@ietf.org Subject: Re: RFC 2461- issue list In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922E0A@ftmail.lab.flarion.com> References: <748C6D0A58C0F94CA63C198B6674697A01922E0A@ftmail.lab.flarion.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >>>>> On Thu, 23 Oct 2003 10:18:12 -0400, >>>>> Soliman Hesham said: >> I have a high-level question first; is the intent to do these updates >> and recycle the document as a draft standard? >> Or to try to move it to full standard? > => My understanding was that the new RFC would still > be in DS, but I could be wrong. It'd be good if the > chairs shed some light on this. >> If recycle at draft is the goal, are there documents (such as MIPv6) >> which contain extensions to the packet formats which should be folded >> into the base ND spec at this point in time? >> >> In addition to the MIP issues in your list there is (at least) the >> definition of the R bit in the prefix option, and the advertisement >> interval option. > => Right. So I'm not sure if the goal is to include all > the ND extensions in other specs, again it would be good > to get some feedback on this point. I assumed that extensions > would be done anyway in other specs as deemed necessary. > So, if this assumption is agreeable then the work should be > limited to clarifying points in the spec or solving problems > that were discovered by people while working with this > version of ND. FWIW, my understanding is the same on both points. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 20:35:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26332 for ; Thu, 23 Oct 2003 20:35:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACpv2-0007MW-3r for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 20:35:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O0Z8ht028300 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 20:35:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACpv1-0007MN-VU for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 20:35:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26289 for ; Thu, 23 Oct 2003 20:34:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACpuz-0002iD-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 20:35:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACpuz-0002iA-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 20:35:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACpux-0007FW-Q9; Thu, 23 Oct 2003 20:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACpuV-0007Cd-Ec for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 20:34:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26279 for ; Thu, 23 Oct 2003 20:34:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACpuT-0002hq-00 for ipv6@ietf.org; Thu, 23 Oct 2003 20:34:33 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ACpuS-0002hW-00 for ipv6@ietf.org; Thu, 23 Oct 2003 20:34:32 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9O0XtW19305; Thu, 23 Oct 2003 17:33:55 -0700 X-mProtect: <200310240033> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdYaA8G6; Thu, 23 Oct 2003 17:33:53 PDT Message-ID: <3F987491.5080501@iprg.nokia.com> Date: Thu, 23 Oct 2003 17:38:41 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Chown CC: ipv6@ietf.org Subject: Re: A host who has private IPv4 address can communicate with IPv6 host globaly by 6to4 tunnel References: <000001c39883$c7471cd0$3c01a8c0@willnote> <20031022102831.GI6932@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The same would work also for ISATAP (see: isatap.com), except that ISATAP can use any IPv6 prefix, i.e., not just 2002::/16. (Besides; 2002 was *last* year...) Fred ftemplin@iprg.nokia.com Tim Chown wrote: >Hi, > >Yes, this will work. This technique is quite widely used, and is one >reason for this draft: >http://www.ietf.org/internet-drafts/draft-palet-v6ops-proto41-nat-01.txt > >Essentially you forward the protocol 41 from the NAT to the internal host. > >It is quite a popular "trick" with our students in their home DSL LANs. > >The problem is that this only works for one host within the NAT network, >so if the NAT encompasses many sites, you're stuck. > >Cheers, >Tim > >On Wed, Oct 22, 2003 at 07:03:44PM +0900, Jisuek.Lim wrote: > > >> Hello all, >> >> I have a idea about communication method with 6to4 tunnel. >> >> Generally, we think a host who has private IPv4 address(because it is >> behind NAT device) can not communicate with IPv6 host globally by >> tunneling(6to4, config tunnel ..) But there is a way using 6to4 >> tunnel. >> >> When we config 6to4 config on a host(for example windows2000 station) >> we assign the host's IPv4 address to the host's 6to4 address(next to >> 2002:). And we know the host's IPv4 address shoud be public IPv4 >> address. >> >> But, if we use the public IPv4 address which is on NAT device's >> external interface to make the host's 6to4 address, the host can >> communicate with IPv6 host globally using 6to4 tunnel and relay >> router. Following are do list. >> >> 1. Map the NAT device's public address(select one) to the host's >> private address(configure on the NAT) >> >> 2. On the NAT device, make a policy which permit incomming >> traffic which has protocol number 41 to the host's private address >> >> 3. Change the NAT device's public IPv4 address(which you >> selected) to hex. format. >> >> 4. Configure the host's 6to4 address using upper hex. >> >> 5. Add route table for 2002 traffic to tunnel interface, and >> ::/0 to relay router(relay router is provided by some orgnization) >> >> >> And then,...try ping6 to any IPv6 address. following is the result of >> my own test. >> >> >> C:\>ping6 6to4.ipv6.fh-regensburg.de >> >> Pinging 6to4.ipv6.fh-regensburg.de [2002:c25f:6cbf:1::1] with 32 bytes >> of data: >> >> >> Reply from 2002:c25f:6cbf:1::1: bytes=32 time=330ms >> >> Reply from 2002:c25f:6cbf:1::1: bytes=32 time=329ms >> >> Reply from 2002:c25f:6cbf:1::1: bytes=32 time=329ms >> >> >> C:\> >> >> C:\>ping6 www.kame.net >> >> >> Pinging orange.kame.net [2001:200:0:8002:203:47ff:fea5:3085] with 32 >> bytes of data: >> >> >> Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=117ms >> >> Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=72ms >> >> Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=68ms >> >> Reply from 2001:200:0:8002:203:47ff:fea5:3085: bytes=32 time=71ms >> >> >> C:\> >> >> >> Following is my computer's IP config >> >> >> C:\>ipconfig >> >> >> Windows 2000 IP Configuration >> >> >> Ethernet adapter : >> >> >> Connection-specific DNS Suffix . : >> >> IP Address. . . . . . . . . . . . : 192.168.1.60 >> >> Subnet Mask . . . . . . . . . . . : 255.255.255.0 >> >> Default Gateway . . . . . . . . . : 192.168.1.254 >> >> >> C:\> >> >> >> as you know 192.168.1.60 is private address !! >> >> Try it. >> >> Thanks. >> >> Jisuek. Lim >> >> > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 20:40:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26534 for ; Thu, 23 Oct 2003 20:40:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACpzw-0000uP-1h for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 20:40:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O0eBF0003455 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 20:40:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACpzu-0000pW-Tb for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 20:40:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26486 for ; Thu, 23 Oct 2003 20:40:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACpzs-0002nT-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 20:40:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACpzs-0002nQ-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 20:40:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACpzp-0000kz-D5; Thu, 23 Oct 2003 20:40:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACpzV-0000gL-D2 for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 20:39:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26466 for ; Thu, 23 Oct 2003 20:39:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACpzT-0002mi-00 for ipv6@ietf.org; Thu, 23 Oct 2003 20:39:43 -0400 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1ACpzS-0002mf-00 for ipv6@ietf.org; Thu, 23 Oct 2003 20:39:42 -0400 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 4A47E8311; Fri, 24 Oct 2003 02:39:40 +0200 (CEST) From: "Jeroen Massar" To: "'Fred Templin'" Cc: Subject: RE: A host who has private IPv4 address can communicate with IPv6 host globaly by 6to4 tunnel Date: Fri, 24 Oct 2003 02:39:29 +0200 Organization: Unfix Message-ID: <005801c399c7$49992220$210d640a@unfix.org> 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.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3F987491.5080501@iprg.nokia.com> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Fred Templin wrote: > The same would work also for ISATAP (see: isatap.com), except > that ISATAP can use any IPv6 prefix, i.e., not just 2002::/16. > (Besides; 2002 was *last* year...) They are talking about 6to4 (proto-41 :) which can use both prefixes from 2001::/16 (the year before that) and 3ffe::/16 (thats a long time from now :) and basically anything one invents ofcourse ;) Personally I have to admit that I never used isatap... I should look into it some time. Greets, Jeroen > >Hi, > > > >Yes, this will work. This technique is quite widely used, and is one > >reason for this draft: > >http://www.ietf.org/internet-drafts/draft-palet-v6ops-proto41-nat-01.txt -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP5h0wSmqKFIzPnwjEQKNWACfbD4K7dQBOnHgFpcuj1fAU86R0UQAoIeK aZJpcltCShg3B75nDBdrR799 =mpQS -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 20:53:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26977 for ; Thu, 23 Oct 2003 20:53:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACqCT-0002VJ-U2 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 20:53:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O0r9kv009619 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 20:53:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACqCT-0002U6-L6 for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 20:53:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26940 for ; Thu, 23 Oct 2003 20:52:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACqCQ-0002zo-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 20:53:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACqCQ-0002zl-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 20:53:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACqCL-0002Nq-Ug; Thu, 23 Oct 2003 20:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACqBr-0002M2-Lu for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 20:52:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26923 for ; Thu, 23 Oct 2003 20:52:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACqBp-0002zN-00 for ipv6@ietf.org; Thu, 23 Oct 2003 20:52:29 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ACqBo-0002zB-00 for ipv6@ietf.org; Thu, 23 Oct 2003 20:52:28 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9O0pujP016160 for ; Thu, 23 Oct 2003 17:51:57 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-334.cisco.com [10.82.225.78]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADK71094; Thu, 23 Oct 2003 20:51:55 -0400 (EDT) Message-Id: <4.3.2.7.2.20031023204646.044801c0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Oct 2003 20:51:53 -0400 To: ipv6@ietf.org From: Ralph Droms Subject: Re: "RFC 2461bis" issue: DNS configuration In-Reply-To: References: <20031023073937.GB18135@login.ecs.soton.ac.uk> <748C6D0A58C0F94CA63C198B6674697A01922E07@ftmail.lab.flarion.com> <16BB6224-0529-11D8-A9F8-00039388672E@muada.com> <20031023073937.GB18135@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Following up on Pekka's e-mail, the DNS configuration problem now belongs to the dnsop WG, and followups to this thread should be posted to dnsop@cafax.se. Most (if not all) of the issues from this thread have already been discussed at the dnsop WG meeting in Vienna and on dnsop@cafax.se Please take a look at the minutes from the Vienna WG meeting, http://ietf.org/proceedings/03jul/index.html, and the dnsop mailing list archive, http://www.cafax.se/dnsop/maillist, for more information. There are lots of problems in this space we haven't solved yet, like how to do secure updates of PTR records for IPv6 hosts that use stateless address autoconfiguration - seems to me we ought to apply our spare cycles to those unsolved problems instead of inventing new solutions to solved problems... - Ralph At 12:03 AM 10/24/2003 +0200, Iljitsch van Beijnum wrote: >On 23 okt 2003, at 9:39, Tim Chown wrote: > >>It will be interesting to see what the Moonv6 work may have to say in >>this area, as the issue I'm sure will have been encountered there. >>There are still very few people working in networks where IPv6 transport >>DNS lookup is a requirement, hence this issue has seen slow progress. > >I know, and in practice there won't be many hosts that run just IPv6. But >what good is a new protocol if it can't stand on its own two feet and >needs its predecessor to provide crucial functions? > >At least the new MacOS that's coming out tomorrow supports DNS transport >over IPv6, making it possible to run IPv6-only. This is pretty cool. > >>I am in the RA camp, but I agree DHCPv6 will be used for other things >>(e.g. NTP server), so in cases where a DHCPv6 server is present it will >>be able to be used for resolver discovery. But I believe we should have >>a RA based method also. > >A strong argument against using DHCPv6 would be that stateless >autoconfiguration definately has the edge over DHCP so we can expect very >many people to continue using autoconf even when DHCP implementations >become available. Requiring DHCP in addition to stateless autoconf for >just one thing that can also be done using mechanisms that autoconf uses >would mean unnecessary complexity and delays. > >But it shouldn't be one or the other. We want/need both. > >>The general thrust of the DHCPv6 camp argument is that in any situation >>where a router is configured to pass DNS info in a RA extension it could >>equally be configured to do so using DHCPv6 (Lite), or could forward to a >>DHCPv6 server using the DHCPv6 relay agent function. > >I doubt that many people will be using DHCP servers with IPv6. The reason >to use them in IPv4 is so you can have stable addresses across reboots. >Stateless autoconfiguration already supports this much better than DHCP >ever did. And let's not forget that autoconf has been available for years >while DHCPv6 is just now becoming somewhat available. > >>The second argument used by the DHCPv6 camp is that having two methods >>may lead to complexity, and problems in troubleshooting. > >That would be a good argument to kill DHCPv6 altogether. Having to run >autoconf for the address and DHCP for nameservers is exactly the >complexity we should avoid. > >>The third is a fear of creeping featurism - where is the line over which >>you don't step for RA extensions? DNS resolver? Search path? >>NTP? > >When was the last time your browser couldn't load a page because the NTP >server wasn't found? > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 21:11:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27553 for ; Thu, 23 Oct 2003 21:11:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACqTz-0004At-H7 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 21:11:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O1BFSE016041 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 21:11:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACqTz-0004Ae-C1 for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 21:11:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27513 for ; Thu, 23 Oct 2003 21:11:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACqTw-0003Dr-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 21:11:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACqTw-0003Do-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 21:11:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACqTm-00045L-Cj; Thu, 23 Oct 2003 21:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACqT6-00041t-7j for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 21:10:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27488; Thu, 23 Oct 2003 21:10:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACqT3-0003DN-00; Thu, 23 Oct 2003 21:10:17 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ACqT2-0003D9-00; Thu, 23 Oct 2003 21:10:17 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9O19iL13607; Thu, 23 Oct 2003 18:09:44 -0700 X-mProtect: <200310240109> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxzsP5s; Thu, 23 Oct 2003 18:09:43 PDT Message-ID: <3F987C5B.9070905@iprg.nokia.com> Date: Thu, 23 Oct 2003 18:11:55 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jinmei@isl.rdc.toshiba.co.jp, Soliman Hesham CC: ipv6@ietf.org, mip6@ietf.org Subject: Re: A list of issues for RFC2462 update References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit hi, here is another issue. it involves both 2461 and 2462. RFC 2461 says 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. RFC 2462 says If the Neighbor Solicitation is the first message to be sent from an interface after interface (re)initialization, the node should delay sending the message by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY]. lets assume a Mobile Node moves and attaches to a new link. it does router discovery and configures a Care-of address. the mobile node cannot send a Binding Update until it completes DAD for the Care-of address. these two random delays (before router discovery and before DAD) contribute a lot to the movement detection delay. I think this needs to be fixed. MAX_RTR_SOLICITATION_DELAY is 1 second. taking the worst case scenario, it could be 1 second before a sending router solicitation, one second before sending neighbor solicitation for DAD and then 1 second before DAD completes. the Binding Update cannot be sent until then. we had a long discussion on the Mobile IP mailing list. some argued that this needs to be done only when the interface is initialized and not when the mobile node attaches to a new link. others argued that this random delay is essential to avoid a DAD storm if a bunch of mobile nodes move at the same time. there is some discussion on this at http://www.piuha.net/~jarkko/publications/mipv6/issues/issue230.txt Vijay JINMEI Tatuya / ???? wrote: > Hello, > > The attached below is a issue list to make necessary updates on > RFC2462 (Stateless Address Autoconfiguration). > > To make this list, I've grepped the ipngwg/ipv6 ML archives from > Jan. 1998 with the keywords "2462" and "stateless," and picked up > issues that seem to be related to this update. Of course, I'm not > claiming the keywords are enough, and even if they are, I may have > missed something important. > > Thus, any corrections/additions are welcome. I'd apologize in advance > the list is not necessarily very readable, but I believe it provides > some hints to start discussion. I'll collect comments on the list, > and edit a new internet draft which will basically be a copy of > RFC2462 with the issue list. > > Due to a lack of time to the cut-off date of an initial draft, I > don't think I can propose any resolutions to the issues. So, please > concentrate, at the moment, on completing or correcting the list, > rather than to discuss how to solve particular ones. > > Thanks, > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > > Easy ones (which will only need some editorial works): > > - A minor typo > by Ignatios Souvatzis, Dec. 1998 > http://www.wcug.wwu.edu/lists/ipng/199812/msg00043.html > > - Dead Code in Addrconf DOS Algortim Prevention > by Jim Bound, Nov 1998 > http://www.wcug.wwu.edu/lists/ipng/199811/msg00024.html > > - A corner case about inbound NA processing > by Richard Draves (via TAHI test), Jun 2000 > > There was a consensus on the behavior, but the text is not clear. > Need to update. > > - Unclear text about StoredLifetime > by jinmei, Aug 2001 > http://www.wcug.wwu.edu/lists/ipng/200108/msg00541.html > > need to clarify the text. > > === > > Issues that may require some discussion, but will not be very hard to > get consensus: > > - Source address selection issues wrt deprecated addresses > mainly by Richard Draves, several times. > e.g. which should be preferred between a deprecated address and > smaller-scope address? > > - Deprecated address handling (the semantics of "new communication" is > not very clear) > by itojun, Nov 2000 and Aug 2002 > > There seemed to be a consensus on a text proposed by Thomas Narten: > http://www.atm.tut.fi/list-archive/ipng/msg05182.html > > Erik Nordmark made a related point (what if an application specifies > a deprecated address as a source address): > http://www.atm.tut.fi/list-archive/ipng/msg05311.html > > There seemed to be no discussion on this, but we may need to > consider this as well. > > - Semantics about the L=0 and A=1 case > by Fred Templin, Feb 2003 > > Thomas Narten said he did not see the need for further > clarification (which I agree on): > http://www.atm.tut.fi/list-archive/ipng/msg07820.html > > - Conflict with the MLD spec about random delay for the first packet > by Greg Daley, May 2005 > http://www.atm.tut.fi/list-archive/ipng/msg09614.html > > - Using stable storage for autoconfigured addresses > by Erik Nordmark, Jun 2002 > http://www.atm.tut.fi/list-archive/ipng/msg04383.html > > There seemed to be no discussion on this. > > === > > Issues that may be controversial: > > - DAD related issues > inconsistency in the text (mixture of SHOULD and MAY) > by itojun, Jun 2001 > > What about the link partitioning case > by Pekka Savola, Jun 2001(?) > > omitting DAD, DAD vs DIID, etc. > many people, many times > > - Possible Denial of Service Attack > by Ken Powell, Feb 2002 > What if a malicious node intentionally sends prefixes for other LANs? > There seemed to be no clear consensus. > > - The semantics of the M/O flags > by several people, several times. Points from Ralph Droms in Mar > 2003 seems to be a good starting point: > http://www.atm.tut.fi/list-archive/ipng/msg03047.html > > a. the text needs to be updated to use RFC 2119 keywords > b. which keywords? > c. what is "the stateful configuration protocol"? > d. if the answer to "c" is DHCPv6, should RFC 2462 more > explicitly reference the configuration-only version > of DHCPv6 in the description of the 'O'flag? > > Adam Machalek also pointed out some inconsistency about mandatory > level of the stateful configuration protocol: > > http://www.atm.tut.fi/list-archive/ipng/msg04363.html > > - Whether a (not a host) router can autoconfigure itself using RFC2462 > (or bis) including > if a router can configure a global address by stateless autoconf > if a router can configure a link-local address in a way described > in RFC 2462 > if a router can configure itself about "other" configuration > information > > by several people, several times > > - If we need a 'not-yet-ready' status of an autoconfigured address to > help renumbering operation > by Fred Baker, Apr 2003 > http://www.atm.tut.fi/list-archive/ipng/msg09394.html > > - Avoiding interface failure upon DAD failure > (mainly) by Jari Arkko, May 2003 > related to mip6. (the latest draft leaves this as "ND extensions") > > - If RFC2462 requires 64bit IFID > by several people, several times. > > - Issues raised in the send requirement draft. > (Sorry, I've not gone through the send requirement draft. So there > may or may not be issues from the draft that need to be added here) > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 21:37:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28510 for ; Thu, 23 Oct 2003 21:37:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACqtO-00074x-9l for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 21:37:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O1bUQM027202 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 21:37:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACqtN-00074c-Ae for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 21:37:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28464 for ; Thu, 23 Oct 2003 21:37:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACqtK-0003c6-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 21:37:26 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACqtK-0003c3-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 21:37:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACqsy-0006rT-Dr; Thu, 23 Oct 2003 21:37:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACqsX-0006iu-W7 for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 21:36:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28435 for ; Thu, 23 Oct 2003 21:36:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACqsV-0003b9-00 for ipv6@ietf.org; Thu, 23 Oct 2003 21:36:35 -0400 Received: from pec.etri.re.kr ([129.254.114.50]) by ietf-mx with esmtp (Exim 4.12) id 1ACqsU-0003aP-00 for ipv6@ietf.org; Thu, 23 Oct 2003 21:36:34 -0400 Received: from pjs3 (pjs2.etri.re.kr [129.254.112.155]) by pec.etri.re.kr (8.12.10/8.12.10) with ESMTP id h9O1ol5l005129; Fri, 24 Oct 2003 10:50:47 +0900 (KST) Message-Id: <200310240150.h9O1ol5l005129@pec.etri.re.kr> Reply-To: From: "jspark" To: "'Pekka Savola'" , "'Myung-Ki Shin'" Cc: Subject: RE: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses" Date: Fri, 24 Oct 2003 10:36:00 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook, Build 11.0.4920 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcOZLxTrsYhDaCzNSTiddRZt+oFkSAAmrBYg Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Pekka. >>>Pekka Savola wrote: >> > First, there is no guarantee of uniqueness in the first place, as >> > DAD on the IPv6 link-local unicast address was performed on the >> > address, not the Interface-ID. In practice, the collisions should be very rare, though. >>Myung-Ki Shin wrote: >> I don't think so. >> DAD on the IPv6 link-local unicast address also guarantees the uniqueness >> of Interface-ID in the link-local unicast address. >> I beleive that there was a consensus on that (when the draft was >> published). >Pekka Savola wrote: >No, I think it was specifically some form of consensus that DAD is not DIID. >This is true in particular with unicast prefixes. This happens with link-local prefixes as well, >if you use e.g. fe81::1 and fe80::1 on the same physical link but pointing to >different nodes. >(Btw, does the spec say the interface-ID must be taken from the link-local address? >If not, it will have problems with manually configured global addresses..) I understand what you mean. So, I'd like to clarify this. Section 3 of our spec says: ----------- "Interface ID field is used to distinguish each host from others. And this value is obtained from the IEEE EUI-64 based interface identifier of the link-local unicast IPv6 address." ----------- Our method uses only the EUI-64 based Interface ID, derived from Link-local unicast address. So, there is guarantee of uniqueness in our method. >> > Pekka Savola wrote: >> > 2) the current spec uses the reserved field in such a fashion that >> > plen=0 and the other nodes not implementing this spec will interpret >> > the link-local multicast addresses generated using this spec as SSM addresses. >>Myung-Ki Shin wrote: >> In unicast-prefix, >> to accomplish SSM, a node MUST: [RFC 3306] >> >> o Set P = 1. >> o Set plen = 0. >> o Set network prefix = 0. >> >> Thus, the "network prefix" should be mentioned to distinguished the >> conflict. >> In this draft, "Interface ID" of link-scoped mcast address != 0. >> I think this clarification should be added in current document. >Pekka Savola wrote: >If an SSM implementation checks for FF3x::/32 (as described in RFC 3306 section 6), >and not for FF3x::/96 (as described in RFC 3306 section 7), but will not implement this specification, >there will be lots of trouble. Of course, I think a SSM implementation "MUST" check for FF3x::/96. Thanks JungSoo -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 22:10:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29371 for ; Thu, 23 Oct 2003 22:10:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrP6-00006W-8j for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 22:10:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O2AGwE000390 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 22:10:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrP5-00006D-SK for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 22:10:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29320 for ; Thu, 23 Oct 2003 22:10:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACrP2-0003xX-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 22:10:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACrP2-0003xU-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 22:10:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrOs-0008Nu-AH; Thu, 23 Oct 2003 22:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrNx-0008Et-40 for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 22:09:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29304; Thu, 23 Oct 2003 22:08:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACrNt-0003x8-00; Thu, 23 Oct 2003 22:09:01 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ACrNt-0003wy-00; Thu, 23 Oct 2003 22:09:01 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RDFGF>; Thu, 23 Oct 2003 22:12:50 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E0F@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Vijay Devarapalli'" , jinmei@isl.rdc.toshiba.co.jp Cc: ipv6@ietf.org, mip6@ietf.org Subject: RE: A list of issues for RFC2462 update Date: Thu, 23 Oct 2003 22:12:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Vijay, Yes, this issue is the same as issue 11 for the RS. I'll add that to the list. Thanks, Hesham > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: Thursday, October 23, 2003 9:12 PM > To: jinmei@isl.rdc.toshiba.co.jp; Soliman Hesham > Cc: ipv6@ietf.org; mip6@ietf.org > Subject: Re: A list of issues for RFC2462 update > > > hi, > > here is another issue. it involves both 2461 and 2462. > > RFC 2461 says > > 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. > > RFC 2462 says > > If the Neighbor Solicitation is the first message to be > sent from an > interface after interface (re)initialization, the node > should delay > sending the message by a random delay between 0 and > MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY]. > > lets assume a Mobile Node moves and attaches to a new > link. it does router discovery and configures a Care-of > address. the mobile node cannot send a Binding Update > until it completes DAD for the Care-of address. these > two random delays (before router discovery and before > DAD) contribute a lot to the movement detection delay. > I think this needs to be fixed. > MAX_RTR_SOLICITATION_DELAY is 1 second. taking the worst > case scenario, it could be 1 second before a sending > router solicitation, one second before sending neighbor > solicitation for DAD and then 1 second before DAD > completes. the Binding Update cannot be sent until then. > > we had a long discussion on the Mobile IP mailing list. > some argued that this needs to be done only when the > interface is initialized and not when the mobile node > attaches to a new link. others argued that this random > delay is essential to avoid a DAD storm if a bunch of > mobile nodes move at the same time. > > there is some discussion on this at > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue230.txt > > Vijay > > > JINMEI Tatuya / ???? wrote: > > Hello, > > > > The attached below is a issue list to make necessary updates on > > RFC2462 (Stateless Address Autoconfiguration). > > > > To make this list, I've grepped the ipngwg/ipv6 ML archives from > > Jan. 1998 with the keywords "2462" and "stateless," and picked up > > issues that seem to be related to this update. Of course, I'm not > > claiming the keywords are enough, and even if they are, I may have > > missed something important. > > > > Thus, any corrections/additions are welcome. I'd > apologize in advance > > the list is not necessarily very readable, but I believe > it provides > > some hints to start discussion. I'll collect comments on the list, > > and edit a new internet draft which will basically be a copy of > > RFC2462 with the issue list. > > > > Due to a lack of time to the cut-off date of an initial draft, I > > don't think I can propose any resolutions to the issues. > So, please > > concentrate, at the moment, on completing or correcting the list, > > rather than to discuss how to solve particular ones. > > > > Thanks, > > > > JINMEI, Tatuya > > Communication Platform Lab. > > Corporate R&D Center, > Toshiba Corp. > > jinmei@isl.rdc.toshiba.co.jp > > > > > > Easy ones (which will only need some editorial works): > > > > - A minor typo > > by Ignatios Souvatzis, Dec. 1998 > > http://www.wcug.wwu.edu/lists/ipng/199812/msg00043.html > > > > - Dead Code in Addrconf DOS Algortim Prevention > > by Jim Bound, Nov 1998 > > http://www.wcug.wwu.edu/lists/ipng/199811/msg00024.html > > > > - A corner case about inbound NA processing > > by Richard Draves (via TAHI test), Jun 2000 > > > > There was a consensus on the behavior, but the text is not clear. > > Need to update. > > > > - Unclear text about StoredLifetime > > by jinmei, Aug 2001 > > http://www.wcug.wwu.edu/lists/ipng/200108/msg00541.html > > > > need to clarify the text. > > > > === > > > > Issues that may require some discussion, but will not be > very hard to > > get consensus: > > > > - Source address selection issues wrt deprecated addresses > > mainly by Richard Draves, several times. > > e.g. which should be preferred between a deprecated address and > > smaller-scope address? > > > > - Deprecated address handling (the semantics of "new > communication" is > > not very clear) > > by itojun, Nov 2000 and Aug 2002 > > > > There seemed to be a consensus on a text proposed by > Thomas Narten: > > http://www.atm.tut.fi/list-archive/ipng/msg05182.html > > > > Erik Nordmark made a related point (what if an > application specifies > > a deprecated address as a source address): > > http://www.atm.tut.fi/list-archive/ipng/msg05311.html > > > > There seemed to be no discussion on this, but we may need to > > consider this as well. > > > > - Semantics about the L=0 and A=1 case > > by Fred Templin, Feb 2003 > > > > Thomas Narten said he did not see the need for further > > clarification (which I agree on): > > http://www.atm.tut.fi/list-archive/ipng/msg07820.html > > > > - Conflict with the MLD spec about random delay for the > first packet > > by Greg Daley, May 2005 > > http://www.atm.tut.fi/list-archive/ipng/msg09614.html > > > > - Using stable storage for autoconfigured addresses > > by Erik Nordmark, Jun 2002 > > http://www.atm.tut.fi/list-archive/ipng/msg04383.html > > > > There seemed to be no discussion on this. > > > > === > > > > Issues that may be controversial: > > > > - DAD related issues > > inconsistency in the text (mixture of SHOULD and MAY) > > by itojun, Jun 2001 > > > > What about the link partitioning case > > by Pekka Savola, Jun 2001(?) > > > > omitting DAD, DAD vs DIID, etc. > > many people, many times > > > > - Possible Denial of Service Attack > > by Ken Powell, Feb 2002 > > What if a malicious node intentionally sends prefixes > for other LANs? > > There seemed to be no clear consensus. > > > > - The semantics of the M/O flags > > by several people, several times. Points from Ralph Droms in Mar > > 2003 seems to be a good starting point: > > http://www.atm.tut.fi/list-archive/ipng/msg03047.html > > > > a. the text needs to be updated to use RFC 2119 keywords > > b. which keywords? > > c. what is "the stateful configuration protocol"? > > d. if the answer to "c" is DHCPv6, should RFC 2462 more > > explicitly reference the configuration-only version > > of DHCPv6 in the description of the 'O'flag? > > > > Adam Machalek also pointed out some inconsistency about mandatory > > level of the stateful configuration protocol: > > > > http://www.atm.tut.fi/list-archive/ipng/msg04363.html > > > > - Whether a (not a host) router can autoconfigure itself > using RFC2462 > > (or bis) including > > if a router can configure a global address by > stateless autoconf > > if a router can configure a link-local address in a > way described > > in RFC 2462 > > if a router can configure itself about "other" configuration > > information > > > > by several people, several times > > > > - If we need a 'not-yet-ready' status of an autoconfigured > address to > > help renumbering operation > > by Fred Baker, Apr 2003 > > http://www.atm.tut.fi/list-archive/ipng/msg09394.html > > > > - Avoiding interface failure upon DAD failure > > (mainly) by Jari Arkko, May 2003 > > related to mip6. (the latest draft leaves this as "ND > extensions") > > > > - If RFC2462 requires 64bit IFID > > by several people, several times. > > > > - Issues raised in the send requirement draft. > > (Sorry, I've not gone through the send requirement > draft. So there > > may or may not be issues from the draft that need to be > added here) > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 22:18:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29577 for ; Thu, 23 Oct 2003 22:18:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrWh-0002Zw-6c for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 22:18:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O2I7I5009905 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 22:18:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrWg-0002YI-IR for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 22:18:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29537 for ; Thu, 23 Oct 2003 22:17:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACrWd-00042P-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 22:18:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACrWc-00042M-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 22:18:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrWc-0002Qm-Ch; Thu, 23 Oct 2003 22:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrWa-0002Q1-OI for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 22:18:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29533 for ; Thu, 23 Oct 2003 22:17:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACrWX-00042I-00 for ipv6@ietf.org; Thu, 23 Oct 2003 22:17:57 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1ACrWW-000427-00 for ipv6@ietf.org; Thu, 23 Oct 2003 22:17:57 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HN800B01P128X@mailout1.samsung.com> for ipv6@ietf.org; Fri, 24 Oct 2003 11:17:26 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HN800EALP112K@mailout1.samsung.com> for ipv6@ietf.org; Fri, 24 Oct 2003 11:17:26 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HN800DABP1146@mmp1.samsung.com> for ipv6@ietf.org; Fri, 24 Oct 2003 11:17:25 +0900 (KST) Date: Fri, 24 Oct 2003 11:17:43 +0900 From: Soohong Daniel Park Subject: RE: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses" In-reply-to: <200310240150.h9O1ol5l005129@pec.etri.re.kr> To: jspark@pec.etri.re.kr, "'Pekka Savola'" , "'Myung-Ki Shin'" Cc: ipv6@ietf.org Message-id: <01ad01c399d5$02139f30$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > Hi, Pekka. > > >>>Pekka Savola wrote: > >> > First, there is no guarantee of uniqueness in the first place, as > >> > DAD on the IPv6 link-local unicast address was performed on the > >> > address, not the Interface-ID. In practice, the > collisions should be > very rare, though. My understanding is that there will be no problem, because the spec says the interface-ID must be taken from the link-local address (IEEE-64 based interface ID) > >Pekka Savola wrote: > >If an SSM implementation checks for FF3x::/32 (as described > in RFC 3306 > section 6), > >and not for FF3x::/96 (as described in RFC 3306 section 7), > but will not > implement this specification, > >there will be lots of trouble. > I think all SSM multicast addresses must have the format FF3x::/96, according to ["network prefix = 0" of RFC 3306] hence there will be no trouble. Daniel -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 22:19:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29663 for ; Thu, 23 Oct 2003 22:19:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrXc-0002z6-Dz for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 22:19:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O2J4c8011466 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 22:19:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrXc-0002yr-82 for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 22:19:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29613 for ; Thu, 23 Oct 2003 22:18:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACrXZ-00043o-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 22:19:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACrXY-00043l-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 22:19:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrXa-0002rl-C9; Thu, 23 Oct 2003 22:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrWh-0002Zp-3o for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 22:18:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29540 for ; Thu, 23 Oct 2003 22:17:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACrWd-00042U-00 for ipv6@ietf.org; Thu, 23 Oct 2003 22:18:03 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ACrWd-00042E-00 for ipv6@ietf.org; Thu, 23 Oct 2003 22:18:03 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RDFGX>; Thu, 23 Oct 2003 22:21:53 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E10@ftmail.lab.flarion.com> From: Soliman Hesham To: "'suresh.krishnan@ericsson.ca'" , ipv6@ietf.org Cc: Soliman Hesham Subject: RE: RFC 2461-new issue? Date: Thu, 23 Oct 2003 22:21:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > In section 4.2 of RFC 2461 regarding the RA message format > the following > is mentioned > > Reserved A 6-bit unused field. It MUST be initialized to > zero by the sender and MUST be ignored by the > receiver. > > The mobile-ipv6 draft draft-ietf-mobileip-ipv6-24.txt > mandates using the > most significant bit of this field as a home agent bit(will > be set to 1 if > the router is also a MIPv6 HA on this link). I do not know > what is the > best way to solve this apparent contradiction. I see the following > possible solutions (in no particular order) => I don't think there is a contradiction. Any IETF spec can be extended by another spec. The question is whether we want to include all these extensions in the new ND spec. I have no problem with that, but I see a couple of issues: 1. New extensions are bound to happen anyway and people will implement them as they come. So the ND spec is likely to not always include all extensions. 2. This RFC is in DS status and my understanding is that there is a limit on the new features that can be included, especially if they come from less mature specifications. If (2) above is incorrect then there is no problem with adding new features. Hesham > > * Reduce the reserved field length in RFC2461bis to 5 bits > * Change the MUSTs to SHOULDs in RFC2461bis > * Put a note on RFC2461/RFC2461bis in the rfc-index saying > it has been > updated by the MIPv6 RFC(when it comes out) > > Regards > Suresh > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 22:25:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29861 for ; Thu, 23 Oct 2003 22:25:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrdl-0004ds-Rt for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 22:25:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O2PPDC017838 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 22:25:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrdl-0004dd-MB for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 22:25:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29822 for ; Thu, 23 Oct 2003 22:25:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACrdi-00048u-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 22:25:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACrdi-00048r-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 22:25:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrdP-0004T8-8c; Thu, 23 Oct 2003 22:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrcn-0004Og-KL for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 22:24:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29811; Thu, 23 Oct 2003 22:24:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACrck-00048T-00; Thu, 23 Oct 2003 22:24:22 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1ACrcj-00048A-00; Thu, 23 Oct 2003 22:24:21 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HN800C01PBRYM@mailout2.samsung.com>; Fri, 24 Oct 2003 11:23:51 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HN8008AJPBQQ6@mailout2.samsung.com>; Fri, 24 Oct 2003 11:23:50 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HN800DJHPBQ46@mmp1.samsung.com>; Fri, 24 Oct 2003 11:23:50 +0900 (KST) Date: Fri, 24 Oct 2003 11:24:08 +0900 From: Soohong Daniel Park Subject: RE: [Mip6] Re: A list of issues for RFC2462 update In-reply-to: <3F987C5B.9070905@iprg.nokia.com> To: "'Vijay Devarapalli'" , jinmei@isl.rdc.toshiba.co.jp, "'Soliman Hesham'" Cc: ipv6@ietf.org, mip6@ietf.org, dna@eng.monash.edu.au Message-id: <01ae01c399d5$e748d660$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hello Vijay I agreed with your mention and this issue is work in progress at the DNA BOF. A second BOF will be scheduled during this meeting. For more reference, please look into this draft. http://www.ietf.org/internet-drafts/draft-park-dna-ipv6dadopt-requiremen t-01.txt Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics > -----Original Message----- > From: mip6-admin@ietf.org [mailto:mip6-admin@ietf.org] On > Behalf Of Vijay Devarapalli > Sent: Friday, October 24, 2003 10:12 AM > To: jinmei@isl.rdc.toshiba.co.jp; Soliman Hesham > Cc: ipv6@ietf.org; mip6@ietf.org > Subject: [Mip6] Re: A list of issues for RFC2462 update > > > hi, > > here is another issue. it involves both 2461 and 2462. > > RFC 2461 says > > 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. > > RFC 2462 says > > If the Neighbor Solicitation is the first message to be > sent from an > interface after interface (re)initialization, the node > should delay > sending the message by a random delay between 0 and > MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY]. > > lets assume a Mobile Node moves and attaches to a new > link. it does router discovery and configures a Care-of > address. the mobile node cannot send a Binding Update until > it completes DAD for the Care-of address. these two random > delays (before router discovery and before > DAD) contribute a lot to the movement detection delay. > I think this needs to be fixed. > MAX_RTR_SOLICITATION_DELAY is 1 second. taking the worst > case scenario, it could be 1 second before a sending > router solicitation, one second before sending neighbor > solicitation for DAD and then 1 second before DAD completes. > the Binding Update cannot be sent until then. > > we had a long discussion on the Mobile IP mailing list. > some argued that this needs to be done only when the > interface is initialized and not when the mobile node > attaches to a new link. others argued that this random > delay is essential to avoid a DAD storm if a bunch of > mobile nodes move at the same time. > > there is some discussion on this at > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue230.txt > > Vijay > > > JINMEI Tatuya / ???? wrote: > > Hello, > > > > The attached below is a issue list to make necessary updates on > > RFC2462 (Stateless Address Autoconfiguration). > > > > To make this list, I've grepped the ipngwg/ipv6 ML archives > from Jan. > > 1998 with the keywords "2462" and "stateless," and picked up issues > > that seem to be related to this update. Of course, I'm not > claiming > > the keywords are enough, and even if they are, I may have missed > > something important. > > > > Thus, any corrections/additions are welcome. I'd apologize > in advance > > the list is not necessarily very readable, but I believe it > provides > > some hints to start discussion. I'll collect comments on the list, > > and edit a new internet draft which will basically be a copy of > > RFC2462 with the issue list. > > > > Due to a lack of time to the cut-off date of an initial > draft, I don't > > think I can propose any resolutions to the issues. So, please > > concentrate, at the moment, on completing or correcting the list, > > rather than to discuss how to solve particular ones. > > > > Thanks, > > > > JINMEI, Tatuya > > Communication Platform Lab. > > Corporate R&D Center, > Toshiba Corp. > > jinmei@isl.rdc.toshiba.co.jp > > > > > > Easy ones (which will only need some editorial works): > > > > - A minor typo > > by Ignatios Souvatzis, Dec. 1998 > > http://www.wcug.wwu.edu/lists/ipng/199812/msg00043.html > > > > - Dead Code in Addrconf DOS Algortim Prevention > > by Jim Bound, Nov 1998 > > http://www.wcug.wwu.edu/lists/ipng/199811/msg00024.html > > > > - A corner case about inbound NA processing > > by Richard Draves (via TAHI test), Jun 2000 > > > > There was a consensus on the behavior, but the text is not clear. > > Need to update. > > > > - Unclear text about StoredLifetime > > by jinmei, Aug 2001 > > http://www.wcug.wwu.edu/lists/ipng/200108/msg00541.html > > > > need to clarify the text. > > > > === > > > > Issues that may require some discussion, but will not be > very hard to > > get consensus: > > > > - Source address selection issues wrt deprecated addresses > > mainly by Richard Draves, several times. > > e.g. which should be preferred between a deprecated address and > > smaller-scope address? > > > > - Deprecated address handling (the semantics of "new > communication" is > > not very clear) > > by itojun, Nov 2000 and Aug 2002 > > > > There seemed to be a consensus on a text proposed by > Thomas Narten: > > http://www.atm.tut.fi/list-archive/ipng/msg05182.html > > > > Erik Nordmark made a related point (what if an > application specifies > > a deprecated address as a source address): > > http://www.atm.tut.fi/list-archive/ipng/msg05311.html > > > > There seemed to be no discussion on this, but we may need to > > consider this as well. > > > > - Semantics about the L=0 and A=1 case > > by Fred Templin, Feb 2003 > > > > Thomas Narten said he did not see the need for further > > clarification (which I agree on): > > http://www.atm.tut.fi/list-archive/ipng/msg07820.html > > > > - Conflict with the MLD spec about random delay for the first packet > > by Greg Daley, May 2005 > > http://www.atm.tut.fi/list-archive/ipng/msg09614.html > > > > - Using stable storage for autoconfigured addresses > > by Erik Nordmark, Jun 2002 > > http://www.atm.tut.fi/list-archive/ipng/msg04383.html > > > > There seemed to be no discussion on this. > > > > === > > > > Issues that may be controversial: > > > > - DAD related issues > > inconsistency in the text (mixture of SHOULD and MAY) > > by itojun, Jun 2001 > > > > What about the link partitioning case > > by Pekka Savola, Jun 2001(?) > > > > omitting DAD, DAD vs DIID, etc. > > many people, many times > > > > - Possible Denial of Service Attack > > by Ken Powell, Feb 2002 > > What if a malicious node intentionally sends prefixes > for other LANs? > > There seemed to be no clear consensus. > > > > - The semantics of the M/O flags > > by several people, several times. Points from Ralph Droms in Mar > > 2003 seems to be a good starting point: > > http://www.atm.tut.fi/list-archive/ipng/msg03047.html > > > > a. the text needs to be updated to use RFC 2119 keywords > > b. which keywords? > > c. what is "the stateful configuration protocol"? > > d. if the answer to "c" is DHCPv6, should RFC 2462 more > > explicitly reference the configuration-only version > > of DHCPv6 in the description of the 'O'flag? > > > > Adam Machalek also pointed out some inconsistency about mandatory > > level of the stateful configuration protocol: > > > > http://www.atm.tut.fi/list-archive/ipng/msg04363.html > > > > - Whether a (not a host) router can autoconfigure itself > using RFC2462 > > (or bis) including > > if a router can configure a global address by stateless autoconf > > if a router can configure a link-local address in a way > described > > in RFC 2462 > > if a router can configure itself about "other" configuration > > information > > > > by several people, several times > > > > - If we need a 'not-yet-ready' status of an autoconfigured > address to > > help renumbering operation > > by Fred Baker, Apr 2003 > > http://www.atm.tut.fi/list-archive/ipng/msg09394.html > > > > - Avoiding interface failure upon DAD failure > > (mainly) by Jari Arkko, May 2003 > > related to mip6. (the latest draft leaves this as "ND > extensions") > > > > - If RFC2462 requires 64bit IFID > > by several people, several times. > > > > - Issues raised in the send requirement draft. > > (Sorry, I've not gone through the send requirement draft. > So there > > may or may not be issues from the draft that need to be > added here) > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 22:30:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00073 for ; Thu, 23 Oct 2003 22:30:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACriN-00063R-98 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 22:30:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O2UBRt023267 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 22:30:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACriN-00063C-4g for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 22:30:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00030 for ; Thu, 23 Oct 2003 22:29:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACriJ-0004Cf-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 22:30:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACriJ-0004Cc-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 22:30:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACriG-0005vh-8A; Thu, 23 Oct 2003 22:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrhf-0005rV-FD for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 22:29:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29958 for ; Thu, 23 Oct 2003 22:29:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACrhc-0004Bw-00 for ipv6@ietf.org; Thu, 23 Oct 2003 22:29:24 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1ACrhb-0004BB-00 for ipv6@ietf.org; Thu, 23 Oct 2003 22:29:23 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HN800D5BPK54T@mailout2.samsung.com> for ipv6@ietf.org; Fri, 24 Oct 2003 11:28:53 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HN800CCTPJOUI@mailout2.samsung.com> for ipv6@ietf.org; Fri, 24 Oct 2003 11:28:36 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HN8001LTPJO26@mmp2.samsung.com> for ipv6@ietf.org; Fri, 24 Oct 2003 11:28:36 +0900 (KST) Date: Fri, 24 Oct 2003 11:28:54 +0900 From: Soohong Daniel Park Subject: RE: I-D ACTION:draft-bykim-ipv6-hpd-00.txt In-reply-to: <02e501c3997f$12d2ff60$9402a8c0@consulintel.es> To: "'JORDI PALET MARTINEZ'" , ipv6@ietf.org Message-id: <01af01c399d6$91e26410$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hello Agreed with jordi's thought. It is a very valuable draft in the IPv6 WG. As far as the implementation is concerned, it was well done. Good job Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On > Behalf Of JORDI PALET MARTINEZ > Sent: Friday, October 24, 2003 1:03 AM > To: ipv6@ietf.org > Subject: Re: I-D ACTION:draft-bykim-ipv6-hpd-00.txt > > > Hi, > > I think this is a very interesting document. > > In fact, we have been working in something similar for some > time, but still not drafted it. > > Our case is a very good example, because we are working in a > project (www.6power.org) that deploys IPv6 PLC networks. In our case, > we may have different network configurations, with routers, > bridges (PLC repeaters) and CPEs. > > The idea is to configure the OSS system, in some cases in a > static way (with the subscriber parameters), some others automatically > (but keeping the security to avoid non registered users to > use the service). > > At this way, when the different devices are plugged into the > power network, there is no need to do ANY configuration at > the devices, > as they will learn (or "create") an adequate network > structure, all the way, until the CPE (that can be also a > router, of course). > > The idea is to extend the auto-configuration capabilities for > IPv6 to the complete network. Today we do an autoconfiguration at the > PLC level already. This could provide one very good reason to > deploy IPv6, specially in new networks, as will save a lot of > resources in the setup and operation/maintenance. > > I think is a very good example of the utility of this > document, and for sure we will be interested in cooperate on > it, and most > probably work on concrete implementations. > > Regards, > Jordi > > ----- Original Message ----- > From: > To: > Cc: > Sent: Thursday, October 23, 2003 11:32 PM > Subject: I-D ACTION:draft-bykim-ipv6-hpd-00.txt > > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > > > > Title : Hierarchical Prefix Delegation Protocol > > Author(s) : B. Kim, K. Lee, J. Park, H. Kim > > Filename : draft-bykim-ipv6-hpd-00.txt > > Pages : 12 > > Date : 2003-10-23 > > > > Stateless Autoconfiguration enables IPv6 hosts to send a > request for a prefix, a network identifier to a router on the subnet. > Using this ability a host can configure its IPv6 address. > Likewise, by defining a way to request for a prefix to an upper level > router, a router can get a prefix to be assigned to its subnet. > > > > This document describes a protocol for prefix delegation > between routers. It allows routers get prefixes from its upstream > routers, enabling the entire network and its belonging hosts > autoconfigure their own addresses. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-bykim-ipv6-hpd-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-bykim-ipv6-hpd-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-bykim-ipv6-hpd-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. > > > > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which may be > privileged or confidential. The information is intended to be > for the use of the individual(s) named above. If you are not > the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, > including attached files, is prohibited. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 23 23:44:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01433 for ; Thu, 23 Oct 2003 23:44:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACsrT-00083O-Ik for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 23:43:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O3hddY030947 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 23:43:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACsrT-000834-Ab for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 23:43:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01408 for ; Thu, 23 Oct 2003 23:43:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACsrR-0004iN-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 23:43:37 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACsrQ-0004iK-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 23:43:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACsqr-0007qy-Th; Thu, 23 Oct 2003 23:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACsqe-0007oA-Dk for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 23:42:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01389 for ; Thu, 23 Oct 2003 23:42:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACsqc-0004i2-00 for ipv6@ietf.org; Thu, 23 Oct 2003 23:42:46 -0400 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by ietf-mx with esmtp (Exim 4.12) id 1ACsqb-0004hy-00 for ipv6@ietf.org; Thu, 23 Oct 2003 23:42:45 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 9FBB611270; Thu, 23 Oct 2003 23:42:45 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 23 Oct 2003 23:42:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC 2461-new issue? Date: Thu, 23 Oct 2003 23:42:44 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0512212D@tayexc13.americas.cpqcorp.net> Thread-Topic: RFC 2461-new issue? Thread-Index: AcOZla7nxZAkyEDyT+ejkDrCHZO0TgAStgyA From: "Bound, Jim" To: , Cc: "Soliman Hesham" X-OriginalArrivalTime: 24 Oct 2003 03:42:45.0440 (UTC) FILETIME=[E2DD8C00:01C399E0] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable My view is we are updating 2461 to remain DS and not breaking any architectural components as that would require and appeal once a spec is at DS which this one is. So idea is to update the spec for clarification, correctness, or extensions. > Hi, > In section 4.2 of RFC 2461 regarding the RA message format=20 > the following=20 > is mentioned >=20 > Reserved A 6-bit unused field. It MUST be initialized to > zero by the sender and MUST be ignored by the > receiver. >=20 > The mobile-ipv6 draft draft-ietf-mobileip-ipv6-24.txt=20 > mandates using the=20 > most significant bit of this field as a home agent bit(will=20 > be set to 1 if=20 > the router is also a MIPv6 HA on this link). I do not know=20 > what is the=20 > best way to solve this apparent contradiction. I see the following=20 > possible solutions (in no particular order) >=20 > * Reduce the reserved field length in RFC2461bis to 5 bits This is the correct answer IMO. /jim > * Change the MUSTs to SHOULDs in RFC2461bis > * Put a note on RFC2461/RFC2461bis in the rfc-index saying it=20 > has been=20 > updated by the MIPv6 RFC(when it comes out) >=20 > Regards > Suresh >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 00:04:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02116 for ; Fri, 24 Oct 2003 00:04:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACtBL-0005dh-LB for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 00:04:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O44B9a021671 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 00:04:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACtBL-0005dS-EW for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 00:04:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02092 for ; Fri, 24 Oct 2003 00:04:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACtBJ-0004y6-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 00:04:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACtBI-0004y3-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 00:04:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACtBC-0005XU-Bn; Fri, 24 Oct 2003 00:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACtAn-0005L8-1U for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 00:03:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02060 for ; Fri, 24 Oct 2003 00:03:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACtAk-0004xS-00 for ipv6@ietf.org; Fri, 24 Oct 2003 00:03:34 -0400 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by ietf-mx with esmtp (Exim 4.12) id 1ACtAj-0004xL-00 for ipv6@ietf.org; Fri, 24 Oct 2003 00:03:33 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id C1D5713962; Fri, 24 Oct 2003 00:03:34 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 24 Oct 2003 00:03:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC 2461- issue list Date: Fri, 24 Oct 2003 00:03:34 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA17F@tayexc13.americas.cpqcorp.net> Thread-Topic: RFC 2461- issue list Thread-Index: AcOZFMeNBepTBBE9RaGL7QoagaJp3AAzG6Iw From: "Bound, Jim" To: "Soliman Hesham" , X-OriginalArrivalTime: 24 Oct 2003 04:03:34.0569 (UTC) FILETIME=[CB678190:01C399E3] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hesham, Comments on the issues-list. Below for initial input. My view is we should not add mobile requirements into the ND 2461 spec at all. Only if a specific field was changed like the reserved field mentioned where MIPv6 used 1 bit. My rationale for that is as follows: ND is a core spec for IPv6 deployment now for many years and the only deployed production IPv6 nodes are NOT Mobile nodes. Mobile IPv6, though I am huge supporter of MIPv6, has not been deployed in production, or any method to do DNS discovery, and we should strongly I state NOT add new untested and unproven features and extensions to a spec that is solid well tested and now widely deployed, because of Mobility. This is an error and invalid approach to adding Mobility to ND and Addrconf parts required for Mobility. I believe SEND also is only valid issue because of Mobility too. So I strongly do not support putting MIPv6 enhancements back into 2461. It will break testing, certification, for a technology that is not yet even in production, and will not be until base IPv6 is deployed which is in process. Here is an example. A user I work with has an IPv6 mandate and requires 2461 because it is DS and widely tested and debugged pretty well. MIPv6 is listed as emerging but not mandated. If we put MIPv6 parts into ND then we have put emerging into a core IPv6 spec. That is not a good standards or engineering strategy and definitely not a good implementation strategy for nodes that do not do mobility, and most nodes on the Internet today are not mobile and that is reality. For tomorrow we need to build additional specs for Mobility as we have done for MIPv6 and add to ND as required not change ND. This is not a good deployment or standards strategy. A good example is we circulated 3315 back to PS. That made it emerging per the user. They are correct but look what just happened. They now do not have a mandated addressing spec but an emerging one for the protocol they are deploying and preparing for production. This was not wise on the IETFs part or we have become incompetent and the market simply cannot trust our judgement here as an engineering organization? More comments in line below. > Issue 1: Mixed Host/Router behaviour > by Pekka Savola, May 2001 > http://www.wcug.wwu.edu/lists/ipng/200105/msg00068.html > Erik Nordmark made a comment that the text could be clearer: > http://www.wcug.wwu.edu/lists/ipng/200105/msg00077.html This is a clarity issue and fine for recycle. >=20 >=20 > Issue 2: Check against the case of preferred lifetime > valid lifetime > by jinmei, Dec 2002 > http://www.atm.tut.fi/list-archive/ipng/msg07250.html >=20 > This thread contained a possible updates on the=20 > router behavior of > sending router advertisements: > http://www.atm.tut.fi/list-archive/ipng/msg07402.html I don't agree with this issue nor the thread and we should not change router behavior for this but that is separate discussion. >=20 > Issue 3: On-link assumptions in 2461 considered harmful.=20 > This issue was raised by Alain and documented in: > draft-ietf-v6ops-onlinkassumption-00.txt > draft-ietf-v6ops-v6onbydefault-00.txt > Also see related issue in section 2.4 of:=20 > http://www.ctie.monash.edu.au/ipv6/draft-jinchoi-ipv6-cRA-00.txt This is nothing more than a note and should not be put into 2461. =20 >=20 > Issue 4: Advertisement lifetime issues raised by Pete Barany We can increase or decrease values or add extensions. =20 >=20 > Issue 5: Clarifying the use of the M and O flags > (raised by Rolf and others during V6ops meeting=20 > in San Francisco) Fine clarity edits. >=20 > Issue 6: The prefix length field in the prefix option > and its consistency with the fixed prefix size=20 > (64 bits) in RFC 3513.=20 This is old debate we can do it again I guess. > =20 >=20 > SEND issues: >=20 > Issue 7: All the security discussions (e.g. assuming that AH > or ESP can be added to the ND messages) will need to > be put in the context of SEND.=20 >=20 > Issue 8: Security considerations section needs to consider issues > in: draft-ietf-send-psreq-04 >=20 > Issue 9: The chicken and egg problem for ND security using IKE > as specified in:=20 > draft-arkko-icmpv6-ike-effects-02=20 >=20 > and manual SAs issues addressed in: > draft-arkko-manual-icmpv6-sas-02 ND with IPsec is secure. Mobile creates new attacks. SEND should do their own spec and add value to ND. ND should not be updated. I argue and question the entire notion of SEND all the time. Not going there again. It is simply not needed for non mobile environments. > =20 > MIP issues: >=20 > Issue 10: Reducing MIN_DELAY_BETWEEN_RAS from 3 seconds=20 > to 50 ms as specified in MIPv6 (many emails on the=20 > MIP mailing list in October and November 2002) >=20 > Issue 11: Eliminating the random delays required before sending > an RS when a mobile node does a handover to a new=20 > link. The random delay imposed by 2461 significantly > increases the movement detection time for mobile nodes >=20 > Issue 12: Eliminating the random delays required in 2461 when > a router sends a solicited RA. See : > draft-mkhalil-ipv6-fastra-04.txt >=20 > Issue 13: Impacts of the omission of a prefix option.=20 > section 2.2 in : > =20 > http://www.ctie.monash.edu.au/ipv6/draft-jinchoi-ipv6-cRA-00.t xt describes the impacts of omitting a prefix option from an RA on movement detection for mobile nodes. RFC 2461=20 does not require options to be present in every RA. >Issue 14: Link ids required to aid with movement detection. see: http://www.ietf.org/internet-drafts/draft-pentland-mobileip-linkid-00.tx t All MIP issues should be done in MIP, NEMO, and MIPSHOP et al. Not in ND for reasons I stated in the front of this email. >Finally, I recall (but not clearly) some discussions=20 >on the clarity of 2461 when it comes to multihomed hosts. But >I haven't managed to find the relevant thread(s) in the=20 >archive. So if you have an issue to add please let me know.=20 This is a very weak set of issues for anything but a recycle and MIP and SEND and DNS should be done as separate drafts. =20 /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 02:43:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18598 for ; Fri, 24 Oct 2003 02:43:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACvfc-0000Iy-HP for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 02:43:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O6haip001173 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 02:43:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACvfc-0000Ig-7F for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 02:43:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18572 for ; Fri, 24 Oct 2003 02:43:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACvfY-0006XW-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 02:43:32 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACvfX-0006XT-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 02:43:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACvf5-0000CS-LM; Fri, 24 Oct 2003 02:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACveL-000094-0G for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 02:42:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18555 for ; Fri, 24 Oct 2003 02:42:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACveH-0006XC-00 for ipv6@ietf.org; Fri, 24 Oct 2003 02:42:13 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACveG-0006Wn-00 for ipv6@ietf.org; Fri, 24 Oct 2003 02:42:12 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9O6fZ419931; Fri, 24 Oct 2003 09:41:36 +0300 Date: Fri, 24 Oct 2003 09:41:35 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: Soliman Hesham , Subject: RE: RFC 2461- issue list In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B047CA17F@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi, My initial thought is also that we should not make RFC 2461bis (or 2462bis) include every extension specified since 1998. Those can stay very well in separate drafts. Of course, we should still consider whether we want to enable the base spec to give more flexibility (e.g., the solicitation timers etc.) for those extensions. There is a clear distinction between these two, IMHO. Another thought: if we recycle RFC2461bis to DS, I think we should re-do the implementation reports if we changed the code (not sure whether new reports is _required_..). This may not be a bad thing, as the current implementation reports should (IMHO) be a bit more detailed than that.. However, there are some things which need addressing now. Inline about two IMHO important classes of issues.. On Fri, 24 Oct 2003, Bound, Jim wrote: [...] > > Issue 3: On-link assumptions in 2461 considered harmful. > > This issue was raised by Alain and documented in: > > draft-ietf-v6ops-onlinkassumption-00.txt > > draft-ietf-v6ops-v6onbydefault-00.txt > > Also see related issue in section 2.4 of: > > http://www.ctie.monash.edu.au/ipv6/draft-jinchoi-ipv6-cRA-00.txt > > This is nothing more than a note and should not be put into 2461. On the contrary, I believe this will of critical for the success of IPv6, and MUST BE dealt with. Whether the WG thinks it is just enough to explicitly state the tradeoffs here, or whether the spec needs to be changed is a different subject. > > SEND issues: > > > > Issue 7: All the security discussions (e.g. assuming that AH > > or ESP can be added to the ND messages) will need to > > be put in the context of SEND. > > > > Issue 8: Security considerations section needs to consider issues > > in: draft-ietf-send-psreq-04 > > > > Issue 9: The chicken and egg problem for ND security using IKE > > as specified in: > > draft-arkko-icmpv6-ike-effects-02 > > > > and manual SAs issues addressed in: > > draft-arkko-manual-icmpv6-sas-02 > > ND with IPsec is secure. Mobile creates new attacks. SEND should do > their own spec and add value to ND. ND should not be updated. I argue > and question the entire notion of SEND all the time. Not going there > again. It is simply not needed for non mobile environments. I think it may not have been clear what these issues imply. To me, it seems clear that we will not be creating a new "secure ND" out of RFC2461bis. However, now that we're identified the shortcomings of ND from the SEND work, we MUST include (some) discussion on these subjects in this spec. This may also result in some changes or optional toggles to make "plain ND" a bit more resistant to attacks, but that's not necessary as long as the issues are documented so the implementors and the users of ND are aware of them. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 02:47:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18702 for ; Fri, 24 Oct 2003 02:47:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACvj3-0000tc-J8 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 02:47:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O6l9jm003443 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 02:47:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACvj3-0000tS-4e for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 02:47:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18679 for ; Fri, 24 Oct 2003 02:46:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACviz-0006b2-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 02:47:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACviy-0006az-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 02:47:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACvix-0000mB-7e; Fri, 24 Oct 2003 02:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACvim-0000lM-8h for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 02:46:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18674 for ; Fri, 24 Oct 2003 02:46:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACvii-0006aq-00 for ipv6@ietf.org; Fri, 24 Oct 2003 02:46:48 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACvih-0006ad-00 for ipv6@ietf.org; Fri, 24 Oct 2003 02:46:47 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9O6k9x19975; Fri, 24 Oct 2003 09:46:09 +0300 Date: Fri, 24 Oct 2003 09:46:09 +0300 (EEST) From: Pekka Savola To: jspark cc: "'Myung-Ki Shin'" , Subject: RE: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses" In-Reply-To: <200310240150.h9O1ol5l005129@pec.etri.re.kr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Fri, 24 Oct 2003, jspark wrote: > Section 3 of our spec says: > ----------- > "Interface ID field is used to distinguish each host from others. And > this value is obtained from the IEEE EUI-64 based interface > identifier of the link-local unicast IPv6 address." > ----------- > > Our method uses only the EUI-64 based Interface ID, > derived from Link-local unicast address. > So, there is guarantee of uniqueness in our method. First, there is typically just one link-local address. Either it uses EUI-64 based IID or not. If it doesn't, you can't generate addresses like this. Second, the EUI-64 does not guarantee the uniqueness of the method. Otherwise we would not be needing DAD with addresses that are generated with EUI-64. But it is mandated by the specs. So these addresses are *not* truly, completely, totally, unique. > >If an SSM implementation checks for FF3x::/32 (as described in RFC 3306 > >section 6), > >and not for FF3x::/96 (as described in RFC 3306 section 7), but will not > >implement this specification, > >there will be lots of trouble. > > Of course, > I think a SSM implementation "MUST" check for FF3x::/96. This is certainly one interpretation. I'm not sure everybody has made the same. This should be brought to the attention of e.g. MBONED WG to see what kind of interpretations they have. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 05:54:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23118 for ; Fri, 24 Oct 2003 05:54:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACyeO-0007xd-S0 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 05:54:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O9sWvS030602 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 05:54:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACyeO-0007xV-J3 for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 05:54:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23091 for ; Fri, 24 Oct 2003 05:54:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACyeK-0000cm-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 05:54:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACyeK-0000ci-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 05:54:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACydu-0007l1-71; Fri, 24 Oct 2003 05:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACydI-0007eZ-In for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 05:53:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23059 for ; Fri, 24 Oct 2003 05:53:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACydE-0000cE-00 for ipv6@ietf.org; Fri, 24 Oct 2003 05:53:20 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ACydE-0000bz-00 for ipv6@ietf.org; Fri, 24 Oct 2003 05:53:20 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RDF0X>; Fri, 24 Oct 2003 05:52:48 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E13@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Nick 'Sharkey' Moore'" Cc: ipv6@ietf.org Subject: RE: RFC 2461- issue list Date: Fri, 24 Oct 2003 05:52:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , [moved this to ipv6 list] Nick, Thanks, I'll add this to the list. Hesham > -----Original Message----- > From: Nick 'Sharkey' Moore [mailto:sharkey@zoic.org] > Sent: Friday, October 24, 2003 3:28 AM > To: mobile-ip@sunroof.eng.sun.com > Cc: Soliman Hesham > Subject: Re: RFC 2461- issue list > > > On 2003-10-22, Soliman Hesham wrote: > > > > This is what I found initially. Please let us know if > > there are any issues that should be added to the list. > > G'day Hesham, > > I don't think this is on your list (cut-n-paste from > the opti-dad draft): > > | An NA with O=0,S=0 and no LLAO may [Note 1], however cause > | the NC entry to be set to STALE, causing NUD to be > | performed on the address. > | > | [Note 1] RFC 2461 is unclear on this, with [RFC2461 > 7.2.5] specifying > | "the advertisement prompts future Neighbour Unreachability > | Detection [...] by changing the state in the cache entry" > | whereas [RFC2461 Appendix C] specifies the state as > "unchanged". > | Many arguments have been made on the list (see > | ) | for one interpretation or the other. For the purposes of this | draft, I have assumed that either behaviour is possible. ... but maybe this should be clarified. cheers, -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 08:25:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27708 for ; Fri, 24 Oct 2003 08:25:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD0zy-00019B-QN for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 08:25:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OCOwnE004403 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 08:24:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD0zy-00018P-Gz for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 08:24:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27626 for ; Fri, 24 Oct 2003 08:24:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD0zx-0002UA-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 08:24:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD0zw-0002U7-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 08:24:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD0zC-0000j5-Rx; Fri, 24 Oct 2003 08:24:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD0WF-0001mn-3U for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 07:54:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26779 for ; Fri, 24 Oct 2003 07:54:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD0WE-00029i-00 for ipv6@ietf.org; Fri, 24 Oct 2003 07:54:14 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AD0WD-00029T-00 for ipv6@ietf.org; Fri, 24 Oct 2003 07:54:13 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RDGG4>; Fri, 24 Oct 2003 07:53:40 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E16@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Vijay Devarapalli'" Cc: ipv6@ietf.org Subject: RE: RFC 2461- issue list Date: Fri, 24 Oct 2003 07:53:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Vijay, thanks for raising this. A question below. > here is another issue. > > when a router includes a Prefix Information Option (section > 4.6.2 of RFC 2461) in the Router Advertisement, and if the > router has an address configured from that prefix, I suggest > including the router's address in the 'Prefix' field. not > just the prefix. the Prefix Length field will still indicate > the prefix length and hosts should be able to figure out > the prefix. > > we have had problems when two different interfaces of a > router use the same link local address. some host > implementations just check the source address and assume that > the current router is still reachable even when they move > between links attached to the two interfaces on the router. > > we came across this issue at Connectathon 2002. the following > URL has some discussion on it > > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue278.txt > > Mobile IPv6 already defines a Modified Prefix Information > option where the router's address is present in the prefix > field. I would like to see it in the Neighbor Discovery > specification itself. having the global unicast address in > the prefix field will help in movement detection. => This sounds like an issue that is currently solved by using the R bit specified in MIPv6, right? If so, and since this issue is specific to MNs, do you think it needs to be considered again in this work? In other words, is your suggestion that we add the support for the R bit in the revised spec? Hesham > > Soliman Hesham wrote: > > Folks, > > > > This is what I found initially. Please let us know if > > there are any issues that should be added to the list. > > > > Please note that some of these issues might not necessarily > > be addressed in this revision if they require non-backward > > compatible changes. The main requirement here is to be > > backward compatible with our changes. > > > > If you wish to express opinions, questions or suggestions > > please start a separate thread with the issue's header > > in the subject field. > > > > Thanks, > > Hesham > > > > Issue 1: Mixed Host/Router behaviour > > by Pekka Savola, May 2001 > > http://www.wcug.wwu.edu/lists/ipng/200105/msg00068.html > > Erik Nordmark made a comment that the text could > be clearer: > > http://www.wcug.wwu.edu/lists/ipng/200105/msg00077.html > > > > > > Issue 2: Check against the case of preferred lifetime > > valid lifetime > > by jinmei, Dec 2002 > > http://www.atm.tut.fi/list-archive/ipng/msg07250.html > > > > This thread contained a possible updates on the > router behavior of > > sending router advertisements: > > http://www.atm.tut.fi/list-archive/ipng/msg07402.html > > > > Issue 3: On-link assumptions in 2461 considered harmful. > > This issue was raised by Alain and documented in: > > draft-ietf-v6ops-onlinkassumption-00.txt > > draft-ietf-v6ops-v6onbydefault-00.txt > > Also see related issue in section 2.4 of: > > http://www.ctie.monash.edu.au/ipv6/draft-jinchoi-ipv6-cRA-00.txt > > > > Issue 4: Advertisement lifetime issues raised by Pete Barany > > > > Issue 5: Clarifying the use of the M and O flags > > (raised by Rolf and others during V6ops meeting > > in San Francisco) > > > > Issue 6: The prefix length field in the prefix option > > and its consistency with the fixed prefix size > > (64 bits) in RFC 3513. > > > > > > SEND issues: > > > > Issue 7: All the security discussions (e.g. assuming that AH > > or ESP can be added to the ND messages) will need to > > be put in the context of SEND. > > > > Issue 8: Security considerations section needs to consider issues > > in: draft-ietf-send-psreq-04 > > > > Issue 9: The chicken and egg problem for ND security using IKE > > as specified in: > > draft-arkko-icmpv6-ike-effects-02 > > > > and manual SAs issues addressed in: > > draft-arkko-manual-icmpv6-sas-02 > > > > MIP issues: > > > > Issue 10: Reducing MIN_DELAY_BETWEEN_RAS from 3 seconds > > to 50 ms as specified in MIPv6 (many emails on the > > MIP mailing list in October and November 2002) > > > > Issue 11: Eliminating the random delays required before sending > > an RS when a mobile node does a handover to a new > > link. The random delay imposed by 2461 significantly > > increases the movement detection time for mobile nodes > > > > Issue 12: Eliminating the random delays required in 2461 when > > a router sends a solicited RA. See : > > draft-mkhalil-ipv6-fastra-04.txt > > > > Issue 13: Impacts of the omission of a prefix option. > > section 2.2 in : > > http://www.ctie.monash.edu.au/ipv6/draft-jinchoi-ipv6-cRA-00.txt > describes the impacts of omitting a prefix option from > an RA on movement detection for mobile nodes. RFC 2461 > does not require options to be present in every RA. > > Issue 14: Link ids required to aid with movement detection. > see: > http://www.ietf.org/internet-drafts/draft-pentland-mobileip-linkid-00.txt > > Finally, I recall (but not clearly) some discussions > on the clarity of 2461 when it comes to multihomed hosts. But > I haven't managed to find the relevant thread(s) in the > archive. So if you have an issue to add please let me know. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 09:06:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28943 for ; Fri, 24 Oct 2003 09:06:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD1dv-0003qG-Eo for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 09:06:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OD6FUj014765 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 09:06:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD1dv-0003q4-81 for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 09:06:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28922 for ; Fri, 24 Oct 2003 09:06:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD1dt-00031v-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 09:06:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD1dt-00031s-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 09:06:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD1di-0003gM-30; Fri, 24 Oct 2003 09:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD1dU-0003cO-VX for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 09:05:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28908 for ; Fri, 24 Oct 2003 09:05:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD1dT-00031Z-00 for ipv6@ietf.org; Fri, 24 Oct 2003 09:05:47 -0400 Received: from sem.renater.fr ([193.49.159.3]) by ietf-mx with esmtp (Exim 4.12) id 1AD1dS-00031R-00 for ipv6@ietf.org; Fri, 24 Oct 2003 09:05:46 -0400 Received: from renater.fr (162.renater.fr [193.49.159.162]) by sem.renater.fr (8.11.6/8.11.0) with ESMTP id h9OD27U08790 for ; Fri, 24 Oct 2003 15:02:07 +0200 X-RAV-AntiVirus: This e-mail has been scanned for viruses on host: sem.renater.fr Message-ID: <3F99236C.8010303@renater.fr> Date: Fri, 24 Oct 2003 15:04:44 +0200 From: Jerome Durand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: FW: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses" References: <200310241110.h9OBAe5l008542@pec.etri.re.kr> In-Reply-To: <200310241110.h9OBAe5l008542@pec.etri.re.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi I don't get: 1=B0) The need for such link-local adresses. Maybe it should be=20 described in the document (saying you will not need any allocation=20 server or equivalent is not enough I think). What type of applications=20 you think will need these link-local adresses? 2=B0) Why to use the flag bit P for these adresses. This bit is alread= y=20 clearly defined in the RFC 3306. I don't see the interest in having an=20 exception for this RFC if scope <=3D 2. We already have a lot of=20 complexity for IPv6 multicast adresses and poor usage. I would prefer we = have one way to allocate the adresses and that people can implement it=20 easily. Could you please clarify these points ? Regards Jerome -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 09:21:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29367 for ; Fri, 24 Oct 2003 09:21:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD1sX-0007cG-To for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 09:21:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ODLL2K029270 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 09:21:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD1sX-0007c1-NC for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 09:21:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29281 for ; Fri, 24 Oct 2003 09:21:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD1sW-00039x-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 09:21:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD1sV-00039u-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 09:21:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD1sE-0007N6-73; Fri, 24 Oct 2003 09:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD1s5-0007LU-0D for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 09:20:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29269 for ; Fri, 24 Oct 2003 09:20:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD1s3-00039S-00 for ipv6@ietf.org; Fri, 24 Oct 2003 09:20:51 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD1s2-000391-00 for ipv6@ietf.org; Fri, 24 Oct 2003 09:20:50 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9ODK9H24970; Fri, 24 Oct 2003 16:20:09 +0300 Date: Fri, 24 Oct 2003 16:20:08 +0300 (EEST) From: Pekka Savola To: jspark cc: ipv6@ietf.org Subject: Re: FW: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses" In-Reply-To: <200310241110.h9OBAe5l008542@pec.etri.re.kr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Fri, 24 Oct 2003, jspark wrote: > > But it is mandated by the specs. So > > these addresses are > > *not* truly, completely, totally, unique. > > In our spec. > The uniqueness of LL unicast address is verified by DAD procedure. > And then, EUI-64 IID (or other) is extracted from LL Unicast address. > > Therefore, > our method supposes that LL unicast address should be verified by DAD > procedure. Yes. But the DAD procedure confirmed that the link-local address was unique (at that point). That does not guarantee that the _EUI-64_ part of it is unique -- the mechanism is not using the whole link-local address here! No amount of DAD with LL unicast addresses is going to change this :-) This is mostly just a theoretical discussion, but the real point is -- there is no need to _specify_, using _standards action_ a deterministic mapping for the link-local multicast addresses. Just invent one and be done with it.. :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 11:09:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07573 for ; Fri, 24 Oct 2003 11:09:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3Yo-0006zd-26 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 11:09:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OF91wM026674 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 11:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3Yh-0006vQ-IK for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 11:08:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07536 for ; Fri, 24 Oct 2003 11:08:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD3Ye-00053J-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 11:08:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD3Ye-00053G-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 11:08:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3Wr-0006GE-Ah; Fri, 24 Oct 2003 11:07:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3WH-0005uu-Fl for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 11:06:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07094 for ; Fri, 24 Oct 2003 11:06:16 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD3WE-0004vc-00 for ipv6@ietf.org; Fri, 24 Oct 2003 11:06:26 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AD3WD-0004vP-00 for ipv6@ietf.org; Fri, 24 Oct 2003 11:06:25 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9OF6OI20517 for ; Fri, 24 Oct 2003 18:06:24 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 24 Oct 2003 18:06:23 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 24 Oct 2003 18:06:23 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 24 Oct 2003 18:06:23 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: Review of draft-ietf-ipv6-node-requirements-05.txt Date: Fri, 24 Oct 2003 18:06:23 +0300 Message-ID: Thread-Topic: Review of draft-ietf-ipv6-node-requirements-05.txt Thread-Index: AcOOXoD26kDRh7orSpaIfsXrJAmtFQAsWNRQ To: , X-OriginalArrivalTime: 24 Oct 2003 15:06:23.0772 (UTC) FILETIME=[63B24DC0:01C39A40] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Chirayu, > > All nodes need to be able to terminate packets. All nodes may be = able > > to route packets. >=20 > The capability of being a final destination includes support for = sending > NS, RS messages etc (basically being a host). If all nodes MUST = support > the capability of being a final destination, then they (all nodes) = must > be able to behave as hosts. Thus the requirement is that all routers > should be able to behave as hosts. =20 >=20 > Is my interpretation correct? > > > Currently, this section does not discuss routin- > > > specific requirements. > >=20 > > Do you have text, I am not sure what you are expecting. >=20 > I wanted to know the meaning of "routing specific" requirements. Does = it > mean - the types of routing protocols that the routers must support? More-or-less, yes. =20 > > The wg could come to no consensus on what to put here. It is = partially > > implementation specific; partly deployment specific. >=20 > Hmm.. Is there an example of atleast one application that does not = work > with RFC 3041 addresses? There has been much discussion on this, you probably might like to see the archives, for blow-by-blow details. FTP will have problems with = 3041 addresses, for example. There has been discussion of 3041-bis being needed. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 11:16:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08079 for ; Fri, 24 Oct 2003 11:16:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3fc-0000IF-My for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 11:16:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OFG8Nl001106 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 11:16:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3fc-0000Fi-Ai for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 11:16:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08037 for ; Fri, 24 Oct 2003 11:15:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD3fb-0005Ef-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 11:16:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD3fa-0005Ec-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 11:16:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3fW-00008x-Oo; Fri, 24 Oct 2003 11:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3b9-0007VE-3u for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 11:11:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07684 for ; Fri, 24 Oct 2003 11:11:18 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD3b6-00056B-00 for ipv6@ietf.org; Fri, 24 Oct 2003 11:11:28 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AD3b5-000568-00 for ipv6@ietf.org; Fri, 24 Oct 2003 11:11:27 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9OFBPI25659 for ; Fri, 24 Oct 2003 18:11:25 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 24 Oct 2003 18:11:25 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 24 Oct 2003 18:11:25 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 24 Oct 2003 18:11:25 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 X-OriginalArrivalTime: 24 Oct 2003 15:06:19.0937 (UTC) FILETIME=[61692110:01C39A40] Subject: RE: Review of draft-ietf-ipv6-node-requirements-05.txt Date: Fri, 24 Oct 2003 18:11:25 +0300 Message-ID: Thread-Topic: Review of draft-ietf-ipv6-node-requirements-05.txt Thread-Index: AcNwnGGOxqGPdrPMRoKnfXbgo8CBDgdfUOqAArFe1JAATiWdAA== To: Cc: Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Dave, thanks for the comments! John > -----Original Message----- > From: ext Dave Thaler [mailto:dthaler@windows.microsoft.com] > Sent: 23 October, 2003 00:06 > To: Loughney John (NRC/Helsinki) > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Review of draft-ietf-ipv6-node-requirements-05.txt >=20 >=20 > The following issue was just brought to my attention today: > > Duplicate Address Detection MUST be supported (RFC2462 section 5.4 > > specifies DAD MUST take place on all unicast addresses). >=20 > DAD is not defined on NBMA links (e.g. 6to4). > RFC 2461 already allows for restricting some requirements to > non-NBMA links in the text already quoted. >=20 > So if you had a device which only supported NBMA links for which > DAD is not done, we're currently saying it has to have DAD code > that can never be used. >=20 > I'd propose the simple clarification: > Duplicate Address Detection MUST be supported on all links > supporting link-layer multicast (RFC2462 section 5.4 > specifies DAD MUST take place on all unicast addresses). >=20 > Also typo: > > router, Redirect functionionality MUST be supported. > ^^^^^^^^^^^^^^^^ > -Dave >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 12:35:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15712 for ; Fri, 24 Oct 2003 12:35:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD4uC-00089O-9A for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 12:35:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OGZGSt031324 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 12:35:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD4uB-000899-VU for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 12:35:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15649 for ; Fri, 24 Oct 2003 12:35:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD4uA-00007A-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 12:35:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD4u9-000075-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 12:35:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD4t0-0007sc-6S; Fri, 24 Oct 2003 12:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD4sr-0007qr-0O for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 12:33:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15457 for ; Fri, 24 Oct 2003 12:33:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD4sp-00003V-00 for ipv6@ietf.org; Fri, 24 Oct 2003 12:33:51 -0400 Received: from [195.167.170.152] (helo=bowl.fysh.org ident=mail) by ietf-mx with esmtp (Exim 4.12) id 1AD4so-00002p-00 for ipv6@ietf.org; Fri, 24 Oct 2003 12:33:50 -0400 Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 1AD4se-0008Uj-00 for ; Fri, 24 Oct 2003 17:33:40 +0100 Date: Fri, 24 Oct 2003 17:33:40 +0100 To: ipv6@ietf.org Subject: Re: I-D ACTION:draft-main-ipaddr-text-rep-01.txt Message-ID: <20031024163339.GC26187@fysh.org> References: <200310241444.KAA04152@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310241444.KAA04152@ietf.org> User-Agent: Mutt/1.3.28i From: Zefram Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Internet-Drafts@ietf.org wrote: > Title : Textual Representation of IPv4 and IPv6 Addresses > Author(s) : A. Main > Filename : draft-main-ipaddr-text-rep-01.txt > Pages : 12 > Date : 2003-10-23 ... >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-main-ipaddr-text-rep-01.txt I've not been able to work on this for most of the last six months due to personal problems, but I've finally got round to handling the comments from the first draft and I'm in full working order again. It was pointed out that this ought to be standards-track, and I've labelled this draft accordingly. Does this need to be adopted as a WG draft in order to be published on the standards track? I'm not clear on the procedure here. If there's any non-trivial decision to be made about the relation between the WG and this draft then it could probably be decided quickly in Minneapolis. (I won't be in Minneapolis, btw -- I'm not going to the US under the present regime.) -zefram -- Andrew Main (Zefram) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 13:06:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18204 for ; Fri, 24 Oct 2003 13:06:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5OH-0005li-BP for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 13:06:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OH6LCs022173 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 13:06:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5OH-0005lY-7F for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 13:06:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18155 for ; Fri, 24 Oct 2003 13:06:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD5OF-0000yd-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 13:06:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD5OF-0000ya-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 13:06:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5Nz-0005dn-BJ; Fri, 24 Oct 2003 13:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5NU-0005as-3X for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 13:05:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18084 for ; Fri, 24 Oct 2003 13:05:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD5NR-0000x1-00 for ipv6@ietf.org; Fri, 24 Oct 2003 13:05:29 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AD5NQ-0000vr-00 for ipv6@ietf.org; Fri, 24 Oct 2003 13:05:29 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9OH4uW04171 for ; Fri, 24 Oct 2003 10:04:56 -0700 X-mProtect: <200310241704> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVJ92ok; Fri, 24 Oct 2003 10:04:55 PDT Message-ID: <3F995CDB.2080406@iprg.nokia.com> Date: Fri, 24 Oct 2003 10:09:47 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: draft-hain-templin-ipv6-localcomm-03.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, A new version of the 'hain/templin' draft is now available (see below). This version obsoletes the previous document named: "Goals for an Addressing Scheme to Support Local Communications within Sites" draft-hain-templin-ipv6-limitedrange-02.txt Fred ftemplin@iprg.nokia.com >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Goals for Local Communications within Sites > Author(s) : T. Hain, F. Templin > Filename : draft-hain-templin-ipv6-localcomm-03.txt > Pages : 15 > Date : 2003-10-23 > >The IPv6 addressing architecture specifies global and local-use >unicast addressing schemes, but provides no operational guidelines >for their use. There is a perceived need for an addressing scheme >that supports local communications within sites. Of special interest >are 'active sites', e.g., sites that are intermittently-connected or >disconnected from the global Internet, sites that frequently change >provider points of attachment, sites that temporarily or permanently >merge with other sites, multi-homed sites, etc. This memo will >discuss goals for an addressing scheme to support local >communications within sites. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-hain-templin-ipv6-localcomm-03.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-hain-templin-ipv6-localcomm-03.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-hain-templin-ipv6-localcomm-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 13:16:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18673 for ; Fri, 24 Oct 2003 13:16:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5Xj-0008C9-M3 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 13:16:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OHG7TO031495 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 13:16:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5Xj-0008Bu-Gc for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 13:16:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18628 for ; Fri, 24 Oct 2003 13:15:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD5Xh-00019a-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 13:16:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD5Xh-00019X-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 13:16:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5Xe-00087C-33; Fri, 24 Oct 2003 13:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5XK-00084O-FR for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 13:15:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18609 for ; Fri, 24 Oct 2003 13:15:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD5XI-000193-00 for ipv6@ietf.org; Fri, 24 Oct 2003 13:15:40 -0400 Received: from oak.cats.ohiou.edu ([132.235.8.44] helo=oak2a.cats.ohiou.edu) by ietf-mx with esmtp (Exim 4.12) id 1AD5XH-000190-00 for ipv6@ietf.org; Fri, 24 Oct 2003 13:15:39 -0400 Received: from 132.235.74.101 by pm2 (PureMessage); Fri Oct 24 12:13:53 2003 Received: from dhcp-074-101.cns.ohiou.edu (dhcp-074-101.cns.ohiou.edu [132.235.74.101]) (authenticated bits=0) by oak1a.cats.ohiou.edu (8.12.8-OU/8.12.8-OU) with ESMTP id h9OGDoOw743221 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 24 Oct 2003 12:13:51 -0400 (EDT) Date: Fri, 24 Oct 2003 12:14:09 -0400 From: Hans Kruse To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Message-ID: <2147483647.1066997649@dhcp-074-101.cns.ohiou.edu> In-Reply-To: <5.1.0.14.2.20031023182433.00b4ec48@kahuna.telstra.net> References: <5.1.0.14.2.20031023182433.00b4ec48@kahuna.telstra.net> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-PMX-Spam: Gauge=IIIII, Probability=5%, Report='IN_REP_TO, REFERENCES, __CD, __CT, __CTE, __CT_TEXT_PLAIN, __EVITE_CTYPE, __HAS_MSGID, __HAS_X_MAILER, __IN_REP_TO, __MIME_VERSION, __REFERENCES, __SANE_MSGID, __UNUSABLE_MSGID' X-MailScanner-SpamCheck: not spam, PureMessage (score=0, required 5) X-PMX-Information: http://www.cns.ohiou.edu/email/spam-virus.html X-PMX-Version: 4.0.4.77969 (pm2) X-PMX-Start: Fri Oct 24 12:13:52 2003 X-PMX-Stop: Fri Oct 24 12:13:53 2003 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Some notes on the draft as well as some of the comments on the list: 1. I think this draft is appropriately being prepared as Proposed Standard. Trying to side-line local addressing to Experimental is not in keeping with the declared consensus on work towards a "replacement for site-locals" (which after all are on the standards track now). Also, this document IMHO can be tweaked in pretty short order to qualify for Proposed Standard status. 2. Several folks stumbled over the wording (in section 1.0) that "applications may treat these address[sic] like global scoped addresses". How about: "Applications may treat these addresses like global scoped addresses; such applications will function correctly within the reach of the local addresses. Sites using a mixture of Globally Routable and Local addresses may experience sub-optimal application behaviour, see sections 8.0-10.0 for further discussion". If that sounds better I am willing to volunteer wording/edits to tighten up those sections (regarding applications in mixed environments). 3. Section 9.0 regarding DHCP6; suggest: "In order for hosts to autoconfigure Local IPv6 addresses, routers have to be configured to advertise Local IPv6 /64 prefixes in router advertisements, or DHCP6 must have been configured to assign them." 4. Regarding DNS; there were some comments regarding RFC1918-style lookups. I assume the concern was regarding reverse lookups (the 1918 root server load issue). However, the Local addresses in this draft are unique (FC00::/8) or nearly unique (FD00::/8). As such there is really no reason not to allow reverse lookups for FC00::/8 in the global DNS. Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 fax -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 13:19:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18847 for ; Fri, 24 Oct 2003 13:19:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5ak-0000XL-SR for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 13:19:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OHJENd002057 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 13:19:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5ak-0000X6-Gy for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 13:19:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18798 for ; Fri, 24 Oct 2003 13:19:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD5ai-0001DH-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 13:19:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD5ah-0001DE-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 13:19:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5aX-0000M8-Cv; Fri, 24 Oct 2003 13:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5aB-0000Hx-PL for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 13:18:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18765 for ; Fri, 24 Oct 2003 13:18:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD5a9-0001Cf-00 for ipv6@ietf.org; Fri, 24 Oct 2003 13:18:37 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AD5a9-0001CR-00 for ipv6@ietf.org; Fri, 24 Oct 2003 13:18:37 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9OHI3C13719; Fri, 24 Oct 2003 10:18:03 -0700 X-mProtect: <200310241718> Nokia Silicon Valley Messaging Protection Received: from danira-pool05289.americas.nokia.com (10.241.52.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd678bqj; Fri, 24 Oct 2003 10:18:02 PDT Message-ID: <3F995EBB.7010400@iprg.nokia.com> Date: Fri, 24 Oct 2003 10:17:47 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: ipv6@ietf.org Subject: Re: RFC 2461- issue list References: <748C6D0A58C0F94CA63C198B6674697A01922E16@ftmail.lab.flarion.com> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922E16@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > > > > when a router includes a Prefix Information Option (section > > 4.6.2 of RFC 2461) in the Router Advertisement, and if the > > router has an address configured from that prefix, I suggest > > including the router's address in the 'Prefix' field. not > > just the prefix. the Prefix Length field will still indicate > > the prefix length and hosts should be able to figure out > > the prefix. > > > > we have had problems when two different interfaces of a > > router use the same link local address. some host > > implementations just check the source address and assume that > > the current router is still reachable even when they move > > between links attached to the two interfaces on the router. > > > > we came across this issue at Connectathon 2002. the following > > URL has some discussion on it > > > > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue278.txt > > > > Mobile IPv6 already defines a Modified Prefix Information > > option where the router's address is present in the prefix > > field. I would like to see it in the Neighbor Discovery > > specification itself. having the global unicast address in > > the prefix field will help in movement detection. > > => This sounds like an issue that is currently solved > by using the R bit specified in MIPv6, right? > If so, and since this issue is specific to MNs, do you > think it needs to be considered again in this work? > In other words, is your suggestion that we add the support > for the R bit in the revised spec? no R bit. always include the global address configured from the prefix instead of just the prefix. the prefix can always be obtained using the prefix length field. it is probably more useful to mobile nodes. but not just MIPv6. it is useful whenever a node needs the global address of its access router. Vijay -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 13:47:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19947 for ; Fri, 24 Oct 2003 13:47:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD61I-0008Ed-Tb for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 13:46:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OHkecW031649 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 13:46:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD61I-0008Do-IR for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 13:46:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19910 for ; Fri, 24 Oct 2003 13:46:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD61G-0001bi-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 13:46:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD61F-0001bf-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 13:46:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD60g-0007wz-MA; Fri, 24 Oct 2003 13:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5zn-0007Ya-57 for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 13:45:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19780 for ; Fri, 24 Oct 2003 13:44:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD5zk-0001ZD-00 for ipv6@ietf.org; Fri, 24 Oct 2003 13:45:04 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AD5zj-0001YE-00 for ipv6@ietf.org; Fri, 24 Oct 2003 13:45:04 -0400 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h9OHiWV27896 for ; Fri, 24 Oct 2003 10:44:32 -0700 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h9OHkttX010454 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 24 Oct 2003 10:47:02 -0700 Message-ID: <3F9964D2.6030404@innovationslab.net> Date: Fri, 24 Oct 2003 13:43:46 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: RFC 2461- issue list References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Erik, The goal at this point is to recycle at DS. I have a query into the ADs as to whether or not we should consider moving it to Full Standard. Given that target, the primary goal is to clarify issues in the spec. I feel that including some additional definitions, such as the MIPv6 R bit, is reasonable. I do not want to see wholesale changes put in this spec from other specs. Anything added to the spec should not break backwards compatibility with existing implementations. This applies to the update to 2462 as well. Regards, Brian Erik Nordmark wrote: > I have a high-level question first; is the intent to do these updates > and recycle the document as a draft standard? > Or to try to move it to full standard? > > If recycle at draft is the goal, are there documents (such as MIPv6) > which contain extensions to the packet formats which should be folded > into the base ND spec at this point in time? > > In addition to the MIP issues in your list there is (at least) the > definition of the R bit in the prefix option, and the advertisement > interval option. > > Erik > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 14:28:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21720 for ; Fri, 24 Oct 2003 14:28:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD6fW-00024y-0P for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 14:28:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OISDPt007991 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 14:28:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD6fV-00024n-Qy for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 14:28:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21696 for ; Fri, 24 Oct 2003 14:28:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD6fT-0002DS-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 14:28:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD6fS-0002DP-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 14:28:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD6fK-0001zn-1G; Fri, 24 Oct 2003 14:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD6f4-0001xj-68 for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 14:27:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21684 for ; Fri, 24 Oct 2003 14:27:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD6f1-0002DE-00 for ipv6@ietf.org; Fri, 24 Oct 2003 14:27:43 -0400 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by ietf-mx with esmtp (Exim 4.12) id 1AD6f1-0002DB-00 for ipv6@ietf.org; Fri, 24 Oct 2003 14:27:43 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id DEE7211143 for ; Fri, 24 Oct 2003 14:27:42 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 24 Oct 2003 14:27:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: draft-syam-ipv6-state-model-00.txt Date: Fri, 24 Oct 2003 14:27:42 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05122174@tayexc13.americas.cpqcorp.net> Thread-Topic: draft-syam-ipv6-state-model-00.txt Thread-Index: AcOaXIXiBPRXwM2zR1yo1rG6P0xZ6Q== From: "Bound, Jim" To: X-OriginalArrivalTime: 24 Oct 2003 18:27:42.0647 (UTC) FILETIME=[83445C70:01C39A5C] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I have read this spec and don't see bugs at this point. Is this document to feed work on MIB definitions for SNMP and network management? Or just to describe as information the various states in the draft? /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 14:40:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22243 for ; Fri, 24 Oct 2003 14:40:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD6rD-00066g-5T for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 14:40:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OIeJDc023468 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 14:40:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD6rC-00066J-Mv for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 14:40:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22187 for ; Fri, 24 Oct 2003 14:40:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD6r9-0002MM-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 14:40:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD6r9-0002MJ-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 14:40:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD6qy-0005th-MF; Fri, 24 Oct 2003 14:40:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD6jV-0003UI-Cs for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 14:32:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21877 for ; Fri, 24 Oct 2003 14:32:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD6jS-0002Go-00 for ipv6@ietf.org; Fri, 24 Oct 2003 14:32:18 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AD6jS-0002Gl-00 for ipv6@ietf.org; Fri, 24 Oct 2003 14:32:18 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9OIWH5u014767 for ; Fri, 24 Oct 2003 12:32:17 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HN900029Y5TR1@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Fri, 24 Oct 2003 12:32:17 -0600 (MDT) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HN9005P5Y47I0@mail.sun.net> for ipv6@ietf.org; Fri, 24 Oct 2003 12:31:20 -0600 (MDT) Date: Fri, 24 Oct 2003 11:34:04 -0700 From: Alain Durand Subject: RFC 2460 issue In-reply-to: <3F9964D2.6030404@innovationslab.net> To: ipv6@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT I had this question yesterday and I couldn't find an answer in RFC2460: Is it valid for a host to send a packet with Hop Count set to zero? - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 16:01:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27046 for ; Fri, 24 Oct 2003 16:01:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD87S-0004Ov-VO for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 16:01:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OK1ASU016911 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 16:01:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD87S-0004Og-PX for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 16:01:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26990 for ; Fri, 24 Oct 2003 16:01:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD87R-0003W9-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 16:01:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD87Q-0003W6-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 16:01:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD86R-00048V-6g; Fri, 24 Oct 2003 16:00:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD85d-0003vh-2E for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 15:59:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26852 for ; Fri, 24 Oct 2003 15:59:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD85b-0003TX-00 for ipv6@ietf.org; Fri, 24 Oct 2003 15:59:15 -0400 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx with esmtp (Exim 4.12) id 1AD85Z-0003TO-00 for ipv6@ietf.org; Fri, 24 Oct 2003 15:59:13 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 3979BFD5F for ; Fri, 24 Oct 2003 15:59:12 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 24 Oct 2003 15:59:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: Review Input: draft-jinchoi-ipv6-cra-00.txt Date: Fri, 24 Oct 2003 15:59:10 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA18C@tayexc13.americas.cpqcorp.net> Thread-Topic: Review Input: draft-jinchoi-ipv6-cra-00.txt Thread-Index: AcOaaU1Z0uQ/HxdbRCOdulFU9eDG2g== From: "Bound, Jim" To: X-OriginalArrivalTime: 24 Oct 2003 19:59:11.0169 (UTC) FILETIME=[4AAE5B10:01C39A69] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Comments on this draft. I am unclear but it may be this work needs to be done in the mipshop WG within the Internet Area as I believe all that is required to resolve the problem statement in this draft is policy to use the current ND 2461 mechanisms and the extended ND mechanisms in MIPv6. As the WG may realize I do not support merging MIPv6 ND changes back into to RFC 2461 so do not see need for that. If this spec is to define and clarify the policy for use of the new prefix option in MIPv6 ND to set RA R bit then I suggest that discussion be in mipshop WG where that is their focus.=20 1. Introduction=20 =20 Movement detection (MD) is one of a series of stages in accomplishing MIPv6 handover. As defined in the MIPv6 specification [MIPv6],=20 detection of movement is accomplished through reception of Router=20 Advertisements (RAs) and Neighbor Advertisements (NAs), and=20 comparison of these messages with previously received router=20 information.=20 Layer 2 can also note movement detection and more reliable and faster today.=20 =20 To detect its movement, an MN should check the (partial) reachability of the current AR and the validity of the current IP address. For=20 these, the information in Router Advertisement is essential. But,=20 based on current definitions [RFC 2461], the information contained in an RA is inadequate for efficient MD due to inconsistency and=20 incompleteness.=20 I do not agree with this statement and believe all that is needed is in the current RAs for what this draft is requesting (2461 + MIPv6). In fact it has been implemented and running in early adopter environments right now with handhelds. =20 =20 2. The RA Information Issues=20 =20 In this chapter, we describe the problems we encountered while=20 working on Movement Detection and investigate the possible solutions. =20 =20 2.1 Link local scope of Router Address=20 =20 The router address contained in an RA message is link-local scope.=20 Neighbor Discovery [RFC 2461] only advertises a router's link-local=20 address, by requiring this address to be used as the IP Source=20 Address of each Router Advertisement. Hence its uniqueness can't be=20 guaranteed outside of a link-instance. =20 This is not true if the R bit is set then the full IP address is available and why it was put as option in MIPv6. But, for most nodes on a link the default is that routers do not need to supply the full IP address in RAs. But, there is a means and support to resolve this problem for Mobility. ALso MD today is based on Layer 1 and 2 information. When a MN changes its link it knows which RA is coming from which link I would postulate in implementation. =20 So if it happens that two different router interfaces have the same=20 link-local address, a host can't detect that it has moved from one=20 interface to another by checking the router address in RA messages. The above needs to state two different links. Routers are not compliant to IPv6 if they duplicate link-local addresses on the same link. =20 =20 On the other hand, a host can't be sure that its current default=20 router is reachable, even when it can communicate with the router,=20 which has the same address as its current router address. That router may be a different one, which, though highly unlikely, happens to=20 have the same link-local address as its current default router.=20 Unclear what the above is trying to convey? If the host can communicate with a router on its link it is reachable? If draft is speaking of a MN the draft needs to say MN not just host, and that specifically if the link-local address of the router on the new link for the MN is the same then correct the MN would not know. But, then these two routers are being used for MIPv6 and should be using the RA ND extension per MIPv6 R bit. Problem solved. =20 Heuristically, a host can use link-layer addresses in Neighbor cache. After link change, if the router address and link-layer address in=20 Neighbor Cache has not changed, i.e. a host can still communicate=20 with those addresses, it's reasonable for the host to assume that=20 current default router is still reachable. =20 This is a good point the link-layer address is not the same as the link-local address and we might want to note that a change in an RA of the link-layer address could also be used for MD and we should at least discuss this maybe in mipshop. But that could be duplicated too. But it is a "hint". =20 Reception of a Router Advertisement with the same on-link global=20 prefix (L=3D1) from the same router's link-local, may be considered = an=20 authoritative indication that the router is still reachable.=20 This is not possible in IPv6. Compliant routers cannot duplicate IPv6 prefixes across multiple links which is why the R bit works. I assume draft is speaking again about the MN moving to a new link and the draft saying because the prefixes are the same that is a problem. That is what is not possible in a compliant IPv6 2461 network. =20 Or a router can advertise its global address, by using Router Address (R) bit in the Prefix Information option. When set, R bit indicates=20 that the Prefix field contains a complete IP address assigned to the=20 sending router. With the RA with R bit set, a node can check whether=20 it can still hear from its current default router.=20 Correct and my point above. =20 =20 2.2 Omission of Prefix Information=20 =20 To check the validity of its IP address, a host should see whether=20 the prefix of its IP address is advertised on the link to which it is currently attached.=20 Well in so many words that is true but there are implementation optimizations to avoid that check on every packet transmission as a note :--)=20 =20 For this, a host checks whether the prefix of its IP address is in=20 the Prefix Information Option of Router Advertisement messages. But=20 an unsolicited Router Advertisement message can omit some prefixes=20 for convenience, for example to save the bandwidth. =20 Then that network will suffer and if the nodes require those prefixes it is not an ommission of 2461 but bad network configuration and planning by the user. =20 So, checking the prefixes in an RA, an MN may make false assumption=20 that the prefix of its current IP address is not supported in a new=20 link, while that prefix is just omitted in that particular RA.=20 But this is not the fault of 2461 and the R bit works when used and routers supporting MNs into its network should use the R bit. There is no problem. =20 Moreover, even though a RA message contains all the Prefix=20 Information Options, a host has no way to know it. There is no=20 indication.=20 Why? Sure they do?=20 =20 Hence, a host can't be sure that the prefix of its current IP address is not supported on the current link, even though the prefix is not=20 contained in an RA message.=20 There are clear administration rules for MN support for ND and MIPv6 Extensions to ND. The problem is do we not feel MIPv6 documented these well enough or not? =20 The problem is 1) an RA may omit some Prefix Information Options and=20 2) even it has all the Prefix Information Options, there is no=20 indication that it does.=20 I cannot parse the conclusion for 2) at all? =20 The possible solution for the above is the RA with =20 1) All the Prefix Information Options and =20 2) The indication that it contains all the Prefix Information=20 Options. =20 Both are administrative statements that can be made and suggested for routers that support MN movement and thus why I feel this work should be moved to mipshop and create a BCP to define the administration and use of the new MIPv6 ND extensions. But we need not add any more bits or explanation to 2461. =20 For 2), we may define a new bit in an RA message. We will give more=20 detail in 3.1.=20 This is not necessary and has been resolved by MIPv6.=20 =20 =20 2.3 Lack of Solicitation Acknowledgement =20 =20 In Router Advertisement messages, there is no solicitation bit, as in Neighbor Advertisement. So when a node receives a RA, it can's be=20 sure it's the reply to its Router Solicitation. To confirm bi- directional reachability, an additional NS/ NA exchange is mandatory. Do not agree. When a node gets an RA it then begins communication. If that communications fails then the router is down and must be retried or must locate another router. The IPv6 architecture did not implement such reacability with routers for a good reason and that is to support reduced discovery messages and bandwidth on an IPv6 link. =20 =20 It may useful to assign S bit, in the case where we want nodes to be=20 able to determine that they have received a solicited router=20 advertisement. With S bit, a node can confirm reachability with only=20 RS/ RA exchange.=20 Same comment as above. =20 =20 2.4 Ambiguity of On-link information (L-bit) =20 =20 Currently confusion is caused by the attempt to overload on-link=20 prefixes to mean some form of "link identifier".=20 This is interpretation and we should make sure it is clear I think it is very clear and have implemented this code and shipped a product. So I am really interested what is not clear. =20 According to RFC 2461, on-link prefix means that this prefix can be=20 used for on-link determination. A node can send packets directly to=20 an address that falls in the on-link prefix without going through=20 default routers. Any two nodes with the addresses having the same on- link prefix can communicate each other at the link layer. Just states a router is not needed and like prefixes are on link. Router is not required. =20 Also RFC 2461 allows the links without on-link prefixes, where all=20 packets would be sent to a default router. Thus as RFC 2461 is=20 designed, it is problematic for the on-link prefixes to be a link=20 identifier.=20 This logic is not valid. The premise does not support the conclusion. When a link prefix is advertised all that is stated is that a node can use this prefix for onlink determination. Because an administrator does not configure is the problem not ND 2461. =20 Reception of an RA with the L bit set to zero does not make any=20 claims about the reachability of hosts on the current link. One of=20 the implications of the unset L bit is that the subnet may be=20 available through multiple interfaces on the same router, or through=20 multiple routers on different links. =20 =20 One problem with RA message reception where the currently configured=20 prefix is L=3D0, is that it is impossible to distinguish between RAs=20 received from routers on different links, and L=3D0 Prefix=20 advertisements received from a different routers on the same link=20 link-local address on the same subnet, until bidirectional=20 reachability checks have been performed with the current router.=20 This was and is not the purpose of the L bit set. The above is not necessary for this discussion or I am missing the point. =20 According to [RFC 2461], a router may advertise prefixes with L=3D0 = and A=3D1. This implies that stateless address autoconfiguration is = allowed for these prefixes [RFC 2462]. It is possible to show that in the=20 absence of Address State on routers or ND proxying, duplicate=20 addresses may be configured for a global address, when an address=20 owner exists on another link of the same subnet. This is point the draft missed early on. Routers cannot provide same prefixes to two separate links.=20 =20 Even if address state (using DHC or otherwise) is maintained on a=20 router, no current specification requires that hosts re-DAD global=20 addresses while they remain within the subnet, even if routers change. =20 This means that if a mobile host moves to another link within an IP=20 subnet (with L=3D0), the router may be unaware that the host has = moved, and have inaccurate information about which link the hosts are on. =20 It is not the job of the router to know what link a host is on. =20 =20 3. RA Optimized for Movement Detection=20 =20 Our goal is to design an RA in such a way that an MN can detect its=20 movement efficiently, quickly and precisely with as little signaling=20 as possible. As described above, the information contained in a=20 current RA message is inconsistent and incomplete for movement=20 detection. The following proposals seek to facilitate efficient=20 movement detection by including all the necessary information in an=20 RA message.=20 There is no reason for this design and the problem has been solved by MIPv6. =20 =20 3.1 Complete RA =20 =20 Since routers may neglect to send all prefixes in every advertisement,=20 it is difficult for an MN to determine whether it is attached to a=20 different subnet, when an RA received without its currently=20 configured prefix.=20 =20 Even though an RA contains all the Prefixes, an MN has no way to know it. There is no indication. So still ambiguity remains. =20 =20 Sure it does if the R bit is set for a router or L bit for host notification. =20 If a router is able to send an indication that the RA it sends=20 contains all of the valid prefixes for a link-instance, then=20 reception of an RA which contains a different set of prefixes=20 indicates the presence of a different subnet. =20 This is to much overhead and the R bit already does this far better and why MIPv6 WG converged on the support of this new prefix option and why the IPv6 WG supported the change. This draft is trying to reinvent that solution and it is not necessary. =20 Moreover if an RA contains all the other options, for example link- layer address option, it will speed up movement detection.=20 And that can be done per ND today. =20 We propose to assign a new bit (Complete bit) in RA message to=20 indicate its completeness. When Complete bit is set, it means the RA=20 contains all the options (including all the Prefix Information=20 Options).=20 This is non needed state in implementations and adds no value over what exists currently. =20 For efficient Movement Detection, we propose a RA with =20 1) AR's global IP address using R bit =20 2) All the options (including all the Prefix Information Options)=20 3) The indication that it has all the options (Complete bit)=20 4) S bit (Solicitation bit) to confirm reachability without NS/ NA=20 exchange=20 I don't agree with the reachability suggestion but all the others exist today and what is needed is to define a policy when all this must execute. =20 thanks /jim =20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 17:49:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01634 for ; Fri, 24 Oct 2003 17:49:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD9nu-0002q6-Av for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 17:49:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OLn6DZ010911 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 17:49:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD9nu-0002pu-1F for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 17:49:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01610 for ; Fri, 24 Oct 2003 17:48:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD9nr-00054d-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 17:49:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD9nr-00054a-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 17:49:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD9ms-0002Xy-JS; Fri, 24 Oct 2003 17:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD9lt-0002SB-Us for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 17:47:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01571 for ; Fri, 24 Oct 2003 17:46:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD9lr-00053J-00 for ipv6@ietf.org; Fri, 24 Oct 2003 17:46:59 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AD9lq-00052c-00 for ipv6@ietf.org; Fri, 24 Oct 2003 17:46:58 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9OLk7T26830; Fri, 24 Oct 2003 14:46:07 -0700 X-mProtect: <200310242146> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdI4yzl5; Fri, 24 Oct 2003 14:46:05 PDT Message-ID: <3F999EC3.8020508@iprg.nokia.com> Date: Fri, 24 Oct 2003 14:50:59 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: iljitsch@muada.com, ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: MTU handling References: <20031023071311.E8E569A@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Itojun, I disagree with your statement. Two examples where the per-neighbor MTU negotiation would be very useful: 1) Peer-to-peer wireless (e.g. IEEE 802.11): On certain wireless media, receiver A can sense QoS metrics (e.g. SNR) for the packets it receives from senders B and C. If the SNR for B is strong, A may wish to inform B that a larger MTU (e.g. 1500 bytes) is acceptable. Conversely, if the SNR for C is weak, A may wish to inform C that a smaller MTU (e.g. 1300 bytes) is desired. 2) Constrained nodes on large links: On large-MTU media (e.g., HiPPI, Gig-E, etc.), nodes with small receive buffers (e.g. boot ROMs, embedded devices) may wish to receive smaller packets than the MTU for the link. For example, a constrained node on a link with MTU of 64KB may wish to inform a neighbor that an MTU of 10KB is desired. Fred ftemplin@iprg.nokia.com Jun-ichiro itojun Hagino wrote: >>I'm not sure this should go into a replacement specification for RFC >>2461, but I'll bring it up anyway: >> >>Currently, routers can advertise an MTU for a link. That's nice. But >>what we really need is a way for hosts to find out the MTU each >>individual neighbor can handle. 100 Mbps and slower ethernet interfaces >>can typically handle only the standard 1500 byte ethernet MTU, while >>gigabit ethernet interfaces usually support a much larger MTU. >> >>However, in most cases hosts with different MTUs are present on the >>same subnet, so simply advertising a larger MTU wouldn't solve this. >>(Not that this would work anyway as hosts are instructed to only listen >>to MTU advertisements where the MTU is between 1280 and 1500 (for >>ethernet).) >> >>But if hosts can tell each other the MTU they support, each set of two >>hosts is always able to use the largest possible MTU between them. >>(This would also require a new link MTU option that conveys the maximum >>MTU the lower layer equipment supports. Switches have their own MTU and >>even some hubs start doing strange things when a larger than expected >>MTU is used.) >> >> > > the assumption made in RFC2461 is that the link MTU is constant > over the link, i guess. i don't think it is necessary to make > MTU negotiable between peers, it would complicate too many things. > >itojun > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 17:55:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01900 for ; Fri, 24 Oct 2003 17:55:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD9tL-0004N6-8N for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 17:54:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OLshaV016798 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 17:54:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD9tL-0004Mr-3S for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 17:54:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01822 for ; Fri, 24 Oct 2003 17:54:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD9tI-00059R-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 17:54:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD9tI-00059L-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 17:54:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD9sh-0003wN-JK; Fri, 24 Oct 2003 17:54:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD9sb-0003v3-GR for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 17:53:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01773 for ; Fri, 24 Oct 2003 17:53:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD9sY-000582-00 for ipv6@ietf.org; Fri, 24 Oct 2003 17:53:54 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AD9sY-00057L-00 for ipv6@ietf.org; Fri, 24 Oct 2003 17:53:54 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9OLr7h32313; Fri, 24 Oct 2003 14:53:07 -0700 X-mProtect: <200310242153> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdT0NGvE; Fri, 24 Oct 2003 14:53:06 PDT Message-ID: <3F99A067.70709@iprg.nokia.com> Date: Fri, 24 Oct 2003 14:57:59 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Jun-ichiro itojun Hagino , iljitsch@muada.com, ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: MTU handling References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola wrote: >On Thu, 23 Oct 2003, Jun-ichiro itojun Hagino wrote: >[...] > > >> the assumption made in RFC2461 is that the link MTU is constant >> over the link, i guess. i don't think it is necessary to make >> MTU negotiable between peers, it would complicate too many things. >> >> > >FWIW, I agree with this assumption. Really, if you want to put different >MTU's on the same link and want to optimize it, use multiple links.. > Not possible in all cases; take multi-access wireless media, for example. We must face facts that there are multiple access, shared-media links out there and will continue to be for the forseeable future. We can wish for a densely-connected mesh of point-to-point links (e.g., ATM PVCs) but we needs-be have to support the L2 infrastructure that is already deployed. (Otherwise, we would have to go through an L2 transition before we even begin to tackle the IPv6 transition.) Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 20:32:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06966 for ; Fri, 24 Oct 2003 20:32:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADCLl-0005vJ-Uv for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 20:32:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9P0WD2O022763 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 20:32:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADCLl-0005v4-LZ for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 20:32:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06925 for ; Fri, 24 Oct 2003 20:32:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADCLj-0006if-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 20:32:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADCLj-0006iZ-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 20:32:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADCKc-0005im-SR; Fri, 24 Oct 2003 20:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADCKW-0005hh-J7 for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 20:30:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06872 for ; Fri, 24 Oct 2003 20:30:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADCKU-0006h6-00 for ipv6@ietf.org; Fri, 24 Oct 2003 20:30:54 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ADCKT-0006gi-00 for ipv6@ietf.org; Fri, 24 Oct 2003 20:30:53 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9P0TUL23853; Fri, 24 Oct 2003 17:29:30 -0700 X-mProtect: <200310250029> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdbsT7da; Fri, 24 Oct 2003 17:29:29 PDT Message-ID: <3F99C50E.5010603@iprg.nokia.com> Date: Fri, 24 Oct 2003 17:34:22 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: Iljitsch van Beijnum , ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: MTU handling References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>Currently, routers can advertise an MTU for a link. That's nice. But >>what we really need is a way for hosts to find out the MTU each >>individual neighbor can handle. 100 Mbps and slower ethernet interfaces >>can typically handle only the standard 1500 byte ethernet MTU, while >>gigabit ethernet interfaces usually support a much larger MTU. >> >>However, in most cases hosts with different MTUs are present on the >>same subnet, so simply advertising a larger MTU wouldn't solve this. >>(Not that this would work anyway as hosts are instructed to only listen >>to MTU advertisements where the MTU is between 1280 and 1500 (for >>ethernet).) >> >>But if hosts can tell each other the MTU they support, each set of two >>hosts is always able to use the largest possible MTU between them. >>(This would also require a new link MTU option that conveys the maximum >>MTU the lower layer equipment supports. Switches have their own MTU and >>even some hubs start doing strange things when a larger than expected >>MTU is used.) >> >> > >This might be useful when the L2 doesn't have any MTU limitations. >For instance, with IP over ATM the default MTU is 9k but AAL5 has a 16 bit >length field (if I don't misremember). Thus a pair of nodes can agree to use >e.g. 37.5k MTU. > HiPPI is another example of a link with a 16-bit length field. So, you can get up to 64KB MTUs but that might be too much for constrained nodes to accept at high packet arrival rates. If IPv6 ND provided a new option for nodes to send per-neighbor (not per-link) MTU values, the situation for constrained nodes on large links would be greatly improved. >But for links where the L2 has tigher limits things are quite a bit more >difficuly. Taking Ethernet as an example. Having two hosts say that they >want to use a 9k MTU over Ethernet is fine as long as the bridges/switches >on the path all support that. But how can the hosts know that? >Even if the hosts can determine this (send a 9k packet and see if it gets >through?), what happens when an addition Ethernet switch or wire comes up >(or goes away) and spanning tree changes the L2 path between those >two hosts so that the packets no longer go through the same set of >bridges/switches? > If you are probing to determine the initial PMTU, the answer is to send periodic additional probes, of course. Routes are going to flap, and paths are going to change - a once-probed MTU cannot be expected to remain stable for any set length of time. >If one would want to pursue this I think the best way would be for >IEEE 802 to define a "frame size discovery" protocol at L2 so that >hosts can robustly determine the frame size a given destination >MAC address and be notified when it changes. >But since Ethernet jumboframes are non-standard (even though more and more >commonly used it seems) and there is concern about the coverage of the Ethernet >CRC for larger frames, the IEEE has been unvilling to look into this. > The IEEE transformation obviously just isn't going to happen. Even if it somehow did, we would have the entire legacy Internet infrastructure to overhaul and (as I said to Pekka) I just can't see waiting for an L2 transition before we move forward seriously with the IPv6 transition. >Once you have such L2 capability then a ND option for "I can receive packets >with this MTU" allowing the a larger value than the default link MTU, >would make sense to me. But without the L2 capability it doesn't seem >very useful. > Disagree here. See my earlier examples on peer-to-peer wireless networking and constrained nodes on large MTU media. Fred ftemplin@iprg.nokia.com > > Erik > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 20:35:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07103 for ; Fri, 24 Oct 2003 20:35:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADCO8-0006SW-S1 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 20:34:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9P0Yegp024828 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 20:34:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADCO8-0006SN-MQ for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 20:34:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07049 for ; Fri, 24 Oct 2003 20:34:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADCO6-0006lW-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 20:34:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADCO6-0006lS-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 20:34:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADCNW-0006BW-Ee; Fri, 24 Oct 2003 20:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADCN1-00069D-2m for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 20:33:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07018 for ; Fri, 24 Oct 2003 20:33:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADCMy-0006kh-00 for ipv6@ietf.org; Fri, 24 Oct 2003 20:33:28 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ADCMy-0006jy-00 for ipv6@ietf.org; Fri, 24 Oct 2003 20:33:28 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9P0WXK26201; Fri, 24 Oct 2003 17:32:33 -0700 X-mProtect: <200310250032> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd0nr6Ka; Fri, 24 Oct 2003 17:32:31 PDT Message-ID: <3F99C5C6.1070800@iprg.nokia.com> Date: Fri, 24 Oct 2003 17:37:26 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Iljitsch van Beijnum , Jun-ichiro itojun Hagino , ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: MTU handling References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola wrote: >On Thu, 23 Oct 2003, Iljitsch van Beijnum wrote: >[...] > > >>See http://sd.wareonearth.com/~phil/net/jumbo/ for some links >>surrounding this issue. >> >> > >Yes, and...? > >Even if you don't want a separate physical infrastructure, defining a VLAN >is trivial. > Where the L2 supports that capability and operators know how to configure it, perhaps. Everywhere else, we still have legacy L2 infrastructures to deal with. >Really, I can't see all that many scenarios where you'd deploy multiple >nodes on a link with different MTU values and the internal traffic would >be so high that optimizing the MTU used between these would be worth >optimizing.. > I have given two good examples. Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 20:48:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07474 for ; Fri, 24 Oct 2003 20:48:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADCbJ-00084J-RW for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 20:48:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9P0mHbM031009 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 20:48:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADCbJ-000844-MY for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 20:48:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07450 for ; Fri, 24 Oct 2003 20:48:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADCbH-0006w6-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 20:48:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADCbH-0006w3-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 20:48:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADCb4-0007um-8c; Fri, 24 Oct 2003 20:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADCah-0007tO-8V for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 20:47:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07437 for ; Fri, 24 Oct 2003 20:47:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADCae-0006vh-00 for ipv6@ietf.org; Fri, 24 Oct 2003 20:47:37 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ADCae-0006vZ-00 for ipv6@ietf.org; Fri, 24 Oct 2003 20:47:36 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9P0kw905326; Fri, 24 Oct 2003 17:46:58 -0700 X-mProtect: <200310250046> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmxm1Fl; Fri, 24 Oct 2003 17:46:57 PDT Message-ID: <3F99C926.3090200@iprg.nokia.com> Date: Fri, 24 Oct 2003 17:51:50 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: Iljitsch van Beijnum , ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: MTU handling References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>Such a capability would enhance a layer 3 neighbor MTU management >>capability, but it isn't required. Operators can simply have routers >>annouce an upper limit on the MTU that may be used on a subnet. This >>doesn't impede the best case scenario where all the switches support a >>good sized MTU. Since the number of switches per subnet is typically >>much smaller than the number of hosts per subnet, getting all switches >>to support jumboframes is significantly simpler than getting all hosts >>to do the same. >> >> > >Ah - now I get where you are going with this. From my "host perspective" >it is the switches lack of support which is the main problem - but you >are right that the inverse problem also exists. > >So one approach would be something like having a router advertisement >option that asserts "trust us; the L2 can in fact support 9k" resulting >in individual hosts deciding to send out an option with their NS/NA saying >"I can support receiving 9k". > Agree with the hosts sending ND messages saying: "I can support receiving 9K" but not necessarily with the rotuer saying "trust us; the L2 can in fact support 9k". The router should be advertising the lowest-common-denominator for all nodes on the link. This might be constrained by the link with the smallest MTU, the node with the smallest receive buffer, etc. Nodes that can accept more than the lowest-common denominator should negotiate a larger MTU with their neighbors - even if the value they negotiate is larger than what is being sent in the MTU option in RA's. (Similarly, nodes that prefer smaller than the LCD should negotiate a smaller MTU - even though they still need to support the LCD for broadcast/multicast.) >Note that this is different than the default MTU being 9k - since not all >hosts support the larger MTU everybody would still need to use the default >1500 MTU for sending broadcast and multicast packets on the link. > Yes - this follows from the LCD discussion above. >This still has the operational issue of what happens when >I need extra ports in my office and I get a cheap 4-port hub; neither >the IT department nor my hosts knows that this box is present and it >might not support jumboframes. One way to cope with this particular topology, >but no other topologies of varying frame size switches, would be >for the host to exchange a 9k packet with the router before >deciding that it should declare itself 9k capable. > You could use something like an IPv6 NS message that is artificially inflated in size for this as we have discussed in the past. But, it's not a once-and-done deal; if you're going to be probing the MTU you need to do it periodically so that L2 path changes don't result in black holes. General comment - it would be nice if folks would reveiw and comment on my drafts: http://www.ietf.org/internet-drafts/draft-templin-ndiscmtu-00.txt http://www.ietf.org/internet-drafts/draft-templin-tunnelmtu-01.txt Fred ftemplin@iprg.nokia.com > > Erik > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 24 21:02:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07869 for ; Fri, 24 Oct 2003 21:02:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADCov-0000aW-L5 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 21:02:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9P12LW7002259 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 21:02:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADCov-0000aM-Dw for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 21:02:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07832 for ; Fri, 24 Oct 2003 21:02:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADCos-00074h-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 21:02:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADCos-00074e-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 21:02:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADCoc-0000Qx-8F; Fri, 24 Oct 2003 21:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADCoF-0000Pz-TH for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 21:01:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07809 for ; Fri, 24 Oct 2003 21:01:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADCoD-000740-00 for ipv6@ietf.org; Fri, 24 Oct 2003 21:01:37 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ADCoC-00073k-00 for ipv6@ietf.org; Fri, 24 Oct 2003 21:01:36 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9P10sc14253; Fri, 24 Oct 2003 18:00:54 -0700 X-mProtect: <200310250100> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5Cx6qP; Fri, 24 Oct 2003 18:00:53 PDT Message-ID: <3F99CC6B.5000203@iprg.nokia.com> Date: Fri, 24 Oct 2003 18:05:47 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: MTU handling References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I see (at least) three ways for the neighbor-to-neighbor MTU negotiation; two were presented in my drafts and the third is presented by Iljitsch here. The methods are: 1) Change RFC 2461 to allow NA messages to include MTU options: Advantages: - Unambiguous mechanism for NA's to inform of a per-neighbor MTU value Disadvantages: - Requires modification to RFC 2461 - May require extra ND messages, since the interpretation of MTU options is different for RAs 2) No changes to RFC 2461; allow "IPv6-over-foo" documents to specify different interpretations of the MTU option in RA's: Advantages: - No modifications to RFC 2461 Disadvantages: - Ambiguous interpretation of MTU options in RAs, or the specified interpretation (MTU for the entire link) is disabled - MTU option only available for RAs; not NAs 3) Change RFC 2461 to specify a new "NBR_MTU" option that can be sent with either NA's or RAs: Advantages: - Unambiguous mechanism to inform of a per-neighbor MTU value - Can be used with either NAs or RAs w/o altering the interpretation of the existing MTU option - Maximum efficiency, since it can be used with either NAs or RAs Disadvantages: - Requires modifications to RFC 2461 So, it should be clear from the above analysis that I support Iljitsch's proposal in terms of what should go into RFC 2461. It is a sensible approach for a valuable mechanism and I think folks should give it the consideration it deserves. Fred ftemplin@iprg.nokia.com Iljitsch van Beijnum wrote: > I'm not sure this should go into a replacement specification for RFC > 2461, but I'll bring it up anyway: > > Currently, routers can advertise an MTU for a link. That's nice. But > what we really need is a way for hosts to find out the MTU each > individual neighbor can handle. 100 Mbps and slower ethernet > interfaces can typically handle only the standard 1500 byte ethernet > MTU, while gigabit ethernet interfaces usually support a much larger MTU. > > However, in most cases hosts with different MTUs are present on the > same subnet, so simply advertising a larger MTU wouldn't solve this. > (Not that this would work anyway as hosts are instructed to only > listen to MTU advertisements where the MTU is between 1280 and 1500 > (for ethernet).) > > But if hosts can tell each other the MTU they support, each set of two > hosts is always able to use the largest possible MTU between them. > (This would also require a new link MTU option that conveys the > maximum MTU the lower layer equipment supports. Switches have their > own MTU and even some hubs start doing strange things when a larger > than expected MTU is used.) > > BTW, some duplication seems to have crept into the document: > > variable MTU - a link that does not have a well-defined MTU (e.g., > IEEE 802.5 token rings). Many links (e.g., > Ethernet) have a standard MTU defined by the link- > layer protocol or by the specific document > describing how to run IP over the link layer. > > variable MTU - Neighbor Discovery allows routers to specify a MTU > for the link, which all nodes then use. All nodes > on a link must use the same MTU (or Maximum > Receive Unit) in order for multicast to work > properly. Otherwise when multicasting a sender, > which can not know which nodes will receive the > packet, could not determine a minimum packet size > all receivers can process. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Oct 25 00:21:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11611 for ; Sat, 25 Oct 2003 00:21:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADFuq-0007Uc-8x for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 00:20:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9P4KeGM028799 for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 00:20:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADFup-0007UQ-Gk for ipv6-web-archive@optimus.ietf.org; Sat, 25 Oct 2003 00:20:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11586 for ; Sat, 25 Oct 2003 00:20:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADFum-0000iE-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 00:20:36 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADFum-0000iB-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 00:20:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADFuF-0007I5-HP; Sat, 25 Oct 2003 00:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADFtZ-0007At-Pb for ipv6@optimus.ietf.org; Sat, 25 Oct 2003 00:19:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11559 for ; Sat, 25 Oct 2003 00:19:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADFtW-0000hV-00 for ipv6@ietf.org; Sat, 25 Oct 2003 00:19:18 -0400 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx with esmtp (Exim 4.12) id 1ADFtW-0000hO-00 for ipv6@ietf.org; Sat, 25 Oct 2003 00:19:18 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id BB6B1B7AE; Sat, 25 Oct 2003 00:19:18 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 25 Oct 2003 00:19:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: "RFC 2461bis" issue: MTU handling Date: Sat, 25 Oct 2003 00:19:17 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B051221A9@tayexc13.americas.cpqcorp.net> Thread-Topic: "RFC 2461bis" issue: MTU handling Thread-Index: AcOak8E/znaJMqLCTV2jTkMziqneoAAGzaGw From: "Bound, Jim" To: "Fred Templin" , "Iljitsch van Beijnum" Cc: X-OriginalArrivalTime: 25 Oct 2003 04:19:18.0528 (UTC) FILETIME=[2875F800:01C39AAF] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I believe there is another option. Develop new spec that does number 3 below to add to 2461 and leave 2461 alone. This would be a spec defining a new option for 2461. /jim > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On=20 > Behalf Of Fred Templin > Sent: Friday, October 24, 2003 9:06 PM > To: Iljitsch van Beijnum > Cc: ipv6@ietf.org > Subject: Re: "RFC 2461bis" issue: MTU handling >=20 >=20 > I see (at least) three ways for the neighbor-to-neighbor MTU=20 > negotiation; two were presented in my drafts and the third is=20 > presented by Iljitsch here. The methods are: >=20 > 1) Change RFC 2461 to allow NA messages to include MTU options: > Advantages: > - Unambiguous mechanism for NA's to inform of a=20 > per-neighbor MTU value > Disadvantages: > - Requires modification to RFC 2461 > - May require extra ND messages, since the interpretation of > MTU options is different for RAs >=20 > 2) No changes to RFC 2461; allow "IPv6-over-foo" documents to > specify different interpretations of the MTU option in RA's: > Advantages: > - No modifications to RFC 2461 > Disadvantages: > - Ambiguous interpretation of MTU options in RAs, or the > specified interpretation (MTU for the entire link) is disabled > - MTU option only available for RAs; not NAs >=20 > 3) Change RFC 2461 to specify a new "NBR_MTU" option that > can be sent with either NA's or RAs: > Advantages: > - Unambiguous mechanism to inform of a per-neighbor MTU value > - Can be used with either NAs or RAs w/o altering the=20 > interpretation > of the existing MTU option > - Maximum efficiency, since it can be used with either=20 > NAs or RAs > Disadvantages: > - Requires modifications to RFC 2461 >=20 > So, it should be clear from the above analysis that I support=20 > Iljitsch's proposal in terms of what should go into RFC 2461.=20 > It is a sensible approach for a valuable mechanism and I=20 > think folks should give it the consideration it deserves. >=20 > Fred > ftemplin@iprg.nokia.com >=20 > Iljitsch van Beijnum wrote: >=20 > > I'm not sure this should go into a replacement specification for RFC > > 2461, but I'll bring it up anyway: > > > > Currently, routers can advertise an MTU for a link. That's nice. But > > what we really need is a way for hosts to find out the MTU each=20 > > individual neighbor can handle. 100 Mbps and slower ethernet=20 > > interfaces can typically handle only the standard 1500 byte=20 > ethernet=20 > > MTU, while gigabit ethernet interfaces usually support a=20 > much larger MTU. > > > > However, in most cases hosts with different MTUs are present on the > > same subnet, so simply advertising a larger MTU wouldn't=20 > solve this.=20 > > (Not that this would work anyway as hosts are instructed to only=20 > > listen to MTU advertisements where the MTU is between 1280 and 1500=20 > > (for ethernet).) > > > > But if hosts can tell each other the MTU they support, each=20 > set of two > > hosts is always able to use the largest possible MTU between them.=20 > > (This would also require a new link MTU option that conveys the=20 > > maximum MTU the lower layer equipment supports. Switches have their=20 > > own MTU and even some hubs start doing strange things when a larger=20 > > than expected MTU is used.) > > > > BTW, some duplication seems to have crept into the document: > > > > variable MTU - a link that does not have a=20 > well-defined MTU (e.g., > > IEEE 802.5 token rings). Many links (e.g., > > Ethernet) have a standard MTU defined=20 > by the link- > > layer protocol or by the specific document > > describing how to run IP over the link layer. > > > > variable MTU - Neighbor Discovery allows routers to=20 > specify a MTU > > for the link, which all nodes then=20 > use. All nodes > > on a link must use the same MTU (or Maximum > > Receive Unit) in order for multicast to work > > properly. Otherwise when=20 > multicasting a sender, > > which can not know which nodes will=20 > receive the > > packet, could not determine a minimum=20 > packet size > > all receivers can process. > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Oct 25 00:30:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12650 for ; Sat, 25 Oct 2003 00:30:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADG48-0000RY-Fs for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 00:30:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9P4UGau001698 for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 00:30:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADG47-0000RB-3x for ipv6-web-archive@optimus.ietf.org; Sat, 25 Oct 2003 00:30:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12607 for ; Sat, 25 Oct 2003 00:30:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADG44-0000od-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 00:30:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADG43-0000oZ-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 00:30:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADG3u-0000I0-TF; Sat, 25 Oct 2003 00:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADG38-0000Dz-JU for ipv6@optimus.ietf.org; Sat, 25 Oct 2003 00:29:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12552 for ; Sat, 25 Oct 2003 00:29:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADG35-0000ms-00 for ipv6@ietf.org; Sat, 25 Oct 2003 00:29:11 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1ADG35-0000mX-00 for ipv6@ietf.org; Sat, 25 Oct 2003 00:29:11 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HNA00705PRNBZ@mailout1.samsung.com> for ipv6@ietf.org; Sat, 25 Oct 2003 13:28:35 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HNA005VJPRKT0@mailout1.samsung.com> for ipv6@ietf.org; Sat, 25 Oct 2003 13:28:32 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HNA006TIPRKRG@mmp2.samsung.com> for ipv6@ietf.org; Sat, 25 Oct 2003 13:28:32 +0900 (KST) Date: Sat, 25 Oct 2003 13:28:50 +0900 From: Soohong Daniel Park Subject: RE: draft-syam-ipv6-state-model-00.txt In-reply-to: <9C422444DE99BC46B3AD3C6EAFC9711B05122174@tayexc13.americas.cpqcorp.net> To: "'Bound, Jim'" , ipv6@ietf.org Cc: "'O.L.N.Rao'" , "'Soohong Daniel Park'" Message-id: <000001c39ab0$7da96180$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hello Jim > I have read this spec and don't see bugs at this point. Is this > document to feed work on MIB definitions for SNMP and network > management? Or just to describe as information the various states in > the draft? The original intent is to be a Informational RFC as a result of our implementation but there is no any wall to refer this document. As you indicated, no bug is there. Shoud this document have "ietf" in its name ? Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On > Behalf Of Bound, Jim > Sent: Saturday, October 25, 2003 3:28 AM > To: ipv6@ietf.org > Subject: draft-syam-ipv6-state-model-00.txt > > > > /jim > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Oct 25 01:38:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13768 for ; Sat, 25 Oct 2003 01:38:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADH8D-0000Gd-0W for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 01:38:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9P5cWjS001015 for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 01:38:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADH8C-0000GI-QI for ipv6-web-archive@optimus.ietf.org; Sat, 25 Oct 2003 01:38:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13733 for ; Sat, 25 Oct 2003 01:38:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADH89-0001Ip-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 01:38:29 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADH89-0001Im-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 01:38:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADH7h-00008y-9R; Sat, 25 Oct 2003 01:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADH7A-0008S2-7v for ipv6@optimus.ietf.org; Sat, 25 Oct 2003 01:37:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13697 for ; Sat, 25 Oct 2003 01:37:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADH77-0001IC-00 for ipv6@ietf.org; Sat, 25 Oct 2003 01:37:25 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADH76-0001Hz-00 for ipv6@ietf.org; Sat, 25 Oct 2003 01:37:24 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9P5aZN05527; Sat, 25 Oct 2003 08:36:36 +0300 Date: Sat, 25 Oct 2003 08:36:34 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: Fred Templin , Iljitsch van Beijnum , Subject: RE: "RFC 2461bis" issue: MTU handling In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B051221A9@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Sat, 25 Oct 2003, Bound, Jim wrote: > I believe there is another option. Develop new spec that does number 3 > below to add to 2461 and leave 2461 alone. This would be a spec > defining a new option for 2461. Or, even define the new interpretation for MTU over NA messages in a separate spec and leave RFC 2461 untouched...? > > -----Original Message----- > > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On > > Behalf Of Fred Templin > > Sent: Friday, October 24, 2003 9:06 PM > > To: Iljitsch van Beijnum > > Cc: ipv6@ietf.org > > Subject: Re: "RFC 2461bis" issue: MTU handling > > > > > > I see (at least) three ways for the neighbor-to-neighbor MTU > > negotiation; two were presented in my drafts and the third is > > presented by Iljitsch here. The methods are: > > > > 1) Change RFC 2461 to allow NA messages to include MTU options: > > Advantages: > > - Unambiguous mechanism for NA's to inform of a > > per-neighbor MTU value > > Disadvantages: > > - Requires modification to RFC 2461 > > - May require extra ND messages, since the interpretation of > > MTU options is different for RAs > > > > 2) No changes to RFC 2461; allow "IPv6-over-foo" documents to > > specify different interpretations of the MTU option in RA's: > > Advantages: > > - No modifications to RFC 2461 > > Disadvantages: > > - Ambiguous interpretation of MTU options in RAs, or the > > specified interpretation (MTU for the entire link) is disabled > > - MTU option only available for RAs; not NAs > > > > 3) Change RFC 2461 to specify a new "NBR_MTU" option that > > can be sent with either NA's or RAs: > > Advantages: > > - Unambiguous mechanism to inform of a per-neighbor MTU value > > - Can be used with either NAs or RAs w/o altering the > > interpretation > > of the existing MTU option > > - Maximum efficiency, since it can be used with either > > NAs or RAs > > Disadvantages: > > - Requires modifications to RFC 2461 > > > > So, it should be clear from the above analysis that I support > > Iljitsch's proposal in terms of what should go into RFC 2461. > > It is a sensible approach for a valuable mechanism and I > > think folks should give it the consideration it deserves. > > > > Fred > > ftemplin@iprg.nokia.com > > > > Iljitsch van Beijnum wrote: > > > > > I'm not sure this should go into a replacement specification for RFC > > > 2461, but I'll bring it up anyway: > > > > > > Currently, routers can advertise an MTU for a link. That's nice. But > > > what we really need is a way for hosts to find out the MTU each > > > individual neighbor can handle. 100 Mbps and slower ethernet > > > interfaces can typically handle only the standard 1500 byte > > ethernet > > > MTU, while gigabit ethernet interfaces usually support a > > much larger MTU. > > > > > > However, in most cases hosts with different MTUs are present on the > > > same subnet, so simply advertising a larger MTU wouldn't > > solve this. > > > (Not that this would work anyway as hosts are instructed to only > > > listen to MTU advertisements where the MTU is between 1280 and 1500 > > > (for ethernet).) > > > > > > But if hosts can tell each other the MTU they support, each > > set of two > > > hosts is always able to use the largest possible MTU between them. > > > (This would also require a new link MTU option that conveys the > > > maximum MTU the lower layer equipment supports. Switches have their > > > own MTU and even some hubs start doing strange things when a larger > > > than expected MTU is used.) > > > > > > BTW, some duplication seems to have crept into the document: > > > > > > variable MTU - a link that does not have a > > well-defined MTU (e.g., > > > IEEE 802.5 token rings). Many links (e.g., > > > Ethernet) have a standard MTU defined > > by the link- > > > layer protocol or by the specific document > > > describing how to run IP over the link layer. > > > > > > variable MTU - Neighbor Discovery allows routers to > > specify a MTU > > > for the link, which all nodes then > > use. All nodes > > > on a link must use the same MTU (or Maximum > > > Receive Unit) in order for multicast to work > > > properly. Otherwise when > > multicasting a sender, > > > which can not know which nodes will > > receive the > > > packet, could not determine a minimum > > packet size > > > all receivers can process. > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Oct 25 06:02:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01095 for ; Sat, 25 Oct 2003 06:02:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADLFH-0004aS-Kv for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 06:02:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9PA27Fa017626 for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 06:02:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADLFH-0004aD-EP for ipv6-web-archive@optimus.ietf.org; Sat, 25 Oct 2003 06:02:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01057 for ; Sat, 25 Oct 2003 06:01:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADLFD-0003OL-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 06:02:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADLFD-0003OH-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 06:02:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADLEE-0004NS-4m; Sat, 25 Oct 2003 06:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADLDe-0004LO-DP for ipv6@optimus.ietf.org; Sat, 25 Oct 2003 06:00:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01031 for ; Sat, 25 Oct 2003 06:00:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADLDa-0003Np-00 for ipv6@ietf.org; Sat, 25 Oct 2003 06:00:22 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1ADLDZ-0003Nd-00 for ipv6@ietf.org; Sat, 25 Oct 2003 06:00:21 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9P9xnxA029898; Sat, 25 Oct 2003 02:59:49 -0700 (PDT) Received: from lillen (vpn-129-156-96-19.EMEA.Sun.COM [129.156.96.19]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9P9xlS29592; Sat, 25 Oct 2003 11:59:47 +0200 (MEST) Date: Sat, 25 Oct 2003 11:59:39 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: RFC 2461- issue list To: Soliman Hesham Cc: "'Erik Nordmark'" , ipv6@ietf.org In-Reply-To: "Your message with ID" <748C6D0A58C0F94CA63C198B6674697A01922E0A@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > There is also the process issue on what can be added to > a DS, given the requirements on moving from PS to DS > (having every option interop tested and some level of > deployment), which might stand in the way of adding > new extensions from a PS/draft. You are allowed to add things that have been at PS for 6 months with interoperability test results i.e. things that could move to DS in their own right. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Oct 25 06:09:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01310 for ; Sat, 25 Oct 2003 06:09:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADLLj-00067m-1t for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 06:08:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9PA8lju023536 for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 06:08:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADLLi-00067X-Rq for ipv6-web-archive@optimus.ietf.org; Sat, 25 Oct 2003 06:08:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01273 for ; Sat, 25 Oct 2003 06:08:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADLLf-0003S9-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 06:08:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADLLe-0003S6-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 06:08:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADLL0-0005qS-EZ; Sat, 25 Oct 2003 06:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADLKQ-0005g6-Uj for ipv6@optimus.ietf.org; Sat, 25 Oct 2003 06:07:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01238 for ; Sat, 25 Oct 2003 06:07:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADLKN-0003Qz-00 for ipv6@ietf.org; Sat, 25 Oct 2003 06:07:23 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ADLKM-0003Qm-00 for ipv6@ietf.org; Sat, 25 Oct 2003 06:07:22 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RDJRT>; Sat, 25 Oct 2003 06:06:44 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E19@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Erik Nordmark'" Cc: ipv6@ietf.org Subject: RE: RFC 2461- issue list Date: Sat, 25 Oct 2003 06:06:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > > There is also the process issue on what can be added to > > a DS, given the requirements on moving from PS to DS > > (having every option interop tested and some level of > > deployment), which might stand in the way of adding > > new extensions from a PS/draft. > > You are allowed to add things that have been at PS for 6 months with > interoperability test results i.e. things that could move to DS in > their own right. => Excellent, thanks for the clarification. I guess this would definitely qualify the R and H bits in the RA to be included. I'll check to see if the RA interval option was ever interop tested. Hesham > > Erik > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Oct 25 08:54:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04184 for ; Sat, 25 Oct 2003 08:54:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADNwB-0002h9-DV for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 08:54:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9PCsZ2o010356 for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 08:54:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADNwB-0002gx-2T for ipv6-web-archive@optimus.ietf.org; Sat, 25 Oct 2003 08:54:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04160 for ; Sat, 25 Oct 2003 08:54:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADNw9-0004nR-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 08:54:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADNw9-0004nH-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 08:54:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADNvd-0002Zp-EG; Sat, 25 Oct 2003 08:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADNue-0002WD-JV for ipv6@optimus.ietf.org; Sat, 25 Oct 2003 08:53:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04136 for ; Sat, 25 Oct 2003 08:52:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADNud-0004mv-00 for ipv6@ietf.org; Sat, 25 Oct 2003 08:52:59 -0400 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1ADNuc-0004ms-00 for ipv6@ietf.org; Sat, 25 Oct 2003 08:52:58 -0400 Received: from tyre (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.10/8.12.1) with SMTP id h9PCqOlr029040 for ; Sat, 25 Oct 2003 21:52:25 +0900 (KST) Message-ID: <039301c39af7$e4eb6ea0$ec2f024b@tyre> From: "JinHyeock Choi" To: References: <3F9964D2.6030404@innovationslab.net> Subject: Re: A list of issues for RFC2462 update Date: Sat, 25 Oct 2003 21:59:57 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: base64 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RGVhciBWaWpheQ0KDQpUaGFua3MgZm9yIGJyaW5nIHRoaXMgdXAuIA0KDQpWaWpheSBEZXZhcmFw YWxsaSB3cm90ZSANCj4gaGksDQo+DQo+IGhlcmUgaXMgYW5vdGhlciBpc3N1ZS4gaXQgaW52b2x2 ZXMgYm90aCAyNDYxIGFuZCAyNDYyLg0KPiANCj4gUkZDIDI0NjEgc2F5cw0KPg0KPiAgIEJlZm9y ZSBhIGhvc3Qgc2VuZHMgYW4gaW5pdGlhbCBzb2xpY2l0YXRpb24sIGl0IFNIT1VMRCBkZWxheSB0 aGUNCj4gICB0cmFuc21pc3Npb24gZm9yIGEgcmFuZG9tIGFtb3VudCBvZiB0aW1lIGJldHdlZW4g MCBhbmQNCj4gICBNQVhfUlRSX1NPTElDSVRBVElPTl9ERUxBWS4NCj4NCj4gUkZDIDI0NjIgc2F5 cw0KPg0KPiAgIElmIHRoZSBOZWlnaGJvciBTb2xpY2l0YXRpb24gaXMgdGhlIGZpcnN0IG1lc3Nh Z2UgdG8gYmUgc2VudCBmcm9tIGFuDQo+ICAgaW50ZXJmYWNlIGFmdGVyIGludGVyZmFjZSAocmUp aW5pdGlhbGl6YXRpb24sIHRoZSBub2RlIHNob3VsZCBkZWxheQ0KPiAgIHNlbmRpbmcgdGhlIG1l c3NhZ2UgYnkgYSByYW5kb20gZGVsYXkgYmV0d2VlbiAwIGFuZA0KPiAgIE1BWF9SVFJfU09MSUNJ VEFUSU9OX0RFTEFZIGFzIHNwZWNpZmllZCBpbiBbRElTQ09WRVJZXS4NCj4NCj4gbGV0cyBhc3N1 bWUgYSBNb2JpbGUgTm9kZSBtb3ZlcyBhbmQgYXR0YWNoZXMgdG8gYSBuZXcNCj4gbGluay4gaXQg ZG9lcyByb3V0ZXIgZGlzY292ZXJ5IGFuZCBjb25maWd1cmVzIGEgQ2FyZS1vZg0KPiBhZGRyZXNz LiB0aGUgbW9iaWxlIG5vZGUgY2Fubm90IHNlbmQgYSBCaW5kaW5nIFVwZGF0ZQ0KPiB1bnRpbCBp dCBjb21wbGV0ZXMgREFEIGZvciB0aGUgQ2FyZS1vZiBhZGRyZXNzLiB0aGVzZQ0KPiB0d28gcmFu ZG9tIGRlbGF5cyAoYmVmb3JlIHJvdXRlciBkaXNjb3ZlcnkgYW5kIGJlZm9yZQ0KPiBEQUQpIGNv bnRyaWJ1dGUgYSBsb3QgdG8gdGhlIG1vdmVtZW50IGRldGVjdGlvbiBkZWxheS4NCj4gSSB0aGlu ayB0aGlzIG5lZWRzIHRvIGJlIGZpeGVkLg0KPiBNQVhfUlRSX1NPTElDSVRBVElPTl9ERUxBWSBp cyAxIHNlY29uZC4gdGFraW5nIHRoZSB3b3JzdA0KPiBjYXNlIHNjZW5hcmlvLCBpdCBjb3VsZCBi ZSAxIHNlY29uZCBiZWZvcmUgYSBzZW5kaW5nDQo+IHJvdXRlciBzb2xpY2l0YXRpb24sIG9uZSBz ZWNvbmQgYmVmb3JlIHNlbmRpbmcgbmVpZ2hib3INCj4gc29saWNpdGF0aW9uIGZvciBEQUQgYW5k IHRoZW4gMSBzZWNvbmQgYmVmb3JlIERBRA0KPiBjb21wbGV0ZXMuIHRoZSBCaW5kaW5nIFVwZGF0 ZSBjYW5ub3QgYmUgc2VudCB1bnRpbCB0aGVuLg0KDQpJbmRlZWQgdGhlc2UgY2F1c2UgbG9uZyBo YW5kb2ZmIGxhdGVuY3kuIEFuZCB0aGVyZSBpcyBhbiBhbm90aGVyIHJhbmRvbSANCmRlbGF5IGJl Zm9yZSBzZW5kaW5nIFJBLiAgDQogDQo+IHdlIGhhZCBhIGxvbmcgZGlzY3Vzc2lvbiBvbiB0aGUg TW9iaWxlIElQIG1haWxpbmcgbGlzdC4NCj4gc29tZSBhcmd1ZWQgdGhhdCB0aGlzIG5lZWRzIHRv IGJlIGRvbmUgb25seSB3aGVuIHRoZQ0KPiBpbnRlcmZhY2UgaXMgaW5pdGlhbGl6ZWQgYW5kIG5v dCB3aGVuIHRoZSBtb2JpbGUgbm9kZQ0KPiBhdHRhY2hlcyB0byBhIG5ldyBsaW5rLiBvdGhlcnMg YXJndWVkIHRoYXQgdGhpcyByYW5kb20NCj4gZGVsYXkgaXMgZXNzZW50aWFsIHRvIGF2b2lkIGEg REFEIHN0b3JtIGlmIGEgYnVuY2ggb2YNCj4gbW9iaWxlIG5vZGVzIG1vdmUgYXQgdGhlIHNhbWUg dGltZS4NCg0KV2UgaGF2ZSBub3QgcmVhY2hlZCBhIGNvbnNlbnN1cyBpbiBtb2JpbGVpcCBtYWls aW5nIGxpc3QuIEkgd2lzaCB3ZSBjbGFyaWZ5IA0KdGhpcy4gIA0KDQpCZXN0IHJlZ2FyZHMNCg0K SmluSHllb2NrDQo= -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Oct 25 10:50:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07378 for ; Sat, 25 Oct 2003 10:50:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADPkX-000560-0o for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 10:50:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9PEoe94019588 for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 10:50:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADPkW-00055r-R0 for ipv6-web-archive@optimus.ietf.org; Sat, 25 Oct 2003 10:50:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07349 for ; Sat, 25 Oct 2003 10:50:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADPkU-0005h3-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 10:50:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADPkT-0005h0-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 10:50:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADPjv-0004yl-6W; Sat, 25 Oct 2003 10:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADPjb-0004xk-HX for ipv6@optimus.ietf.org; Sat, 25 Oct 2003 10:49:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07334 for ; Sat, 25 Oct 2003 10:49:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADPjZ-0005ga-00 for ipv6@ietf.org; Sat, 25 Oct 2003 10:49:41 -0400 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1ADPjY-0005gS-00 for ipv6@ietf.org; Sat, 25 Oct 2003 10:49:40 -0400 Received: from tyre (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.10/8.12.1) with SMTP id h9PEn7lr004662 for ; Sat, 25 Oct 2003 23:49:08 +0900 (KST) Message-ID: <03a701c39b08$32c830d0$ec2f024b@tyre> From: "JinHyeock Choi" To: References: <3F9964D2.6030404@innovationslab.net> <039301c39af7$e4eb6ea0$ec2f024b@tyre> Subject: Re: A list of issues for RFC2462 update Date: Sat, 25 Oct 2003 23:56:40 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: base64 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RGVhciBKaW0NCg0KVGhhbmtzIGZvciB5b3VyIGRldGFpbGVkIGNvbW1lbnRzLg0KDQpJIG1heSBu b3QgYmUgY2xlYXIgZW5vdWdoLiBUaGlzIEktRCBhc3N1bWVzIHRoZSBzY2VuYXJpbyBvZiBhIGhv c3QgbW92aW5nIGZyb20gb25lIGxpbmsgDQp0byBhbm90aGVyLiBJbiBtYW55IGNhc2VzLCB0aGUg dGVybSAnYSBob3N0L25vZGUnIGlzIGFjdHVhbGx5ICdhbiBNTicuDQoNCktpbmRseSBmaW5kIG15 IGluIGxpbmUgY29tbWVudHMuICAgDQoNCj4gQ29tbWVudHMgb24gdGhpcyBkcmFmdC4gIEkgYW0g dW5jbGVhciBidXQgaXQgbWF5IGJlIHRoaXMgd29yayBuZWVkcyB0bw0KPiBiZSBkb25lIGluIHRo ZSBtaXBzaG9wIFdHIHdpdGhpbiB0aGUgSW50ZXJuZXQgQXJlYSBhcyBJIGJlbGlldmUgYWxsIHRo YXQNCj4gaXMgcmVxdWlyZWQgdG8gcmVzb2x2ZSB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgaW4gdGhp cyBkcmFmdCBpcyBwb2xpY3kgdG8NCj4gdXNlIHRoZSBjdXJyZW50IE5EIDI0NjEgbWVjaGFuaXNt cyBhbmQgdGhlIGV4dGVuZGVkIE5EIG1lY2hhbmlzbXMgaW4NCj4gTUlQdjYuICBBcyB0aGUgV0cg bWF5IHJlYWxpemUgSSBkbyBub3Qgc3VwcG9ydCBtZXJnaW5nIE1JUHY2IE5EIGNoYW5nZXMNCj4g YmFjayBpbnRvIHRvIFJGQyAyNDYxIHNvIGRvIG5vdCBzZWUgbmVlZCBmb3IgdGhhdC4gIElmIHRo aXMgc3BlYyBpcyB0bw0KPiBkZWZpbmUgYW5kIGNsYXJpZnkgdGhlIHBvbGljeSBmb3IgdXNlIG9m IHRoZSBuZXcgcHJlZml4IG9wdGlvbiBpbiBNSVB2Ng0KPiBORCB0byBzZXQgUkEgUiBiaXQgdGhl biBJIHN1Z2dlc3QgdGhhdCBkaXNjdXNzaW9uIGJlIGluIG1pcHNob3AgV0cgd2hlcmUNCj4gdGhh dCBpcyB0aGVpciBmb2N1cy4gDQogDQpUaGFua3MgZm9yIHlvdXIgYWR2aWNlLiBJdCB3YXMgbm90 IGNsZWFyIHRvIG1lIHdoaWNoIFdHIGhhZCBtYW5kYXRlIG92ZXIgdGhpcyB3b3JrLiANCg0KPiAx LiBJbnRyb2R1Y3Rpb24gDQo+ICAgICANCj4gICAgTW92ZW1lbnQgZGV0ZWN0aW9uIChNRCkgaXMg b25lIG9mIGEgc2VyaWVzIG9mIHN0YWdlcyBpbiBhY2NvbXBsaXNoaW5nDQo+IA0KPiAgICBNSVB2 NiBoYW5kb3Zlci4gQXMgZGVmaW5lZCBpbiB0aGUgTUlQdjYgc3BlY2lmaWNhdGlvbiBbTUlQdjZd LCANCj4gICAgZGV0ZWN0aW9uIG9mIG1vdmVtZW50IGlzIGFjY29tcGxpc2hlZCB0aHJvdWdoIHJl Y2VwdGlvbiBvZiBSb3V0ZXIgDQo+ICAgIEFkdmVydGlzZW1lbnRzIChSQXMpIGFuZCBOZWlnaGJv ciBBZHZlcnRpc2VtZW50cyAoTkFzKSwgYW5kIA0KPiAgICBjb21wYXJpc29uIG9mIHRoZXNlIG1l c3NhZ2VzIHdpdGggcHJldmlvdXNseSByZWNlaXZlZCByb3V0ZXIgDQo+ICAgIGluZm9ybWF0aW9u LiANCj4gDQo+IExheWVyIDIgY2FuIGFsc28gbm90ZSBtb3ZlbWVudCBkZXRlY3Rpb24gYW5kIG1v cmUgcmVsaWFibGUgYW5kIGZhc3Rlcg0KPiB0b2RheS4gDQoNCkxheWVyIDIgY2FuIG9ubHkgZGV0 ZWN0IExpbmsgbGF5ZXIgY2hhbmdlLiBMYXllciAyIG1heSBhY3QgYXMgYSBoaW50IGJ1dCBjYW4n dCBjb25maXJtIA0KbW92ZW1lbnQuIEZvciBleGFtcGxlLCBsYXllciAyIGJ5IGl0c2VsZiBjYW4n dCBjaGVjayB0aGUgKHBhcnRpYWwpIHJlYWNoYWJpbGl0eSBvZiBjdXJyZW50IA0KZGVmYXVsdCBy b3V0ZXIuICANCiAgDQpbT21pdHRlZF0gICAgIA0KPiAyLjEgTGluayBsb2NhbCBzY29wZSBvZiBS b3V0ZXIgQWRkcmVzcyANCj4gIA0KPiAgICBUaGUgcm91dGVyIGFkZHJlc3MgY29udGFpbmVkIGlu IGFuIFJBIG1lc3NhZ2UgaXMgbGluay1sb2NhbCBzY29wZS4gDQo+ICAgIE5laWdoYm9yIERpc2Nv dmVyeSBbUkZDIDI0NjFdIG9ubHkgYWR2ZXJ0aXNlcyBhIHJvdXRlcidzIGxpbmstbG9jYWwgDQo+ ICAgIGFkZHJlc3MsIGJ5IHJlcXVpcmluZyB0aGlzIGFkZHJlc3MgdG8gYmUgdXNlZCBhcyB0aGUg SVAgU291cmNlIA0KPiAgICBBZGRyZXNzIG9mIGVhY2ggUm91dGVyIEFkdmVydGlzZW1lbnQuIEhl bmNlIGl0cyB1bmlxdWVuZXNzIGNhbid0IGJlIA0KPiAgICBndWFyYW50ZWVkIG91dHNpZGUgb2Yg YSBsaW5rLWluc3RhbmNlLiAgDQo+IA0KPiBUaGlzIGlzIG5vdCB0cnVlIGlmIHRoZSBSIGJpdCBp cyBzZXQgdGhlbiB0aGUgZnVsbCBJUCBhZGRyZXNzIGlzDQo+IGF2YWlsYWJsZSBhbmQgd2h5IGl0 IHdhcyBwdXQgYXMgb3B0aW9uIGluIE1JUHY2LiAgQnV0LCBmb3IgbW9zdCBub2RlcyBvbg0KPiBh IGxpbmsgdGhlIGRlZmF1bHQgaXMgdGhhdCByb3V0ZXJzIGRvIG5vdCBuZWVkIHRvIHN1cHBseSB0 aGUgZnVsbCBJUA0KPiBhZGRyZXNzIGluIFJBcy4gIEJ1dCwgdGhlcmUgaXMgYSBtZWFucyBhbmQg c3VwcG9ydCB0byByZXNvbHZlIHRoaXMNCj4gcHJvYmxlbSBmb3IgTW9iaWxpdHkuDQoNCkkgYWdy ZWUgdGhhdCBSIGJpdCBjYW4gc29sdmUgdGhpcyBpc3N1ZSBidXQgdGhlIGFib3ZlIHBhcnQgaXMg dG8gZGVzY3JpYmUgdGhlIHByb2JsZW1zLiANCllvdSBwcmVzZW50IHRoZSBzb2x1dGlvbiB0b28g ZWFybHkuIDotKSAgDQogDQpbT21pdHRlZF0gIA0KPiAgICBGb3IgdGhpcywgYSBob3N0IGNoZWNr cyB3aGV0aGVyIHRoZSBwcmVmaXggb2YgaXRzIElQIGFkZHJlc3MgaXMgaW4gDQo+ICAgIHRoZSBQ cmVmaXggSW5mb3JtYXRpb24gT3B0aW9uIG9mIFJvdXRlciBBZHZlcnRpc2VtZW50IG1lc3NhZ2Vz LiBCdXQgDQo+ICAgIGFuIHVuc29saWNpdGVkIFJvdXRlciBBZHZlcnRpc2VtZW50IG1lc3NhZ2Ug Y2FuIG9taXQgc29tZSBwcmVmaXhlcyANCj4gICAgZm9yIGNvbnZlbmllbmNlLCBmb3IgZXhhbXBs ZSB0byBzYXZlIHRoZSBiYW5kd2lkdGguICANCj4gDQo+IFRoZW4gdGhhdCBuZXR3b3JrIHdpbGwg c3VmZmVyIGFuZCBpZiB0aGUgbm9kZXMgcmVxdWlyZSB0aG9zZSBwcmVmaXhlcyBpdA0KPiBpcyBu b3QgYW4gb21taXNzaW9uIG9mIDI0NjEgYnV0IGJhZCBuZXR3b3JrIGNvbmZpZ3VyYXRpb24gYW5k IHBsYW5uaW5nDQo+IGJ5IHRoZSB1c2VyLg0KDQpJbiBjYXNlIG9mIG11bHRpcGxlIHByZWZpeGVz IG9uIGEgV0lSRUxFU1MgbGluaywgaXQgbWF5IHRha2UgdG9vIG11Y2ggYmFuZHdpZHRoIHRvIA0K YWR2ZXJ0aXNlIGFsbCB0aGUgcHJlZml4ZXMgYWxsIHRoZSB0aW1lLiAgDQogICAgIA0KPiAgICBT bywgY2hlY2tpbmcgdGhlIHByZWZpeGVzIGluIGFuIFJBLCBhbiBNTiBtYXkgbWFrZSBmYWxzZSBh c3N1bXB0aW9uIA0KPiAgICB0aGF0IHRoZSBwcmVmaXggb2YgaXRzIGN1cnJlbnQgSVAgYWRkcmVz cyBpcyBub3Qgc3VwcG9ydGVkIGluIGEgbmV3IA0KPiAgICBsaW5rLCB3aGlsZSB0aGF0IHByZWZp eCBpcyBqdXN0IG9taXR0ZWQgaW4gdGhhdCBwYXJ0aWN1bGFyIFJBLiANCj4gDQo+IEJ1dCB0aGlz IGlzIG5vdCB0aGUgZmF1bHQgb2YgMjQ2MSBhbmQgdGhlIFIgYml0IHdvcmtzIHdoZW4gdXNlZCBh bmQNCj4gcm91dGVycyBzdXBwb3J0aW5nIE1OcyBpbnRvIGl0cyBuZXR3b3JrIHNob3VsZCB1c2Ug dGhlIFIgYml0LiAgVGhlcmUgaXMNCj4gbm8gcHJvYmxlbS4NCg0KUiBiaXQgYnkgaXRzZWxmIGNh bid0IHNvbHZlIHRoaXMgcHJvYmxlbS4gQWZ0ZXIgTW92ZW1lbnQsIGlmIGFuIE1OIGNhbiBzdGls bCBoZWFyIGl0cyANCmN1cnJlbnQgZGVmYXVsdCByb3V0ZXIgKGNvbmZpcm1lZCB3aXRoIFIgYml0 KSwgaXQgY2FuIGFzc3VtZSB0aGF0IGl0cyBDb0EgaXMgc3RpbGwgdmFsaWQuIA0KQnV0IGlmIGFu IE1OIGRvZXNuJ3QgaGVhciBpdHMgY3VycmVudCBkZWZhdWx0IHJvdXRlciwgTU4gaXMgaW4gYSB0 cm91YmxlIGRlc2NyaWJlZCANCmFib3ZlLiANCiAgDQo+ICAgIE1vcmVvdmVyLCBldmVuIHRob3Vn aCBhIFJBIG1lc3NhZ2UgY29udGFpbnMgYWxsIHRoZSBQcmVmaXggDQo+ICAgIEluZm9ybWF0aW9u IE9wdGlvbnMsIGEgaG9zdCBoYXMgbm8gd2F5IHRvIGtub3cgaXQuIFRoZXJlIGlzIG5vIA0KPiAg ICBpbmRpY2F0aW9uLiANCj4gDQo+IFdoeT8gIFN1cmUgdGhleSBkbz8gDQoNCldoZW4gYSBSQSBh cnJpdmVzLCBhbiBNTiBjYW4ndCBiZSBzdXJlIHRoYXQgaXQgY29udGFpbnMgYWxsIHRoZSBwcmVm aXhlcy4gVGhlcmUgYWx3YXlzIGlzIA0KYSBwb3NzaWJpbGl0eSB0aGF0IGEgcHJlZml4IG1heSBi ZSBvbWl0dGVkIGluIHRoaXMgcGFydGljdWxhciBSQS4gDQogICAgIA0KPiAgICBIZW5jZSwgYSBo b3N0IGNhbid0IGJlIHN1cmUgdGhhdCB0aGUgcHJlZml4IG9mIGl0cyBjdXJyZW50IElQIGFkZHJl c3MNCj4gDQo+ICAgIGlzIG5vdCBzdXBwb3J0ZWQgb24gdGhlIGN1cnJlbnQgbGluaywgZXZlbiB0 aG91Z2ggdGhlIHByZWZpeCBpcyBub3QgDQo+ICAgIGNvbnRhaW5lZCBpbiBhbiBSQSBtZXNzYWdl LiANCj4gDQo+IFRoZXJlIGFyZSBjbGVhciBhZG1pbmlzdHJhdGlvbiBydWxlcyBmb3IgTU4gc3Vw cG9ydCBmb3IgTkQgYW5kIE1JUHY2DQo+IEV4dGVuc2lvbnMgdG8gTkQuIFRoZSBwcm9ibGVtIGlz IGRvIHdlIG5vdCBmZWVsIE1JUHY2IGRvY3VtZW50ZWQgdGhlc2UNCj4gd2VsbCBlbm91Z2ggb3Ig bm90Pw0KPiAgICAgDQo+ICAgIFRoZSBwcm9ibGVtIGlzIDEpIGFuIFJBIG1heSBvbWl0IHNvbWUg UHJlZml4IEluZm9ybWF0aW9uIE9wdGlvbnMgYW5kIA0KPiAgICAyKSBldmVuIGl0IGhhcyBhbGwg dGhlIFByZWZpeCBJbmZvcm1hdGlvbiBPcHRpb25zLCB0aGVyZSBpcyBubyANCj4gICAgaW5kaWNh dGlvbiB0aGF0IGl0IGRvZXMuIA0KPiANCj4gSSBjYW5ub3QgcGFyc2UgdGhlIGNvbmNsdXNpb24g Zm9yIDIpIGF0IGFsbD8NCg0KQXMgSSBkZXNjcmliZWQgYWJvdmUsIHRoZXJlIGlzIG5vIGluZGlj YXRpb24gaW4gYSBSQSB3aGljaCBub3RpZmllcyB0aGlzIFJBIGNvbnRhaW5zIGFsbCB0aGUgDQpw cmVmaXhlcy4gDQoNCj4gICAgVGhlIHBvc3NpYmxlIHNvbHV0aW9uIGZvciB0aGUgYWJvdmUgaXMg dGhlIFJBIHdpdGggIA0KPiAgICAxKSBBbGwgdGhlIFByZWZpeCBJbmZvcm1hdGlvbiBPcHRpb25z IGFuZCAgDQo+ICAgIDIpIFRoZSBpbmRpY2F0aW9uIHRoYXQgaXQgY29udGFpbnMgYWxsIHRoZSBQ cmVmaXggSW5mb3JtYXRpb24gDQo+ICAgICAgIE9wdGlvbnMuICANCj4gDQo+ICAgIEZvciAyKSwg d2UgbWF5IGRlZmluZSBhIG5ldyBiaXQgaW4gYW4gUkEgbWVzc2FnZS4gV2Ugd2lsbCBnaXZlIG1v cmUgDQo+ICAgIGRldGFpbCBpbiAzLjEuIA0KPiANCj4gVGhpcyBpcyBub3QgbmVjZXNzYXJ5IGFu ZCBoYXMgYmVlbiByZXNvbHZlZCBieSBNSVB2Ni4gDQogICAgDQpBY3R1YWxseSBtb2JpbGVpcCBX RyBkb2Vzbid0IGZlZWwgdGhhdCBNRCBpcyB1bmRlciBpdHMgd29yayBzY29wZSBlaXRoZXIuIEEg bmV3IFdHLCANCkROQSwgY3VycmVudGx5IEJvRiwgd2lsbCBkbyB0aGlzLiAuIA0KICAgICANCj4g Mi4zIExhY2sgb2YgU29saWNpdGF0aW9uIEFja25vd2xlZGdlbWVudCAgDQo+ICAgICANCj4gICAg SW4gUm91dGVyIEFkdmVydGlzZW1lbnQgbWVzc2FnZXMsIHRoZXJlIGlzIG5vIHNvbGljaXRhdGlv biBiaXQsIGFzIGluDQo+IA0KPiAgICBOZWlnaGJvciBBZHZlcnRpc2VtZW50LiBTbyB3aGVuIGEg bm9kZSByZWNlaXZlcyBhIFJBLCBpdCBjYW4ncyBiZSANCj4gICAgc3VyZSBpdCdzIHRoZSByZXBs eSB0byBpdHMgUm91dGVyIFNvbGljaXRhdGlvbi4gVG8gY29uZmlybSBiaS0NCj4gICAgZGlyZWN0 aW9uYWwgcmVhY2hhYmlsaXR5LCBhbiBhZGRpdGlvbmFsIE5TLyBOQSBleGNoYW5nZSBpcyBtYW5k YXRvcnkuDQo+IA0KPiBEbyBub3QgYWdyZWUuICBXaGVuIGEgbm9kZSBnZXRzIGFuIFJBIGl0IHRo ZW4gYmVnaW5zIGNvbW11bmljYXRpb24uICBJZg0KPiB0aGF0IGNvbW11bmljYXRpb25zIGZhaWxz IHRoZW4gdGhlIHJvdXRlciBpcyBkb3duIGFuZCBtdXN0IGJlIHJldHJpZWQgb3INCj4gbXVzdCBs b2NhdGUgYW5vdGhlciByb3V0ZXIuICBUaGUgSVB2NiBhcmNoaXRlY3R1cmUgZGlkIG5vdCBpbXBs ZW1lbnQNCj4gc3VjaCByZWFjYWJpbGl0eSB3aXRoIHJvdXRlcnMgZm9yIGEgZ29vZCByZWFzb24g YW5kIHRoYXQgaXMgdG8gc3VwcG9ydA0KPiByZWR1Y2VkIGRpc2NvdmVyeSBtZXNzYWdlcyBhbmQg YmFuZHdpZHRoIG9uIGFuIElQdjYgbGluay4gICANCg0KQ29ycmVjdCBtZSBpZiB3cm9uZy4gQnV0 IFJGQyAyNDYxIG1hbmRhdGVzIGhvc3RzIHRvIGNvbmZpcm0gcmVhY2hhYmlsaXR5IHdpdGggaXRz IGRlZmF1bHQgDQpyb3V0ZXIuIEFmdGVyIG1vdmVtZW50LCBob3N0cyBoYXZlIHRvIGNvbmZpcm0g cmVhY2hhYmlsaXR5IGFuZCBpdCBlbnRhaWxzIE5TLyBOQSBleGNoYW5nZS4NCiAgICAgDQpbT21p dHRlZF0gDQo+ICAgIEFjY29yZGluZyB0byBbUkZDIDI0NjFdLCBhIHJvdXRlciBtYXkgYWR2ZXJ0 aXNlIHByZWZpeGVzIHdpdGggTD0wIGFuZA0KPiANCj4gICAgQT0xLiBUaGlzIGltcGxpZXMgdGhh dCBzdGF0ZWxlc3MgYWRkcmVzcyBhdXRvY29uZmlndXJhdGlvbiBpcyBhbGxvd2VkDQo+IA0KPiAg ICBmb3IgdGhlc2UgcHJlZml4ZXMgW1JGQyAyNDYyXS4gSXQgaXMgcG9zc2libGUgdG8gc2hvdyB0 aGF0IGluIHRoZSANCj4gICAgYWJzZW5jZSBvZiBBZGRyZXNzIFN0YXRlIG9uIHJvdXRlcnMgb3Ig TkQgcHJveHlpbmcsIGR1cGxpY2F0ZSANCj4gICAgYWRkcmVzc2VzIG1heSBiZSBjb25maWd1cmVk IGZvciBhIGdsb2JhbCBhZGRyZXNzLCB3aGVuIGFuIGFkZHJlc3MgDQo+ICAgIG93bmVyIGV4aXN0 cyBvbiBhbm90aGVyIGxpbmsgb2YgdGhlIHNhbWUgc3VibmV0Lg0KPiANCj4gVGhpcyBpcyBwb2lu dCB0aGUgZHJhZnQgbWlzc2VkIGVhcmx5IG9uLiAgUm91dGVycyBjYW5ub3QgcHJvdmlkZSBzYW1l DQo+IHByZWZpeGVzIHRvIHR3byBzZXBhcmF0ZSBsaW5rcy4gDQoNClRoaXMgcG9pbnQgd2UnZCBi ZXR0ZXIgY2xhcmlmeS4gSSB0aGluayB0aGF0IFJvdXRlcnMgY2FuIHByb3ZpZGUgdGhlIHNhbWUg cHJlZml4IHRvIHR3byBzZXBhcmF0ZSANCmxpbmtzIHdoZW4gTCBiaXQgaWYgb2ZmLiBLaW5kbHkg Y2hlY2sgdGhlIGZvbGxvd2luZyBleGFtcGxlLiANCg0KQSByb3V0ZXIgaGFzIHR3byBpbnRlcmZh Y2VzIHRvIHdoaWNoIHR3byBzZXBhcmF0ZSBsaW5rIGFyZSBhdHRhY2hlZC4gRm9yIHRob3NlIGlu dGVyZmFjZXMsIHRoZSANCnJvdXRlciBhZHZlcnRpc2UgdGhlIHNhbWUgcHJlZml4IEE6OiB3aXRo IEwgYml0IG9mZi4gVGhlcmUgaXMgbm90aGluZyBpbiBSRkMgMjQ2MSB3aGljaCBiYW5zDQp0aGlz LiANCg0KICAgICAgICAgICAgICAgICAgICAgICAgICBfX19fDQogICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgIHwgICBSICAgfF9fX19f X19fX19fX19fX18gDQogICAgICAgICAgICAgICAgICAgICAgICAgfF9fX198ICAgICAgICAgICAg QTo6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgQTo6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgIA0K SSB0aGluayB0aGF0IHRoZSB1c2FnZSBvZiB0aGUgcHJlZml4IHdpdGggTCBiaXQgb2ZmIGlzIGEg bGl0dGxlIGFtYmlndW91cy4gV2UnZCBiZXR0ZXIgY2xhcmlmeSBpdC4gDQogDQo+IDMuIFJBIE9w dGltaXplZCBmb3IgTW92ZW1lbnQgRGV0ZWN0aW9uIA0KPiAgICAgDQo+ICAgIE91ciBnb2FsIGlz IHRvIGRlc2lnbiBhbiBSQSBpbiBzdWNoIGEgd2F5IHRoYXQgYW4gTU4gY2FuIGRldGVjdCBpdHMg DQo+ICAgIG1vdmVtZW50IGVmZmljaWVudGx5LCBxdWlja2x5IGFuZCBwcmVjaXNlbHkgd2l0aCBh cyBsaXR0bGUgc2lnbmFsaW5nIA0KPiAgICBhcyBwb3NzaWJsZS4gQXMgZGVzY3JpYmVkIGFib3Zl LCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIGEgDQo+ICAgIGN1cnJlbnQgUkEgbWVzc2Fn ZSBpcyBpbmNvbnNpc3RlbnQgYW5kIGluY29tcGxldGUgZm9yIG1vdmVtZW50IA0KPiAgICBkZXRl Y3Rpb24uIFRoZSBmb2xsb3dpbmcgcHJvcG9zYWxzIHNlZWsgdG8gZmFjaWxpdGF0ZSBlZmZpY2ll bnQgDQo+ICAgIG1vdmVtZW50IGRldGVjdGlvbiBieSBpbmNsdWRpbmcgYWxsIHRoZSBuZWNlc3Nh cnkgaW5mb3JtYXRpb24gaW4gYW4gDQo+ICAgIFJBIG1lc3NhZ2UuIA0KPiANCj4gVGhlcmUgaXMg bm8gcmVhc29uIGZvciB0aGlzIGRlc2lnbiBhbmQgdGhlIHByb2JsZW0gaGFzIGJlZW4gc29sdmVk IGJ5DQo+IE1JUHY2Lg0KDQpVbmZvcnR1bmF0ZWx5IHRoaXMgcHJvYmxlbSBoYXMgbm90IHNvbHZl ZCBieSBNSVB2Ni4gTmVpdGhlciBNSVA2IFdHIGlzIHRvIHdvcmsgb24gaXQuIA0KRE5BIGlzIHRv IGRlc2lnbiBhIHNvbHV0aW9uIGFuZCwgSSB0aGluaywgdGhpcyBpcyBhIHBhcnQgb2YgaXQuICAN CiANCj4gMy4xIENvbXBsZXRlIFJBICANCj4gICAgIA0KPiAgICBTaW5jZSByb3V0ZXJzIG1heSBu ZWdsZWN0IHRvIHNlbmQgYWxsIHByZWZpeGVzIGluIGV2ZXJ5DQo+IGFkdmVydGlzZW1lbnQsIA0K PiAgICBpdCBpcyBkaWZmaWN1bHQgZm9yIGFuIE1OIHRvIGRldGVybWluZSB3aGV0aGVyIGl0IGlz IGF0dGFjaGVkIHRvIGEgDQo+ICAgIGRpZmZlcmVudCBzdWJuZXQsIHdoZW4gYW4gUkEgcmVjZWl2 ZWQgd2l0aG91dCBpdHMgY3VycmVudGx5IA0KPiAgICBjb25maWd1cmVkIHByZWZpeC4gDQo+ICAg ICANCj4gICAgRXZlbiB0aG91Z2ggYW4gUkEgY29udGFpbnMgYWxsIHRoZSBQcmVmaXhlcywgYW4g TU4gaGFzIG5vIHdheSB0byBrbm93DQo+IA0KPiAgICBpdC4gVGhlcmUgaXMgbm8gaW5kaWNhdGlv bi4gU28gc3RpbGwgYW1iaWd1aXR5IHJlbWFpbnMuICANCj4gIA0KPiBTdXJlIGl0IGRvZXMgaWYg dGhlIFIgYml0IGlzIHNldCBmb3IgYSByb3V0ZXIgb3IgTCBiaXQgZm9yIGhvc3QNCj4gbm90aWZp Y2F0aW9uLg0KICAgICANCldlIGhhdmUgYSBkaXNhZ3JlZW1lbnQgaGVyZS4gUiBiaXQgYW5kIEwg Yml0IHRhbGsgb25seSBhYm91dCBqdXN0IG9uZSBwcmVmaXguIFRoZXkgZG9uJ3Qgc2F5IA0KYW55 dGhpbmcgYWJvdXQgdGhlIGNvbGxlY3Rpb24gb2YgYWxsIHByZWZpeGVzLiBJIGRvbid0IGtub3cg aG93LCB3aXRoIEwgYW5kIFIgYml0LCBhbiBNTiBjYW4gDQpiZSBzdXJlIGEgcGFydGljdWxhciBS QSBjb250YWlucyBhbGwgdGhlIHByZWZpeGVzLiANCg0KPiAgICBJZiBhIHJvdXRlciBpcyBhYmxl IHRvIHNlbmQgYW4gaW5kaWNhdGlvbiB0aGF0IHRoZSBSQSBpdCBzZW5kcyANCj4gICAgY29udGFp bnMgYWxsIG9mIHRoZSB2YWxpZCBwcmVmaXhlcyBmb3IgYSBsaW5rLWluc3RhbmNlLCB0aGVuIA0K PiAgICByZWNlcHRpb24gb2YgYW4gUkEgd2hpY2ggY29udGFpbnMgYSBkaWZmZXJlbnQgc2V0IG9m IHByZWZpeGVzIA0KPiAgICBpbmRpY2F0ZXMgdGhlIHByZXNlbmNlIG9mIGEgZGlmZmVyZW50IHN1 Ym5ldC4gIA0KPiANCj4gVGhpcyBpcyB0byBtdWNoIG92ZXJoZWFkIGFuZCB0aGUgUiBiaXQgYWxy ZWFkeSBkb2VzIHRoaXMgZmFyIGJldHRlciBhbmQNCj4gd2h5IE1JUHY2IFdHIGNvbnZlcmdlZCBv biB0aGUgc3VwcG9ydCBvZiB0aGlzIG5ldyBwcmVmaXggb3B0aW9uIGFuZCB3aHkNCj4gdGhlIElQ djYgV0cgc3VwcG9ydGVkIHRoZSBjaGFuZ2UuICBUaGlzIGRyYWZ0IGlzIHRyeWluZyB0byByZWlu dmVudCB0aGF0DQo+IHNvbHV0aW9uIGFuZCBpdCBpcyBub3QgbmVjZXNzYXJ5Lg0KDQpJTUhPLCB0 aGUgcHVycG9zZSBvZiBSIGJpdCBhbmQgQ29tcGxldGUgYml0IGlzIGRpZmZlcmVudC4gIA0KICAg ICANCltPbWl0dGVkXSANCj4gICAgRm9yIGVmZmljaWVudCBNb3ZlbWVudCBEZXRlY3Rpb24sIHdl IHByb3Bvc2UgYSBSQSB3aXRoICANCj4gICAgMSkgQVIncyBnbG9iYWwgSVAgYWRkcmVzcyB1c2lu ZyBSIGJpdCAgDQo+ICAgIDIpIEFsbCB0aGUgb3B0aW9ucyAoaW5jbHVkaW5nIGFsbCB0aGUgUHJl Zml4IEluZm9ybWF0aW9uIE9wdGlvbnMpIA0KPiAgICAzKSBUaGUgaW5kaWNhdGlvbiB0aGF0IGl0 IGhhcyBhbGwgdGhlIG9wdGlvbnMgKENvbXBsZXRlIGJpdCkgDQo+ICAgIDQpIFMgYml0IChTb2xp Y2l0YXRpb24gYml0KSB0byBjb25maXJtIHJlYWNoYWJpbGl0eSB3aXRob3V0IE5TLyBOQSANCj4g ICAgICAgZXhjaGFuZ2UgDQo+IA0KPiBJIGRvbid0IGFncmVlIHdpdGggdGhlIHJlYWNoYWJpbGl0 eSBzdWdnZXN0aW9uIGJ1dCBhbGwgdGhlIG90aGVycyBleGlzdA0KPiB0b2RheSBhbmQgd2hhdCBp cyBuZWVkZWQgaXMgdG8gZGVmaW5lIGEgcG9saWN5IHdoZW4gYWxsIHRoaXMgbXVzdA0KPiBleGVj dXRlLg0KDQpUaGVyZSBpcyBub3RoaW5nIGZvciAzKSwgdG8gaW5kaWNhdGUgdGhlIGNvbXBsZXRl bmVzcyBvZiBhIFJBLiAgDQoNCkFub3RoZXIgdGhhbmtzIGZvciB5b3VyIGRldGFpbGVkIGFuZCBo ZWxwZnVsIGNvbW1lbnRzLiBJdCBjbGFyaWZpZXMgbXkgdGhvdWdodHMuIA0KDQpCZXN0IHJlZ2Fy ZHMNCg0KSmluSHllb2NrDQoNCg== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Oct 25 11:00:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07609 for ; Sat, 25 Oct 2003 11:00:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADPtu-0006FV-Pt for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 11:00:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9PF0Mnf024015 for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 11:00:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADPtu-0006FG-Jd for ipv6-web-archive@optimus.ietf.org; Sat, 25 Oct 2003 11:00:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07582 for ; Sat, 25 Oct 2003 11:00:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADPts-0005nw-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 11:00:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADPtr-0005nt-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 11:00:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADPtc-00064u-Iq; Sat, 25 Oct 2003 11:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADPtT-00063o-2q for ipv6@optimus.ietf.org; Sat, 25 Oct 2003 10:59:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07560 for ; Sat, 25 Oct 2003 10:59:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADPtQ-0005nh-00 for ipv6@ietf.org; Sat, 25 Oct 2003 10:59:52 -0400 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1ADPtP-0005mZ-00 for ipv6@ietf.org; Sat, 25 Oct 2003 10:59:51 -0400 Received: from tyre (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.10/8.12.1) with SMTP id h9PEx9ls005221; Sat, 25 Oct 2003 23:59:10 +0900 (KST) Message-ID: <03c001c39b09$9988b4b0$ec2f024b@tyre> From: "JinHyeock Choi" To: "Bound, Jim" , References: <9C422444DE99BC46B3AD3C6EAFC9711B047CA18C@tayexc13.americas.cpqcorp.net> Subject: Re: Review Input: draft-jinchoi-ipv6-cra-00.txt Date: Sun, 26 Oct 2003 00:06:42 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: base64 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RGVhciBKaW0NCg0KVGhhbmtzIGZvciB5b3VyIGRldGFpbGVkIGNvbW1lbnRzLg0KDQpJIG1heSBu b3QgYmUgY2xlYXIgZW5vdWdoLiBUaGlzIEktRCBhc3N1bWVzIHRoZSBzY2VuYXJpbyBvZiBhIGhv c3QgbW92aW5nIGZyb20gb25lIGxpbmsgDQp0byBhbm90aGVyLiBJbiBtYW55IGNhc2VzLCB0aGUg dGVybSAnYSBob3N0L25vZGUnIGlzIGFjdHVhbGx5ICdhbiBNTicuDQoNCktpbmRseSBmaW5kIG15 IGluIGxpbmUgY29tbWVudHMuICAgDQoNCj4gQ29tbWVudHMgb24gdGhpcyBkcmFmdC4gIEkgYW0g dW5jbGVhciBidXQgaXQgbWF5IGJlIHRoaXMgd29yayBuZWVkcyB0bw0KPiBiZSBkb25lIGluIHRo ZSBtaXBzaG9wIFdHIHdpdGhpbiB0aGUgSW50ZXJuZXQgQXJlYSBhcyBJIGJlbGlldmUgYWxsIHRo YXQNCj4gaXMgcmVxdWlyZWQgdG8gcmVzb2x2ZSB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgaW4gdGhp cyBkcmFmdCBpcyBwb2xpY3kgdG8NCj4gdXNlIHRoZSBjdXJyZW50IE5EIDI0NjEgbWVjaGFuaXNt cyBhbmQgdGhlIGV4dGVuZGVkIE5EIG1lY2hhbmlzbXMgaW4NCj4gTUlQdjYuICBBcyB0aGUgV0cg bWF5IHJlYWxpemUgSSBkbyBub3Qgc3VwcG9ydCBtZXJnaW5nIE1JUHY2IE5EIGNoYW5nZXMNCj4g YmFjayBpbnRvIHRvIFJGQyAyNDYxIHNvIGRvIG5vdCBzZWUgbmVlZCBmb3IgdGhhdC4gIElmIHRo aXMgc3BlYyBpcyB0bw0KPiBkZWZpbmUgYW5kIGNsYXJpZnkgdGhlIHBvbGljeSBmb3IgdXNlIG9m IHRoZSBuZXcgcHJlZml4IG9wdGlvbiBpbiBNSVB2Ng0KPiBORCB0byBzZXQgUkEgUiBiaXQgdGhl biBJIHN1Z2dlc3QgdGhhdCBkaXNjdXNzaW9uIGJlIGluIG1pcHNob3AgV0cgd2hlcmUNCj4gdGhh dCBpcyB0aGVpciBmb2N1cy4gDQogDQpUaGFua3MgZm9yIHlvdXIgYWR2aWNlLiBJdCB3YXMgbm90 IGNsZWFyIHRvIG1lIHdoaWNoIFdHIGhhZCBtYW5kYXRlIG92ZXIgdGhpcyB3b3JrLiANCg0KPiAx LiBJbnRyb2R1Y3Rpb24gDQo+ICAgICANCj4gICAgTW92ZW1lbnQgZGV0ZWN0aW9uIChNRCkgaXMg b25lIG9mIGEgc2VyaWVzIG9mIHN0YWdlcyBpbiBhY2NvbXBsaXNoaW5nDQo+IA0KPiAgICBNSVB2 NiBoYW5kb3Zlci4gQXMgZGVmaW5lZCBpbiB0aGUgTUlQdjYgc3BlY2lmaWNhdGlvbiBbTUlQdjZd LCANCj4gICAgZGV0ZWN0aW9uIG9mIG1vdmVtZW50IGlzIGFjY29tcGxpc2hlZCB0aHJvdWdoIHJl Y2VwdGlvbiBvZiBSb3V0ZXIgDQo+ICAgIEFkdmVydGlzZW1lbnRzIChSQXMpIGFuZCBOZWlnaGJv ciBBZHZlcnRpc2VtZW50cyAoTkFzKSwgYW5kIA0KPiAgICBjb21wYXJpc29uIG9mIHRoZXNlIG1l c3NhZ2VzIHdpdGggcHJldmlvdXNseSByZWNlaXZlZCByb3V0ZXIgDQo+ICAgIGluZm9ybWF0aW9u LiANCj4gDQo+IExheWVyIDIgY2FuIGFsc28gbm90ZSBtb3ZlbWVudCBkZXRlY3Rpb24gYW5kIG1v cmUgcmVsaWFibGUgYW5kIGZhc3Rlcg0KPiB0b2RheS4gDQoNCkxheWVyIDIgY2FuIG9ubHkgZGV0 ZWN0IExpbmsgbGF5ZXIgY2hhbmdlLiBMYXllciAyIG1heSBhY3QgYXMgYSBoaW50IGJ1dCBjYW4n dCBjb25maXJtIA0KbW92ZW1lbnQuIEZvciBleGFtcGxlLCBsYXllciAyIGJ5IGl0c2VsZiBjYW4n dCBjaGVjayB0aGUgKHBhcnRpYWwpIHJlYWNoYWJpbGl0eSBvZiBjdXJyZW50IA0KZGVmYXVsdCBy b3V0ZXIuICANCiAgDQpbT21pdHRlZF0gICAgIA0KPiAyLjEgTGluayBsb2NhbCBzY29wZSBvZiBS b3V0ZXIgQWRkcmVzcyANCj4gIA0KPiAgICBUaGUgcm91dGVyIGFkZHJlc3MgY29udGFpbmVkIGlu IGFuIFJBIG1lc3NhZ2UgaXMgbGluay1sb2NhbCBzY29wZS4gDQo+ICAgIE5laWdoYm9yIERpc2Nv dmVyeSBbUkZDIDI0NjFdIG9ubHkgYWR2ZXJ0aXNlcyBhIHJvdXRlcidzIGxpbmstbG9jYWwgDQo+ ICAgIGFkZHJlc3MsIGJ5IHJlcXVpcmluZyB0aGlzIGFkZHJlc3MgdG8gYmUgdXNlZCBhcyB0aGUg SVAgU291cmNlIA0KPiAgICBBZGRyZXNzIG9mIGVhY2ggUm91dGVyIEFkdmVydGlzZW1lbnQuIEhl bmNlIGl0cyB1bmlxdWVuZXNzIGNhbid0IGJlIA0KPiAgICBndWFyYW50ZWVkIG91dHNpZGUgb2Yg YSBsaW5rLWluc3RhbmNlLiAgDQo+IA0KPiBUaGlzIGlzIG5vdCB0cnVlIGlmIHRoZSBSIGJpdCBp cyBzZXQgdGhlbiB0aGUgZnVsbCBJUCBhZGRyZXNzIGlzDQo+IGF2YWlsYWJsZSBhbmQgd2h5IGl0 IHdhcyBwdXQgYXMgb3B0aW9uIGluIE1JUHY2LiAgQnV0LCBmb3IgbW9zdCBub2RlcyBvbg0KPiBh IGxpbmsgdGhlIGRlZmF1bHQgaXMgdGhhdCByb3V0ZXJzIGRvIG5vdCBuZWVkIHRvIHN1cHBseSB0 aGUgZnVsbCBJUA0KPiBhZGRyZXNzIGluIFJBcy4gIEJ1dCwgdGhlcmUgaXMgYSBtZWFucyBhbmQg c3VwcG9ydCB0byByZXNvbHZlIHRoaXMNCj4gcHJvYmxlbSBmb3IgTW9iaWxpdHkuDQoNCkkgYWdy ZWUgdGhhdCBSIGJpdCBjYW4gc29sdmUgdGhpcyBpc3N1ZSBidXQgdGhlIGFib3ZlIHBhcnQgaXMg dG8gZGVzY3JpYmUgdGhlIHByb2JsZW1zLiANCllvdSBwcmVzZW50IHRoZSBzb2x1dGlvbiB0b28g ZWFybHkuIDotKSAgDQogDQpbT21pdHRlZF0gIA0KPiAgICBGb3IgdGhpcywgYSBob3N0IGNoZWNr cyB3aGV0aGVyIHRoZSBwcmVmaXggb2YgaXRzIElQIGFkZHJlc3MgaXMgaW4gDQo+ICAgIHRoZSBQ cmVmaXggSW5mb3JtYXRpb24gT3B0aW9uIG9mIFJvdXRlciBBZHZlcnRpc2VtZW50IG1lc3NhZ2Vz LiBCdXQgDQo+ICAgIGFuIHVuc29saWNpdGVkIFJvdXRlciBBZHZlcnRpc2VtZW50IG1lc3NhZ2Ug Y2FuIG9taXQgc29tZSBwcmVmaXhlcyANCj4gICAgZm9yIGNvbnZlbmllbmNlLCBmb3IgZXhhbXBs ZSB0byBzYXZlIHRoZSBiYW5kd2lkdGguICANCj4gDQo+IFRoZW4gdGhhdCBuZXR3b3JrIHdpbGwg c3VmZmVyIGFuZCBpZiB0aGUgbm9kZXMgcmVxdWlyZSB0aG9zZSBwcmVmaXhlcyBpdA0KPiBpcyBu b3QgYW4gb21taXNzaW9uIG9mIDI0NjEgYnV0IGJhZCBuZXR3b3JrIGNvbmZpZ3VyYXRpb24gYW5k IHBsYW5uaW5nDQo+IGJ5IHRoZSB1c2VyLg0KDQpJbiBjYXNlIG9mIG11bHRpcGxlIHByZWZpeGVz IG9uIGEgV0lSRUxFU1MgbGluaywgaXQgbWF5IHRha2UgdG9vIG11Y2ggYmFuZHdpZHRoIHRvIA0K YWR2ZXJ0aXNlIGFsbCB0aGUgcHJlZml4ZXMgYWxsIHRoZSB0aW1lLiAgDQogICAgIA0KPiAgICBT bywgY2hlY2tpbmcgdGhlIHByZWZpeGVzIGluIGFuIFJBLCBhbiBNTiBtYXkgbWFrZSBmYWxzZSBh c3N1bXB0aW9uIA0KPiAgICB0aGF0IHRoZSBwcmVmaXggb2YgaXRzIGN1cnJlbnQgSVAgYWRkcmVz cyBpcyBub3Qgc3VwcG9ydGVkIGluIGEgbmV3IA0KPiAgICBsaW5rLCB3aGlsZSB0aGF0IHByZWZp eCBpcyBqdXN0IG9taXR0ZWQgaW4gdGhhdCBwYXJ0aWN1bGFyIFJBLiANCj4gDQo+IEJ1dCB0aGlz IGlzIG5vdCB0aGUgZmF1bHQgb2YgMjQ2MSBhbmQgdGhlIFIgYml0IHdvcmtzIHdoZW4gdXNlZCBh bmQNCj4gcm91dGVycyBzdXBwb3J0aW5nIE1OcyBpbnRvIGl0cyBuZXR3b3JrIHNob3VsZCB1c2Ug dGhlIFIgYml0LiAgVGhlcmUgaXMNCj4gbm8gcHJvYmxlbS4NCg0KUiBiaXQgYnkgaXRzZWxmIGNh bid0IHNvbHZlIHRoaXMgcHJvYmxlbS4gQWZ0ZXIgTW92ZW1lbnQsIGlmIGFuIE1OIGNhbiBzdGls bCBoZWFyIGl0cyANCmN1cnJlbnQgZGVmYXVsdCByb3V0ZXIgKGNvbmZpcm1lZCB3aXRoIFIgYml0 KSwgaXQgY2FuIGFzc3VtZSB0aGF0IGl0cyBDb0EgaXMgc3RpbGwgdmFsaWQuIA0KQnV0IGlmIGFu IE1OIGRvZXNuJ3QgaGVhciBpdHMgY3VycmVudCBkZWZhdWx0IHJvdXRlciwgTU4gaXMgaW4gYSB0 cm91YmxlIGRlc2NyaWJlZCANCmFib3ZlLiANCiAgDQo+ICAgIE1vcmVvdmVyLCBldmVuIHRob3Vn aCBhIFJBIG1lc3NhZ2UgY29udGFpbnMgYWxsIHRoZSBQcmVmaXggDQo+ICAgIEluZm9ybWF0aW9u IE9wdGlvbnMsIGEgaG9zdCBoYXMgbm8gd2F5IHRvIGtub3cgaXQuIFRoZXJlIGlzIG5vIA0KPiAg ICBpbmRpY2F0aW9uLiANCj4gDQo+IFdoeT8gIFN1cmUgdGhleSBkbz8gDQoNCldoZW4gYSBSQSBh cnJpdmVzLCBhbiBNTiBjYW4ndCBiZSBzdXJlIHRoYXQgaXQgY29udGFpbnMgYWxsIHRoZSBwcmVm aXhlcy4gVGhlcmUgYWx3YXlzIGlzIA0KYSBwb3NzaWJpbGl0eSB0aGF0IGEgcHJlZml4IG1heSBi ZSBvbWl0dGVkIGluIHRoaXMgcGFydGljdWxhciBSQS4gDQogICAgIA0KPiAgICBIZW5jZSwgYSBo b3N0IGNhbid0IGJlIHN1cmUgdGhhdCB0aGUgcHJlZml4IG9mIGl0cyBjdXJyZW50IElQIGFkZHJl c3MNCj4gDQo+ICAgIGlzIG5vdCBzdXBwb3J0ZWQgb24gdGhlIGN1cnJlbnQgbGluaywgZXZlbiB0 aG91Z2ggdGhlIHByZWZpeCBpcyBub3QgDQo+ICAgIGNvbnRhaW5lZCBpbiBhbiBSQSBtZXNzYWdl LiANCj4gDQo+IFRoZXJlIGFyZSBjbGVhciBhZG1pbmlzdHJhdGlvbiBydWxlcyBmb3IgTU4gc3Vw cG9ydCBmb3IgTkQgYW5kIE1JUHY2DQo+IEV4dGVuc2lvbnMgdG8gTkQuIFRoZSBwcm9ibGVtIGlz IGRvIHdlIG5vdCBmZWVsIE1JUHY2IGRvY3VtZW50ZWQgdGhlc2UNCj4gd2VsbCBlbm91Z2ggb3Ig bm90Pw0KPiAgICAgDQo+ICAgIFRoZSBwcm9ibGVtIGlzIDEpIGFuIFJBIG1heSBvbWl0IHNvbWUg UHJlZml4IEluZm9ybWF0aW9uIE9wdGlvbnMgYW5kIA0KPiAgICAyKSBldmVuIGl0IGhhcyBhbGwg dGhlIFByZWZpeCBJbmZvcm1hdGlvbiBPcHRpb25zLCB0aGVyZSBpcyBubyANCj4gICAgaW5kaWNh dGlvbiB0aGF0IGl0IGRvZXMuIA0KPiANCj4gSSBjYW5ub3QgcGFyc2UgdGhlIGNvbmNsdXNpb24g Zm9yIDIpIGF0IGFsbD8NCg0KQXMgSSBkZXNjcmliZWQgYWJvdmUsIHRoZXJlIGlzIG5vIGluZGlj YXRpb24gaW4gYSBSQSB3aGljaCBub3RpZmllcyB0aGlzIFJBIGNvbnRhaW5zIGFsbCB0aGUgDQpw cmVmaXhlcy4gDQoNCj4gICAgVGhlIHBvc3NpYmxlIHNvbHV0aW9uIGZvciB0aGUgYWJvdmUgaXMg dGhlIFJBIHdpdGggIA0KPiAgICAxKSBBbGwgdGhlIFByZWZpeCBJbmZvcm1hdGlvbiBPcHRpb25z IGFuZCAgDQo+ICAgIDIpIFRoZSBpbmRpY2F0aW9uIHRoYXQgaXQgY29udGFpbnMgYWxsIHRoZSBQ cmVmaXggSW5mb3JtYXRpb24gDQo+ICAgICAgIE9wdGlvbnMuICANCj4gDQo+ICAgIEZvciAyKSwg d2UgbWF5IGRlZmluZSBhIG5ldyBiaXQgaW4gYW4gUkEgbWVzc2FnZS4gV2Ugd2lsbCBnaXZlIG1v cmUgDQo+ICAgIGRldGFpbCBpbiAzLjEuIA0KPiANCj4gVGhpcyBpcyBub3QgbmVjZXNzYXJ5IGFu ZCBoYXMgYmVlbiByZXNvbHZlZCBieSBNSVB2Ni4gDQogICAgDQpBY3R1YWxseSBtb2JpbGVpcCBX RyBkb2Vzbid0IGZlZWwgdGhhdCBNRCBpcyB1bmRlciBpdHMgd29yayBzY29wZSBlaXRoZXIuIEEg bmV3IFdHLCANCkROQSwgY3VycmVudGx5IEJvRiwgd2lsbCBkbyB0aGlzLiAuIA0KICAgICANCj4g Mi4zIExhY2sgb2YgU29saWNpdGF0aW9uIEFja25vd2xlZGdlbWVudCAgDQo+ICAgICANCj4gICAg SW4gUm91dGVyIEFkdmVydGlzZW1lbnQgbWVzc2FnZXMsIHRoZXJlIGlzIG5vIHNvbGljaXRhdGlv biBiaXQsIGFzIGluDQo+IA0KPiAgICBOZWlnaGJvciBBZHZlcnRpc2VtZW50LiBTbyB3aGVuIGEg bm9kZSByZWNlaXZlcyBhIFJBLCBpdCBjYW4ncyBiZSANCj4gICAgc3VyZSBpdCdzIHRoZSByZXBs eSB0byBpdHMgUm91dGVyIFNvbGljaXRhdGlvbi4gVG8gY29uZmlybSBiaS0NCj4gICAgZGlyZWN0 aW9uYWwgcmVhY2hhYmlsaXR5LCBhbiBhZGRpdGlvbmFsIE5TLyBOQSBleGNoYW5nZSBpcyBtYW5k YXRvcnkuDQo+IA0KPiBEbyBub3QgYWdyZWUuICBXaGVuIGEgbm9kZSBnZXRzIGFuIFJBIGl0IHRo ZW4gYmVnaW5zIGNvbW11bmljYXRpb24uICBJZg0KPiB0aGF0IGNvbW11bmljYXRpb25zIGZhaWxz IHRoZW4gdGhlIHJvdXRlciBpcyBkb3duIGFuZCBtdXN0IGJlIHJldHJpZWQgb3INCj4gbXVzdCBs b2NhdGUgYW5vdGhlciByb3V0ZXIuICBUaGUgSVB2NiBhcmNoaXRlY3R1cmUgZGlkIG5vdCBpbXBs ZW1lbnQNCj4gc3VjaCByZWFjYWJpbGl0eSB3aXRoIHJvdXRlcnMgZm9yIGEgZ29vZCByZWFzb24g YW5kIHRoYXQgaXMgdG8gc3VwcG9ydA0KPiByZWR1Y2VkIGRpc2NvdmVyeSBtZXNzYWdlcyBhbmQg YmFuZHdpZHRoIG9uIGFuIElQdjYgbGluay4gICANCg0KQ29ycmVjdCBtZSBpZiB3cm9uZy4gQnV0 IFJGQyAyNDYxIG1hbmRhdGVzIGhvc3RzIHRvIGNvbmZpcm0gcmVhY2hhYmlsaXR5IHdpdGggaXRz IGRlZmF1bHQgDQpyb3V0ZXIuIEFmdGVyIG1vdmVtZW50LCBob3N0cyBoYXZlIHRvIGNvbmZpcm0g cmVhY2hhYmlsaXR5IGFuZCBpdCBlbnRhaWxzIE5TLyBOQSBleGNoYW5nZS4NCiAgICAgDQpbT21p dHRlZF0gDQo+ICAgIEFjY29yZGluZyB0byBbUkZDIDI0NjFdLCBhIHJvdXRlciBtYXkgYWR2ZXJ0 aXNlIHByZWZpeGVzIHdpdGggTD0wIGFuZA0KPiANCj4gICAgQT0xLiBUaGlzIGltcGxpZXMgdGhh dCBzdGF0ZWxlc3MgYWRkcmVzcyBhdXRvY29uZmlndXJhdGlvbiBpcyBhbGxvd2VkDQo+IA0KPiAg ICBmb3IgdGhlc2UgcHJlZml4ZXMgW1JGQyAyNDYyXS4gSXQgaXMgcG9zc2libGUgdG8gc2hvdyB0 aGF0IGluIHRoZSANCj4gICAgYWJzZW5jZSBvZiBBZGRyZXNzIFN0YXRlIG9uIHJvdXRlcnMgb3Ig TkQgcHJveHlpbmcsIGR1cGxpY2F0ZSANCj4gICAgYWRkcmVzc2VzIG1heSBiZSBjb25maWd1cmVk IGZvciBhIGdsb2JhbCBhZGRyZXNzLCB3aGVuIGFuIGFkZHJlc3MgDQo+ICAgIG93bmVyIGV4aXN0 cyBvbiBhbm90aGVyIGxpbmsgb2YgdGhlIHNhbWUgc3VibmV0Lg0KPiANCj4gVGhpcyBpcyBwb2lu dCB0aGUgZHJhZnQgbWlzc2VkIGVhcmx5IG9uLiAgUm91dGVycyBjYW5ub3QgcHJvdmlkZSBzYW1l DQo+IHByZWZpeGVzIHRvIHR3byBzZXBhcmF0ZSBsaW5rcy4gDQoNClRoaXMgcG9pbnQgd2UnZCBi ZXR0ZXIgY2xhcmlmeS4gSSB0aGluayB0aGF0IFJvdXRlcnMgY2FuIHByb3ZpZGUgdGhlIHNhbWUg cHJlZml4IHRvIHR3byBzZXBhcmF0ZSANCmxpbmtzIHdoZW4gTCBiaXQgaWYgb2ZmLiBLaW5kbHkg Y2hlY2sgdGhlIGZvbGxvd2luZyBleGFtcGxlLiANCg0KQSByb3V0ZXIgaGFzIHR3byBpbnRlcmZh Y2VzIHRvIHdoaWNoIHR3byBzZXBhcmF0ZSBsaW5rIGFyZSBhdHRhY2hlZC4gRm9yIHRob3NlIGlu dGVyZmFjZXMsIHRoZSANCnJvdXRlciBhZHZlcnRpc2UgdGhlIHNhbWUgcHJlZml4IEE6OiB3aXRo IEwgYml0IG9mZi4gVGhlcmUgaXMgbm90aGluZyBpbiBSRkMgMjQ2MSB3aGljaCBiYW5zDQp0aGlz LiANCg0KICAgICAgICAgICAgICAgICAgICAgICAgICBfX19fDQogICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgIHwgICBSICAgfF9fX19f X19fX19fX19fX18gDQogICAgICAgICAgICAgICAgICAgICAgICAgfF9fX198ICAgICAgICAgICAg QTo6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgQTo6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgIA0K SSB0aGluayB0aGF0IHRoZSB1c2FnZSBvZiB0aGUgcHJlZml4IHdpdGggTCBiaXQgb2ZmIGlzIGEg bGl0dGxlIGFtYmlndW91cy4gV2UnZCBiZXR0ZXIgY2xhcmlmeSBpdC4gDQogDQo+IDMuIFJBIE9w dGltaXplZCBmb3IgTW92ZW1lbnQgRGV0ZWN0aW9uIA0KPiAgICAgDQo+ICAgIE91ciBnb2FsIGlz IHRvIGRlc2lnbiBhbiBSQSBpbiBzdWNoIGEgd2F5IHRoYXQgYW4gTU4gY2FuIGRldGVjdCBpdHMg DQo+ICAgIG1vdmVtZW50IGVmZmljaWVudGx5LCBxdWlja2x5IGFuZCBwcmVjaXNlbHkgd2l0aCBh cyBsaXR0bGUgc2lnbmFsaW5nIA0KPiAgICBhcyBwb3NzaWJsZS4gQXMgZGVzY3JpYmVkIGFib3Zl LCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIGEgDQo+ICAgIGN1cnJlbnQgUkEgbWVzc2Fn ZSBpcyBpbmNvbnNpc3RlbnQgYW5kIGluY29tcGxldGUgZm9yIG1vdmVtZW50IA0KPiAgICBkZXRl Y3Rpb24uIFRoZSBmb2xsb3dpbmcgcHJvcG9zYWxzIHNlZWsgdG8gZmFjaWxpdGF0ZSBlZmZpY2ll bnQgDQo+ICAgIG1vdmVtZW50IGRldGVjdGlvbiBieSBpbmNsdWRpbmcgYWxsIHRoZSBuZWNlc3Nh cnkgaW5mb3JtYXRpb24gaW4gYW4gDQo+ICAgIFJBIG1lc3NhZ2UuIA0KPiANCj4gVGhlcmUgaXMg bm8gcmVhc29uIGZvciB0aGlzIGRlc2lnbiBhbmQgdGhlIHByb2JsZW0gaGFzIGJlZW4gc29sdmVk IGJ5DQo+IE1JUHY2Lg0KDQpVbmZvcnR1bmF0ZWx5IHRoaXMgcHJvYmxlbSBoYXMgbm90IHNvbHZl ZCBieSBNSVB2Ni4gTmVpdGhlciBNSVA2IFdHIGlzIHRvIHdvcmsgb24gaXQuIA0KRE5BIGlzIHRv IGRlc2lnbiBhIHNvbHV0aW9uIGFuZCwgSSB0aGluaywgdGhpcyBpcyBhIHBhcnQgb2YgaXQuICAN CiANCj4gMy4xIENvbXBsZXRlIFJBICANCj4gICAgIA0KPiAgICBTaW5jZSByb3V0ZXJzIG1heSBu ZWdsZWN0IHRvIHNlbmQgYWxsIHByZWZpeGVzIGluIGV2ZXJ5DQo+IGFkdmVydGlzZW1lbnQsIA0K PiAgICBpdCBpcyBkaWZmaWN1bHQgZm9yIGFuIE1OIHRvIGRldGVybWluZSB3aGV0aGVyIGl0IGlz IGF0dGFjaGVkIHRvIGEgDQo+ICAgIGRpZmZlcmVudCBzdWJuZXQsIHdoZW4gYW4gUkEgcmVjZWl2 ZWQgd2l0aG91dCBpdHMgY3VycmVudGx5IA0KPiAgICBjb25maWd1cmVkIHByZWZpeC4gDQo+ICAg ICANCj4gICAgRXZlbiB0aG91Z2ggYW4gUkEgY29udGFpbnMgYWxsIHRoZSBQcmVmaXhlcywgYW4g TU4gaGFzIG5vIHdheSB0byBrbm93DQo+IA0KPiAgICBpdC4gVGhlcmUgaXMgbm8gaW5kaWNhdGlv bi4gU28gc3RpbGwgYW1iaWd1aXR5IHJlbWFpbnMuICANCj4gIA0KPiBTdXJlIGl0IGRvZXMgaWYg dGhlIFIgYml0IGlzIHNldCBmb3IgYSByb3V0ZXIgb3IgTCBiaXQgZm9yIGhvc3QNCj4gbm90aWZp Y2F0aW9uLg0KICAgICANCldlIGhhdmUgYSBkaXNhZ3JlZW1lbnQgaGVyZS4gUiBiaXQgYW5kIEwg Yml0IHRhbGsgb25seSBhYm91dCBqdXN0IG9uZSBwcmVmaXguIFRoZXkgZG9uJ3Qgc2F5IA0KYW55 dGhpbmcgYWJvdXQgdGhlIGNvbGxlY3Rpb24gb2YgYWxsIHByZWZpeGVzLiBJIGRvbid0IGtub3cg aG93LCB3aXRoIEwgYW5kIFIgYml0LCBhbiBNTiBjYW4gDQpiZSBzdXJlIGEgcGFydGljdWxhciBS QSBjb250YWlucyBhbGwgdGhlIHByZWZpeGVzLiANCg0KPiAgICBJZiBhIHJvdXRlciBpcyBhYmxl IHRvIHNlbmQgYW4gaW5kaWNhdGlvbiB0aGF0IHRoZSBSQSBpdCBzZW5kcyANCj4gICAgY29udGFp bnMgYWxsIG9mIHRoZSB2YWxpZCBwcmVmaXhlcyBmb3IgYSBsaW5rLWluc3RhbmNlLCB0aGVuIA0K PiAgICByZWNlcHRpb24gb2YgYW4gUkEgd2hpY2ggY29udGFpbnMgYSBkaWZmZXJlbnQgc2V0IG9m IHByZWZpeGVzIA0KPiAgICBpbmRpY2F0ZXMgdGhlIHByZXNlbmNlIG9mIGEgZGlmZmVyZW50IHN1 Ym5ldC4gIA0KPiANCj4gVGhpcyBpcyB0byBtdWNoIG92ZXJoZWFkIGFuZCB0aGUgUiBiaXQgYWxy ZWFkeSBkb2VzIHRoaXMgZmFyIGJldHRlciBhbmQNCj4gd2h5IE1JUHY2IFdHIGNvbnZlcmdlZCBv biB0aGUgc3VwcG9ydCBvZiB0aGlzIG5ldyBwcmVmaXggb3B0aW9uIGFuZCB3aHkNCj4gdGhlIElQ djYgV0cgc3VwcG9ydGVkIHRoZSBjaGFuZ2UuICBUaGlzIGRyYWZ0IGlzIHRyeWluZyB0byByZWlu dmVudCB0aGF0DQo+IHNvbHV0aW9uIGFuZCBpdCBpcyBub3QgbmVjZXNzYXJ5Lg0KDQpJTUhPLCB0 aGUgcHVycG9zZSBvZiBSIGJpdCBhbmQgQ29tcGxldGUgYml0IGlzIGRpZmZlcmVudC4gIA0KICAg ICANCltPbWl0dGVkXSANCj4gICAgRm9yIGVmZmljaWVudCBNb3ZlbWVudCBEZXRlY3Rpb24sIHdl IHByb3Bvc2UgYSBSQSB3aXRoICANCj4gICAgMSkgQVIncyBnbG9iYWwgSVAgYWRkcmVzcyB1c2lu ZyBSIGJpdCAgDQo+ICAgIDIpIEFsbCB0aGUgb3B0aW9ucyAoaW5jbHVkaW5nIGFsbCB0aGUgUHJl Zml4IEluZm9ybWF0aW9uIE9wdGlvbnMpIA0KPiAgICAzKSBUaGUgaW5kaWNhdGlvbiB0aGF0IGl0 IGhhcyBhbGwgdGhlIG9wdGlvbnMgKENvbXBsZXRlIGJpdCkgDQo+ICAgIDQpIFMgYml0IChTb2xp Y2l0YXRpb24gYml0KSB0byBjb25maXJtIHJlYWNoYWJpbGl0eSB3aXRob3V0IE5TLyBOQSANCj4g ICAgICAgZXhjaGFuZ2UgDQo+IA0KPiBJIGRvbid0IGFncmVlIHdpdGggdGhlIHJlYWNoYWJpbGl0 eSBzdWdnZXN0aW9uIGJ1dCBhbGwgdGhlIG90aGVycyBleGlzdA0KPiB0b2RheSBhbmQgd2hhdCBp cyBuZWVkZWQgaXMgdG8gZGVmaW5lIGEgcG9saWN5IHdoZW4gYWxsIHRoaXMgbXVzdA0KPiBleGVj dXRlLg0KDQpUaGVyZSBpcyBub3RoaW5nIGZvciAzKSwgdG8gaW5kaWNhdGUgdGhlIGNvbXBsZXRl bmVzcyBvZiBhIFJBLiAgDQoNCkFub3RoZXIgdGhhbmtzIGZvciB5b3VyIGRldGFpbGVkIGFuZCBo ZWxwZnVsIGNvbW1lbnRzLiBJdCBjbGFyaWZpZXMgbXkgdGhvdWdodHMuIA0KDQpCZXN0IHJlZ2Fy ZHMNCg0KSmluSHllb2NrDQo= -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Oct 25 13:11:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09941 for ; Sat, 25 Oct 2003 13:11:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADRwt-0007zv-1p for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 13:11:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9PHBZHt030744 for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 13:11:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADRws-0007zn-Rv for ipv6-web-archive@optimus.ietf.org; Sat, 25 Oct 2003 13:11:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09906 for ; Sat, 25 Oct 2003 13:11:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADRwq-0007bF-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 13:11:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADRwq-0007bC-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 13:11:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADRwM-0007sl-Ge; Sat, 25 Oct 2003 13:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADRvu-0007rV-Nu for ipv6@optimus.ietf.org; Sat, 25 Oct 2003 13:10:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09897 for ; Sat, 25 Oct 2003 13:10:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADRvs-0007b2-00 for ipv6@ietf.org; Sat, 25 Oct 2003 13:10:32 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1ADRvs-0007az-00 for ipv6@ietf.org; Sat, 25 Oct 2003 13:10:32 -0400 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9PHAOed051044; Sat, 25 Oct 2003 19:10:24 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <3F99C926.3090200@iprg.nokia.com> References: <3F99C926.3090200@iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <23720522-070E-11D8-BE4E-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org From: Iljitsch van Beijnum Subject: draft-templin-tunnelmtu-01.txt Date: Sat, 25 Oct 2003 19:10:31 +0200 To: Fred Templin X-Mailer: Apple Mail (2.604) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 25 okt 2003, at 2:51, Fred Templin wrote: > General comment - it would be nice if folks would reveiw and comment > on my drafts: > http://www.ietf.org/internet-drafts/draft-templin-ndiscmtu-00.txt > http://www.ietf.org/internet-drafts/draft-templin-tunnelmtu-01.txt Ok, the second one first: As far as I can tell, not being someone who builds routers, some of the mechanisms outlined here are problematic. For instance, determining whether the IP packet that carries a tunneled packet was fragmented means transferring information from one place in the architecture (reception and reassembly of IP packets) to another (handling protocol 41). Another: doing a router sollicitation triggered by wanting to transmit a packet of a certain size is not a good thing. But why bother in the first place? Presonally, I would happily let my tunnel packets be fragmented as this way I don't incur a reduced MTU when using a tunnel. Sure, this costs extra CPU time for the tunnel endpoints but in most cases this isn't a problem. And when it is, the tunnel endpoints should be able to do PMTUD over the tunnel. And if that doesn't work, it's always possible to configure a smaller MTU. Don't forget that tunnels are typically pretty static so once everything is set up, there shouldn't be too many surprises. I think this draft is solving a non-problem. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Oct 25 14:39:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11986 for ; Sat, 25 Oct 2003 14:39:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADTJv-00070T-SS for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 14:39:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9PIdRR1026929 for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 14:39:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADTJv-00070G-Np for ipv6-web-archive@optimus.ietf.org; Sat, 25 Oct 2003 14:39:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11968 for ; Sat, 25 Oct 2003 14:39:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADTJt-00014L-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 14:39:25 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADTJs-00014I-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 14:39:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADTJW-0006ti-9q; Sat, 25 Oct 2003 14:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADTIg-0006qg-TP for ipv6@optimus.ietf.org; Sat, 25 Oct 2003 14:38:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11935 for ; Sat, 25 Oct 2003 14:37:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADTIe-00012d-00 for ipv6@ietf.org; Sat, 25 Oct 2003 14:38:08 -0400 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by ietf-mx with esmtp (Exim 4.12) id 1ADTId-00012Z-00 for ipv6@ietf.org; Sat, 25 Oct 2003 14:38:07 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id AD8A21125B; Sat, 25 Oct 2003 14:38:07 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 25 Oct 2003 14:38:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-syam-ipv6-state-model-00.txt Date: Sat, 25 Oct 2003 14:38:07 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B051221BA@tayexc13.americas.cpqcorp.net> Thread-Topic: draft-syam-ipv6-state-model-00.txt Thread-Index: AcOasJRT8eCWZkdJRde4l55zii+z/wAdomvg From: "Bound, Jim" To: "Soohong Daniel Park" , Cc: "O.L.N.Rao" X-OriginalArrivalTime: 25 Oct 2003 18:38:07.0526 (UTC) FILETIME=[22231460:01C39B27] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I believe it should have ietf in its name yes. /jim > -----Original Message----- > From: Soohong Daniel Park [mailto:soohong.park@samsung.com]=20 > Sent: Saturday, October 25, 2003 12:29 AM > To: Bound, Jim; ipv6@ietf.org > Cc: 'O.L.N.Rao'; 'Soohong Daniel Park' > Subject: RE: draft-syam-ipv6-state-model-00.txt >=20 >=20 > Hello Jim >=20 > > I have read this spec and don't see bugs at this point. Is this=20 > > document to feed work on MIB definitions for SNMP and network=20 > > management? Or just to describe as information the various=20 > states in=20 > > the draft? >=20 > The original intent is to be a Informational RFC as a result > of our implementation but there is no any wall to refer=20 > this document. As you indicated, no bug is there. >=20 > Shoud this document have "ietf" in its name ? >=20 >=20 > Regards >=20 > Daniel (Soohong Daniel Park) > Mobile Platform Laboratory, SAMSUNG Electronics=20 >=20 > > -----Original Message----- > > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On > > Behalf Of Bound, Jim > > Sent: Saturday, October 25, 2003 3:28 AM > > To: ipv6@ietf.org > > Subject: draft-syam-ipv6-state-model-00.txt > >=20 > >=20 >=20 > >=20 > > /jim > >=20 > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > >=20 >=20 >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Oct 25 14:53:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12246 for ; Sat, 25 Oct 2003 14:53:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADTX8-0008Rc-TJ for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 14:53:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9PIr6DO032454 for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 14:53:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADTX8-0008RN-Mv for ipv6-web-archive@optimus.ietf.org; Sat, 25 Oct 2003 14:53:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12224 for ; Sat, 25 Oct 2003 14:52:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADTX5-0001Jd-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 14:53:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADTX5-0001Ja-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 14:53:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADTX3-0008NW-Jj; Sat, 25 Oct 2003 14:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADTW7-0008LE-EN for ipv6@optimus.ietf.org; Sat, 25 Oct 2003 14:52:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12220 for ; Sat, 25 Oct 2003 14:51:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADTW4-0001J0-00 for ipv6@ietf.org; Sat, 25 Oct 2003 14:52:00 -0400 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by ietf-mx with esmtp (Exim 4.12) id 1ADTW3-0001Ix-00 for ipv6@ietf.org; Sat, 25 Oct 2003 14:51:59 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 0F49A13A0C; Sat, 25 Oct 2003 14:52:00 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 25 Oct 2003 14:51:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: A list of issues for RFC2462 update Date: Sat, 25 Oct 2003 14:51:59 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA198@tayexc13.americas.cpqcorp.net> Thread-Topic: A list of issues for RFC2462 update Thread-Index: AcObB4rvNEaWYP1rQhS/NaApxgbezwAIFZcQ From: "Bound, Jim" To: "JinHyeock Choi" , X-OriginalArrivalTime: 25 Oct 2003 18:51:59.0884 (UTC) FILETIME=[1242D4C0:01C39B29] Content-Transfer-Encoding: base64 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RGVhciBKaW5IeWVvY2ssDQoNCkkgd2lsbCBnbyBvZmZsaW5lIHdpdGggeW91IGFzIEkgdGhpbmsg d2UgbmVlZCB0byBkZWVwIGRpdmUgdGVjaG5pY2FsbHkgYW5kIGl0IHdpbGwgdGFrZSBtYW55IGVt YWlscyBmb3IgeW91IGFuZCBJIHRvIHBhcnNlIHRoaXMgdmlhIGVtYWlsIGlzIG15IGd1ZXNzLiAg R2l2ZW4gdGhlIElFVEYgQURzIGFuZCBDaGFpcnMgd2lzaCB0byByZWR1Y2UgZW1haWwgZmxvdyBh bmQgb24gb3VyIG1lbWJlcnMgbWFpbCBpbmJveGVzIEkgc3VnZ2VzdCB3ZSBnbyBvZmZsaW5lIGFu ZCB0ZWNobmljYWxsbHkgd29yayBvdXQgb3VyIGRpc2Nvbm5lY3RzIGFuZCBhc3N1bXB0aW9ucyBh Ym91dCBNRCByZXF1aXJlbWVudHMgZm9yIFJBcy4gIFRoZW4gY29tZSBiYWNrIHRvIHRoZSBJUHY2 IFdHIHdoZW4gd2UgYXJlIGRvbmUgd2l0aCB0aGUgcmVzdWx0cy4gQXMgd2UgYXJlIGJvdGggaW1w bGVtZW50b3JzIHRoaXMgd2lsbCBiZSBhIHZlcnkgdXNlZnVsIGRpc2N1c3Npb24gYW5kIGludGVn cmF0aW9uIG9mIG91ciB2aWV3cy4gQXMgYSBub3RlIHRoZSBETkEgQk9GIGlzIHZlcnkgaW1wb3J0 YW50IEkgYWdyZWUsIEkgd2lsbCBiZSB0aGVyZSBpZiBJIGFtIGFsaXZlIGF0IHRoYXQgdGltZS4N Cg0KUmVzcGVjdGZ1bGx5LA0KL2ppbQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IGlwdjYtYWRtaW5AaWV0Zi5vcmcgW21haWx0bzppcHY2LWFkbWluQGlldGYub3JnXSBP biANCj4gQmVoYWxmIE9mIEppbkh5ZW9jayBDaG9pDQo+IFNlbnQ6IFNhdHVyZGF5LCBPY3RvYmVy IDI1LCAyMDAzIDEwOjU3IEFNDQo+IFRvOiBpcHY2QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBB IGxpc3Qgb2YgaXNzdWVzIGZvciBSRkMyNDYyIHVwZGF0ZQ0KPiANCj4gDQo+IERlYXIgSmltDQo+ IA0KPiBUaGFua3MgZm9yIHlvdXIgZGV0YWlsZWQgY29tbWVudHMuDQo+IA0KPiBJIG1heSBub3Qg YmUgY2xlYXIgZW5vdWdoLiBUaGlzIEktRCBhc3N1bWVzIHRoZSBzY2VuYXJpbyBvZiBhIA0KPiBo b3N0IG1vdmluZyBmcm9tIG9uZSBsaW5rIA0KPiB0byBhbm90aGVyLiBJbiBtYW55IGNhc2VzLCB0 aGUgdGVybSAnYSBob3N0L25vZGUnIGlzIGFjdHVhbGx5ICdhbiBNTicuDQo+IA0KPiBLaW5kbHkg ZmluZCBteSBpbiBsaW5lIGNvbW1lbnRzLiAgIA0KPiANCj4gPiBDb21tZW50cyBvbiB0aGlzIGRy YWZ0LiAgSSBhbSB1bmNsZWFyIGJ1dCBpdCBtYXkgYmUgdGhpcyANCj4gd29yayBuZWVkcyB0byAN Cj4gPiBiZSBkb25lIGluIHRoZSBtaXBzaG9wIFdHIHdpdGhpbiB0aGUgSW50ZXJuZXQgQXJlYSBh cyBJIGJlbGlldmUgYWxsIA0KPiA+IHRoYXQgaXMgcmVxdWlyZWQgdG8gcmVzb2x2ZSB0aGUgcHJv YmxlbSBzdGF0ZW1lbnQgaW4gdGhpcyBkcmFmdCBpcyANCj4gPiBwb2xpY3kgdG8gdXNlIHRoZSBj dXJyZW50IE5EIDI0NjEgbWVjaGFuaXNtcyBhbmQgdGhlIGV4dGVuZGVkIE5EIA0KPiA+IG1lY2hh bmlzbXMgaW4gTUlQdjYuICBBcyB0aGUgV0cgbWF5IHJlYWxpemUgSSBkbyBub3QgDQo+IHN1cHBv cnQgbWVyZ2luZyANCj4gPiBNSVB2NiBORCBjaGFuZ2VzIGJhY2sgaW50byB0byBSRkMgMjQ2MSBz byBkbyBub3Qgc2VlIG5lZWQgDQo+IGZvciB0aGF0LiAgDQo+ID4gSWYgdGhpcyBzcGVjIGlzIHRv IGRlZmluZSBhbmQgY2xhcmlmeSB0aGUgcG9saWN5IGZvciB1c2Ugb2YgdGhlIG5ldyANCj4gPiBw cmVmaXggb3B0aW9uIGluIE1JUHY2IE5EIHRvIHNldCBSQSBSIGJpdCB0aGVuIEkgc3VnZ2VzdCB0 aGF0IA0KPiA+IGRpc2N1c3Npb24gYmUgaW4gbWlwc2hvcCBXRyB3aGVyZSB0aGF0IGlzIHRoZWly IGZvY3VzLg0KPiAgDQo+IFRoYW5rcyBmb3IgeW91ciBhZHZpY2UuIEl0IHdhcyBub3QgY2xlYXIg dG8gbWUgd2hpY2ggV0cgaGFkIA0KPiBtYW5kYXRlIG92ZXIgdGhpcyB3b3JrLiANCj4gDQo+ID4g MS4gSW50cm9kdWN0aW9uDQo+ID4gICAgIA0KPiA+ICAgIE1vdmVtZW50IGRldGVjdGlvbiAoTUQp IGlzIG9uZSBvZiBhIHNlcmllcyBvZiBzdGFnZXMgaW4gDQo+ID4gYWNjb21wbGlzaGluZw0KPiA+ IA0KPiA+ICAgIE1JUHY2IGhhbmRvdmVyLiBBcyBkZWZpbmVkIGluIHRoZSBNSVB2NiBzcGVjaWZp Y2F0aW9uIFtNSVB2Nl0sIA0KPiA+ICAgIGRldGVjdGlvbiBvZiBtb3ZlbWVudCBpcyBhY2NvbXBs aXNoZWQgdGhyb3VnaCByZWNlcHRpb24gDQo+IG9mIFJvdXRlciANCj4gPiAgICBBZHZlcnRpc2Vt ZW50cyAoUkFzKSBhbmQgTmVpZ2hib3IgQWR2ZXJ0aXNlbWVudHMgKE5BcyksIGFuZCANCj4gPiAg ICBjb21wYXJpc29uIG9mIHRoZXNlIG1lc3NhZ2VzIHdpdGggcHJldmlvdXNseSByZWNlaXZlZCBy b3V0ZXIgDQo+ID4gICAgaW5mb3JtYXRpb24uDQo+ID4gDQo+ID4gTGF5ZXIgMiBjYW4gYWxzbyBu b3RlIG1vdmVtZW50IGRldGVjdGlvbiBhbmQgbW9yZSByZWxpYWJsZSANCj4gYW5kIGZhc3RlciAN Cj4gPiB0b2RheS4NCj4gDQo+IExheWVyIDIgY2FuIG9ubHkgZGV0ZWN0IExpbmsgbGF5ZXIgY2hh bmdlLiBMYXllciAyIG1heSBhY3QgYXMgDQo+IGEgaGludCBidXQgY2FuJ3QgY29uZmlybSANCj4g bW92ZW1lbnQuIEZvciBleGFtcGxlLCBsYXllciAyIGJ5IGl0c2VsZiBjYW4ndCBjaGVjayB0aGUg DQo+IChwYXJ0aWFsKSByZWFjaGFiaWxpdHkgb2YgY3VycmVudCANCj4gZGVmYXVsdCByb3V0ZXIu ICANCj4gICANCj4gW09taXR0ZWRdICAgICANCj4gPiAyLjEgTGluayBsb2NhbCBzY29wZSBvZiBS b3V0ZXIgQWRkcmVzcw0KPiA+ICANCj4gPiAgICBUaGUgcm91dGVyIGFkZHJlc3MgY29udGFpbmVk IGluIGFuIFJBIG1lc3NhZ2UgaXMgDQo+IGxpbmstbG9jYWwgc2NvcGUuIA0KPiA+ICAgIE5laWdo Ym9yIERpc2NvdmVyeSBbUkZDIDI0NjFdIG9ubHkgYWR2ZXJ0aXNlcyBhIHJvdXRlcidzIA0KPiBs aW5rLWxvY2FsIA0KPiA+ICAgIGFkZHJlc3MsIGJ5IHJlcXVpcmluZyB0aGlzIGFkZHJlc3MgdG8g YmUgdXNlZCBhcyB0aGUgSVAgU291cmNlIA0KPiA+ICAgIEFkZHJlc3Mgb2YgZWFjaCBSb3V0ZXIg QWR2ZXJ0aXNlbWVudC4gSGVuY2UgaXRzIA0KPiB1bmlxdWVuZXNzIGNhbid0IGJlIA0KPiA+ICAg IGd1YXJhbnRlZWQgb3V0c2lkZSBvZiBhIGxpbmstaW5zdGFuY2UuDQo+ID4gDQo+ID4gVGhpcyBp cyBub3QgdHJ1ZSBpZiB0aGUgUiBiaXQgaXMgc2V0IHRoZW4gdGhlIGZ1bGwgSVAgYWRkcmVzcyBp cyANCj4gPiBhdmFpbGFibGUgYW5kIHdoeSBpdCB3YXMgcHV0IGFzIG9wdGlvbiBpbiBNSVB2Ni4g IEJ1dCwgZm9yIA0KPiBtb3N0IG5vZGVzIA0KPiA+IG9uIGEgbGluayB0aGUgZGVmYXVsdCBpcyB0 aGF0IHJvdXRlcnMgZG8gbm90IG5lZWQgdG8gc3VwcGx5IA0KPiB0aGUgZnVsbCANCj4gPiBJUCBh ZGRyZXNzIGluIFJBcy4gIEJ1dCwgdGhlcmUgaXMgYSBtZWFucyBhbmQgc3VwcG9ydCB0byANCj4g cmVzb2x2ZSB0aGlzIA0KPiA+IHByb2JsZW0gZm9yIE1vYmlsaXR5Lg0KPiANCj4gSSBhZ3JlZSB0 aGF0IFIgYml0IGNhbiBzb2x2ZSB0aGlzIGlzc3VlIGJ1dCB0aGUgYWJvdmUgcGFydCBpcyANCj4g dG8gZGVzY3JpYmUgdGhlIHByb2JsZW1zLiANCj4gWW91IHByZXNlbnQgdGhlIHNvbHV0aW9uIHRv byBlYXJseS4gOi0pICANCj4gIA0KPiBbT21pdHRlZF0gIA0KPiA+ICAgIEZvciB0aGlzLCBhIGhv c3QgY2hlY2tzIHdoZXRoZXIgdGhlIHByZWZpeCBvZiBpdHMgSVAgDQo+IGFkZHJlc3MgaXMgaW4g DQo+ID4gICAgdGhlIFByZWZpeCBJbmZvcm1hdGlvbiBPcHRpb24gb2YgUm91dGVyIEFkdmVydGlz ZW1lbnQgDQo+IG1lc3NhZ2VzLiBCdXQgDQo+ID4gICAgYW4gdW5zb2xpY2l0ZWQgUm91dGVyIEFk dmVydGlzZW1lbnQgbWVzc2FnZSBjYW4gb21pdCANCj4gc29tZSBwcmVmaXhlcyANCj4gPiAgICBm b3IgY29udmVuaWVuY2UsIGZvciBleGFtcGxlIHRvIHNhdmUgdGhlIGJhbmR3aWR0aC4NCj4gPiAN Cj4gPiBUaGVuIHRoYXQgbmV0d29yayB3aWxsIHN1ZmZlciBhbmQgaWYgdGhlIG5vZGVzIHJlcXVp cmUgDQo+IHRob3NlIHByZWZpeGVzIA0KPiA+IGl0IGlzIG5vdCBhbiBvbW1pc3Npb24gb2YgMjQ2 MSBidXQgYmFkIG5ldHdvcmsgY29uZmlndXJhdGlvbiBhbmQgDQo+ID4gcGxhbm5pbmcgYnkgdGhl IHVzZXIuDQo+IA0KPiBJbiBjYXNlIG9mIG11bHRpcGxlIHByZWZpeGVzIG9uIGEgV0lSRUxFU1Mg bGluaywgaXQgbWF5IHRha2UgDQo+IHRvbyBtdWNoIGJhbmR3aWR0aCB0byANCj4gYWR2ZXJ0aXNl IGFsbCB0aGUgcHJlZml4ZXMgYWxsIHRoZSB0aW1lLiAgDQo+ICAgICAgDQo+ID4gICAgU28sIGNo ZWNraW5nIHRoZSBwcmVmaXhlcyBpbiBhbiBSQSwgYW4gTU4gbWF5IG1ha2UgZmFsc2UgDQo+IGFz c3VtcHRpb24gDQo+ID4gICAgdGhhdCB0aGUgcHJlZml4IG9mIGl0cyBjdXJyZW50IElQIGFkZHJl c3MgaXMgbm90IA0KPiBzdXBwb3J0ZWQgaW4gYSBuZXcgDQo+ID4gICAgbGluaywgd2hpbGUgdGhh dCBwcmVmaXggaXMganVzdCBvbWl0dGVkIGluIHRoYXQgcGFydGljdWxhciBSQS4NCj4gPiANCj4g PiBCdXQgdGhpcyBpcyBub3QgdGhlIGZhdWx0IG9mIDI0NjEgYW5kIHRoZSBSIGJpdCB3b3JrcyB3 aGVuIHVzZWQgYW5kIA0KPiA+IHJvdXRlcnMgc3VwcG9ydGluZyBNTnMgaW50byBpdHMgbmV0d29y ayBzaG91bGQgdXNlIHRoZSBSIA0KPiBiaXQuICBUaGVyZSANCj4gPiBpcyBubyBwcm9ibGVtLg0K PiANCj4gUiBiaXQgYnkgaXRzZWxmIGNhbid0IHNvbHZlIHRoaXMgcHJvYmxlbS4gQWZ0ZXIgTW92 ZW1lbnQsIGlmIA0KPiBhbiBNTiBjYW4gc3RpbGwgaGVhciBpdHMgDQo+IGN1cnJlbnQgZGVmYXVs dCByb3V0ZXIgKGNvbmZpcm1lZCB3aXRoIFIgYml0KSwgaXQgY2FuIGFzc3VtZSANCj4gdGhhdCBp dHMgQ29BIGlzIHN0aWxsIHZhbGlkLiANCj4gQnV0IGlmIGFuIE1OIGRvZXNuJ3QgaGVhciBpdHMg Y3VycmVudCBkZWZhdWx0IHJvdXRlciwgTU4gaXMgDQo+IGluIGEgdHJvdWJsZSBkZXNjcmliZWQg DQo+IGFib3ZlLiANCj4gICANCj4gPiAgICBNb3Jlb3ZlciwgZXZlbiB0aG91Z2ggYSBSQSBtZXNz YWdlIGNvbnRhaW5zIGFsbCB0aGUgUHJlZml4IA0KPiA+ICAgIEluZm9ybWF0aW9uIE9wdGlvbnMs IGEgaG9zdCBoYXMgbm8gd2F5IHRvIGtub3cgaXQuIFRoZXJlIGlzIG5vIA0KPiA+ICAgIGluZGlj YXRpb24uDQo+ID4gDQo+ID4gV2h5PyAgU3VyZSB0aGV5IGRvPw0KPiANCj4gV2hlbiBhIFJBIGFy cml2ZXMsIGFuIE1OIGNhbid0IGJlIHN1cmUgdGhhdCBpdCBjb250YWlucyBhbGwgDQo+IHRoZSBw cmVmaXhlcy4gVGhlcmUgYWx3YXlzIGlzIA0KPiBhIHBvc3NpYmlsaXR5IHRoYXQgYSBwcmVmaXgg bWF5IGJlIG9taXR0ZWQgaW4gdGhpcyBwYXJ0aWN1bGFyIFJBLiANCj4gICAgICANCj4gPiAgICBI ZW5jZSwgYSBob3N0IGNhbid0IGJlIHN1cmUgdGhhdCB0aGUgcHJlZml4IG9mIGl0cyBjdXJyZW50 IElQIA0KPiA+IGFkZHJlc3MNCj4gPiANCj4gPiAgICBpcyBub3Qgc3VwcG9ydGVkIG9uIHRoZSBj dXJyZW50IGxpbmssIGV2ZW4gdGhvdWdoIHRoZSANCj4gcHJlZml4IGlzIG5vdCANCj4gPiAgICBj b250YWluZWQgaW4gYW4gUkEgbWVzc2FnZS4NCj4gPiANCj4gPiBUaGVyZSBhcmUgY2xlYXIgYWRt aW5pc3RyYXRpb24gcnVsZXMgZm9yIE1OIHN1cHBvcnQgZm9yIE5EIA0KPiBhbmQgTUlQdjYgDQo+ ID4gRXh0ZW5zaW9ucyB0byBORC4gVGhlIHByb2JsZW0gaXMgZG8gd2Ugbm90IGZlZWwgTUlQdjYg DQo+IGRvY3VtZW50ZWQgdGhlc2UgDQo+ID4gd2VsbCBlbm91Z2ggb3Igbm90Pw0KPiA+ICAgICAN Cj4gPiAgICBUaGUgcHJvYmxlbSBpcyAxKSBhbiBSQSBtYXkgb21pdCBzb21lIFByZWZpeCBJbmZv cm1hdGlvbiANCj4gT3B0aW9ucyBhbmQgDQo+ID4gICAgMikgZXZlbiBpdCBoYXMgYWxsIHRoZSBQ cmVmaXggSW5mb3JtYXRpb24gT3B0aW9ucywgdGhlcmUgaXMgbm8gDQo+ID4gICAgaW5kaWNhdGlv biB0aGF0IGl0IGRvZXMuDQo+ID4gDQo+ID4gSSBjYW5ub3QgcGFyc2UgdGhlIGNvbmNsdXNpb24g Zm9yIDIpIGF0IGFsbD8NCj4gDQo+IEFzIEkgZGVzY3JpYmVkIGFib3ZlLCB0aGVyZSBpcyBubyBp bmRpY2F0aW9uIGluIGEgUkEgd2hpY2ggDQo+IG5vdGlmaWVzIHRoaXMgUkEgY29udGFpbnMgYWxs IHRoZSANCj4gcHJlZml4ZXMuIA0KPiANCj4gPiAgICBUaGUgcG9zc2libGUgc29sdXRpb24gZm9y IHRoZSBhYm92ZSBpcyB0aGUgUkEgd2l0aCAgDQo+ID4gICAgMSkgQWxsIHRoZSBQcmVmaXggSW5m b3JtYXRpb24gT3B0aW9ucyBhbmQgIA0KPiA+ICAgIDIpIFRoZSBpbmRpY2F0aW9uIHRoYXQgaXQg Y29udGFpbnMgYWxsIHRoZSBQcmVmaXggSW5mb3JtYXRpb24gDQo+ID4gICAgICAgT3B0aW9ucy4N Cj4gPiANCj4gPiAgICBGb3IgMiksIHdlIG1heSBkZWZpbmUgYSBuZXcgYml0IGluIGFuIFJBIG1l c3NhZ2UuIFdlIA0KPiB3aWxsIGdpdmUgbW9yZSANCj4gPiAgICBkZXRhaWwgaW4gMy4xLg0KPiA+ IA0KPiA+IFRoaXMgaXMgbm90IG5lY2Vzc2FyeSBhbmQgaGFzIGJlZW4gcmVzb2x2ZWQgYnkgTUlQ djYuDQo+ICAgICANCj4gQWN0dWFsbHkgbW9iaWxlaXAgV0cgZG9lc24ndCBmZWVsIHRoYXQgTUQg aXMgdW5kZXIgaXRzIHdvcmsgDQo+IHNjb3BlIGVpdGhlci4gQSBuZXcgV0csIA0KPiBETkEsIGN1 cnJlbnRseSBCb0YsIHdpbGwgZG8gdGhpcy4gLiANCj4gICAgICANCj4gPiAyLjMgTGFjayBvZiBT b2xpY2l0YXRpb24gQWNrbm93bGVkZ2VtZW50DQo+ID4gICAgIA0KPiA+ICAgIEluIFJvdXRlciBB ZHZlcnRpc2VtZW50IG1lc3NhZ2VzLCB0aGVyZSBpcyBubyANCj4gc29saWNpdGF0aW9uIGJpdCwg YXMgDQo+ID4gaW4NCj4gPiANCj4gPiAgICBOZWlnaGJvciBBZHZlcnRpc2VtZW50LiBTbyB3aGVu IGEgbm9kZSByZWNlaXZlcyBhIFJBLCBpdCANCj4gY2FuJ3MgYmUgDQo+ID4gICAgc3VyZSBpdCdz IHRoZSByZXBseSB0byBpdHMgUm91dGVyIFNvbGljaXRhdGlvbi4gVG8gY29uZmlybSBiaS0NCj4g PiAgICBkaXJlY3Rpb25hbCByZWFjaGFiaWxpdHksIGFuIGFkZGl0aW9uYWwgTlMvIE5BIGV4Y2hh bmdlIGlzIA0KPiA+IG1hbmRhdG9yeS4NCj4gPiANCj4gPiBEbyBub3QgYWdyZWUuICBXaGVuIGEg bm9kZSBnZXRzIGFuIFJBIGl0IHRoZW4gYmVnaW5zIA0KPiBjb21tdW5pY2F0aW9uLiAgDQo+ID4g SWYgdGhhdCBjb21tdW5pY2F0aW9ucyBmYWlscyB0aGVuIHRoZSByb3V0ZXIgaXMgZG93biBhbmQg bXVzdCBiZSANCj4gPiByZXRyaWVkIG9yIG11c3QgbG9jYXRlIGFub3RoZXIgcm91dGVyLiAgVGhl IElQdjYgDQo+IGFyY2hpdGVjdHVyZSBkaWQgbm90IA0KPiA+IGltcGxlbWVudCBzdWNoIHJlYWNh YmlsaXR5IHdpdGggcm91dGVycyBmb3IgYSBnb29kIHJlYXNvbiANCj4gYW5kIHRoYXQgaXMgdG8g c3VwcG9ydA0KPiA+IHJlZHVjZWQgZGlzY292ZXJ5IG1lc3NhZ2VzIGFuZCBiYW5kd2lkdGggb24g YW4gSVB2NiBsaW5rLiAgIA0KPiANCj4gQ29ycmVjdCBtZSBpZiB3cm9uZy4gQnV0IFJGQyAyNDYx IG1hbmRhdGVzIGhvc3RzIHRvIGNvbmZpcm0gDQo+IHJlYWNoYWJpbGl0eSB3aXRoIGl0cyBkZWZh dWx0IA0KPiByb3V0ZXIuIEFmdGVyIG1vdmVtZW50LCBob3N0cyBoYXZlIHRvIGNvbmZpcm0gcmVh Y2hhYmlsaXR5IA0KPiBhbmQgaXQgZW50YWlscyBOUy8gTkEgZXhjaGFuZ2UuDQo+ICAgICAgDQo+ IFtPbWl0dGVkXSANCj4gPiAgICBBY2NvcmRpbmcgdG8gW1JGQyAyNDYxXSwgYSByb3V0ZXIgbWF5 IGFkdmVydGlzZSBwcmVmaXhlcyANCj4gd2l0aCBMPTAgDQo+ID4gYW5kDQo+ID4gDQo+ID4gICAg QT0xLiBUaGlzIGltcGxpZXMgdGhhdCBzdGF0ZWxlc3MgYWRkcmVzcyBhdXRvY29uZmlndXJhdGlv biBpcyANCj4gPiBhbGxvd2VkDQo+ID4gDQo+ID4gICAgZm9yIHRoZXNlIHByZWZpeGVzIFtSRkMg MjQ2Ml0uIEl0IGlzIHBvc3NpYmxlIHRvIHNob3cgDQo+IHRoYXQgaW4gdGhlIA0KPiA+ICAgIGFi c2VuY2Ugb2YgQWRkcmVzcyBTdGF0ZSBvbiByb3V0ZXJzIG9yIE5EIHByb3h5aW5nLCBkdXBsaWNh dGUgDQo+ID4gICAgYWRkcmVzc2VzIG1heSBiZSBjb25maWd1cmVkIGZvciBhIGdsb2JhbCBhZGRy ZXNzLCB3aGVuIA0KPiBhbiBhZGRyZXNzIA0KPiA+ICAgIG93bmVyIGV4aXN0cyBvbiBhbm90aGVy IGxpbmsgb2YgdGhlIHNhbWUgc3VibmV0Lg0KPiA+IA0KPiA+IFRoaXMgaXMgcG9pbnQgdGhlIGRy YWZ0IG1pc3NlZCBlYXJseSBvbi4gIFJvdXRlcnMgY2Fubm90IA0KPiBwcm92aWRlIHNhbWUgDQo+ ID4gcHJlZml4ZXMgdG8gdHdvIHNlcGFyYXRlIGxpbmtzLg0KPiANCj4gVGhpcyBwb2ludCB3ZSdk IGJldHRlciBjbGFyaWZ5LiBJIHRoaW5rIHRoYXQgUm91dGVycyBjYW4gDQo+IHByb3ZpZGUgdGhl IHNhbWUgcHJlZml4IHRvIHR3byBzZXBhcmF0ZSANCj4gbGlua3Mgd2hlbiBMIGJpdCBpZiBvZmYu IEtpbmRseSBjaGVjayB0aGUgZm9sbG93aW5nIGV4YW1wbGUuIA0KPiANCj4gQSByb3V0ZXIgaGFz IHR3byBpbnRlcmZhY2VzIHRvIHdoaWNoIHR3byBzZXBhcmF0ZSBsaW5rIGFyZSANCj4gYXR0YWNo ZWQuIEZvciB0aG9zZSBpbnRlcmZhY2VzLCB0aGUgDQo+IHJvdXRlciBhZHZlcnRpc2UgdGhlIHNh bWUgcHJlZml4IEE6OiB3aXRoIEwgYml0IG9mZi4gVGhlcmUgaXMgDQo+IG5vdGhpbmcgaW4gUkZD IDI0NjEgd2hpY2ggYmFucyB0aGlzLiANCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg X19fXw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgfA0KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgIFIgICB8X19fX19fX19fX19fX19fXyANCj4gICAgICAgICAgICAg ICAgICAgICAgICAgIHxfX19ffCAgICAgICAgICAgIEE6Og0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBBOjoNCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICAgIA0KPiBJIHRoaW5rIHRoYXQgdGhl IHVzYWdlIG9mIHRoZSBwcmVmaXggd2l0aCBMIGJpdCBvZmYgaXMgYSANCj4gbGl0dGxlIGFtYmln dW91cy4gV2UnZCBiZXR0ZXIgY2xhcmlmeSBpdC4gDQo+ICANCj4gPiAzLiBSQSBPcHRpbWl6ZWQg Zm9yIE1vdmVtZW50IERldGVjdGlvbg0KPiA+ICAgICANCj4gPiAgICBPdXIgZ29hbCBpcyB0byBk ZXNpZ24gYW4gUkEgaW4gc3VjaCBhIHdheSB0aGF0IGFuIE1OIGNhbiANCj4gZGV0ZWN0IGl0cyAN Cj4gPiAgICBtb3ZlbWVudCBlZmZpY2llbnRseSwgcXVpY2tseSBhbmQgcHJlY2lzZWx5IHdpdGgg YXMgDQo+IGxpdHRsZSBzaWduYWxpbmcgDQo+ID4gICAgYXMgcG9zc2libGUuIEFzIGRlc2NyaWJl ZCBhYm92ZSwgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiBhIA0KPiA+ICAgIGN1cnJlbnQg UkEgbWVzc2FnZSBpcyBpbmNvbnNpc3RlbnQgYW5kIGluY29tcGxldGUgZm9yIG1vdmVtZW50IA0K PiA+ICAgIGRldGVjdGlvbi4gVGhlIGZvbGxvd2luZyBwcm9wb3NhbHMgc2VlayB0byBmYWNpbGl0 YXRlIGVmZmljaWVudCANCj4gPiAgICBtb3ZlbWVudCBkZXRlY3Rpb24gYnkgaW5jbHVkaW5nIGFs bCB0aGUgbmVjZXNzYXJ5IA0KPiBpbmZvcm1hdGlvbiBpbiBhbiANCj4gPiAgICBSQSBtZXNzYWdl Lg0KPiA+IA0KPiA+IFRoZXJlIGlzIG5vIHJlYXNvbiBmb3IgdGhpcyBkZXNpZ24gYW5kIHRoZSBw cm9ibGVtIGhhcyBiZWVuIA0KPiBzb2x2ZWQgYnkgDQo+ID4gTUlQdjYuDQo+IA0KPiBVbmZvcnR1 bmF0ZWx5IHRoaXMgcHJvYmxlbSBoYXMgbm90IHNvbHZlZCBieSBNSVB2Ni4gTmVpdGhlciANCj4g TUlQNiBXRyBpcyB0byB3b3JrIG9uIGl0LiANCj4gRE5BIGlzIHRvIGRlc2lnbiBhIHNvbHV0aW9u IGFuZCwgSSB0aGluaywgdGhpcyBpcyBhIHBhcnQgb2YgaXQuICANCj4gIA0KPiA+IDMuMSBDb21w bGV0ZSBSQQ0KPiA+ICAgICANCj4gPiAgICBTaW5jZSByb3V0ZXJzIG1heSBuZWdsZWN0IHRvIHNl bmQgYWxsIHByZWZpeGVzIGluIGV2ZXJ5IA0KPiA+IGFkdmVydGlzZW1lbnQsDQo+ID4gICAgaXQg aXMgZGlmZmljdWx0IGZvciBhbiBNTiB0byBkZXRlcm1pbmUgd2hldGhlciBpdCBpcyANCj4gYXR0 YWNoZWQgdG8gYSANCj4gPiAgICBkaWZmZXJlbnQgc3VibmV0LCB3aGVuIGFuIFJBIHJlY2VpdmVk IHdpdGhvdXQgaXRzIGN1cnJlbnRseSANCj4gPiAgICBjb25maWd1cmVkIHByZWZpeC4NCj4gPiAg ICAgDQo+ID4gICAgRXZlbiB0aG91Z2ggYW4gUkEgY29udGFpbnMgYWxsIHRoZSBQcmVmaXhlcywg YW4gTU4gaGFzIG5vIHdheSB0byANCj4gPiBrbm93DQo+ID4gDQo+ID4gICAgaXQuIFRoZXJlIGlz IG5vIGluZGljYXRpb24uIFNvIHN0aWxsIGFtYmlndWl0eSByZW1haW5zLg0KPiA+ICANCj4gPiBT dXJlIGl0IGRvZXMgaWYgdGhlIFIgYml0IGlzIHNldCBmb3IgYSByb3V0ZXIgb3IgTCBiaXQgZm9y IGhvc3QgDQo+ID4gbm90aWZpY2F0aW9uLg0KPiAgICAgIA0KPiBXZSBoYXZlIGEgZGlzYWdyZWVt ZW50IGhlcmUuIFIgYml0IGFuZCBMIGJpdCB0YWxrIG9ubHkgYWJvdXQgDQo+IGp1c3Qgb25lIHBy ZWZpeC4gVGhleSBkb24ndCBzYXkgDQo+IGFueXRoaW5nIGFib3V0IHRoZSBjb2xsZWN0aW9uIG9m IGFsbCBwcmVmaXhlcy4gSSBkb24ndCBrbm93IA0KPiBob3csIHdpdGggTCBhbmQgUiBiaXQsIGFu IE1OIGNhbiANCj4gYmUgc3VyZSBhIHBhcnRpY3VsYXIgUkEgY29udGFpbnMgYWxsIHRoZSBwcmVm aXhlcy4gDQo+IA0KPiA+ICAgIElmIGEgcm91dGVyIGlzIGFibGUgdG8gc2VuZCBhbiBpbmRpY2F0 aW9uIHRoYXQgdGhlIFJBIGl0IHNlbmRzIA0KPiA+ICAgIGNvbnRhaW5zIGFsbCBvZiB0aGUgdmFs aWQgcHJlZml4ZXMgZm9yIGEgbGluay1pbnN0YW5jZSwgdGhlbiANCj4gPiAgICByZWNlcHRpb24g b2YgYW4gUkEgd2hpY2ggY29udGFpbnMgYSBkaWZmZXJlbnQgc2V0IG9mIHByZWZpeGVzIA0KPiA+ ICAgIGluZGljYXRlcyB0aGUgcHJlc2VuY2Ugb2YgYSBkaWZmZXJlbnQgc3VibmV0Lg0KPiA+IA0K PiA+IFRoaXMgaXMgdG8gbXVjaCBvdmVyaGVhZCBhbmQgdGhlIFIgYml0IGFscmVhZHkgZG9lcyB0 aGlzIGZhciBiZXR0ZXIgDQo+ID4gYW5kIHdoeSBNSVB2NiBXRyBjb252ZXJnZWQgb24gdGhlIHN1 cHBvcnQgb2YgdGhpcyBuZXcgcHJlZml4IG9wdGlvbiANCj4gPiBhbmQgd2h5IHRoZSBJUHY2IFdH IHN1cHBvcnRlZCB0aGUgY2hhbmdlLiAgVGhpcyBkcmFmdCBpcyB0cnlpbmcgdG8gDQo+ID4gcmVp bnZlbnQgdGhhdCBzb2x1dGlvbiBhbmQgaXQgaXMgbm90IG5lY2Vzc2FyeS4NCj4gDQo+IElNSE8s IHRoZSBwdXJwb3NlIG9mIFIgYml0IGFuZCBDb21wbGV0ZSBiaXQgaXMgZGlmZmVyZW50LiAgDQo+ ICAgICAgDQo+IFtPbWl0dGVkXSANCj4gPiAgICBGb3IgZWZmaWNpZW50IE1vdmVtZW50IERldGVj dGlvbiwgd2UgcHJvcG9zZSBhIFJBIHdpdGggIA0KPiA+ICAgIDEpIEFSJ3MgZ2xvYmFsIElQIGFk ZHJlc3MgdXNpbmcgUiBiaXQgIA0KPiA+ICAgIDIpIEFsbCB0aGUgb3B0aW9ucyAoaW5jbHVkaW5n IGFsbCB0aGUgUHJlZml4IEluZm9ybWF0aW9uIA0KPiBPcHRpb25zKSANCj4gPiAgICAzKSBUaGUg aW5kaWNhdGlvbiB0aGF0IGl0IGhhcyBhbGwgdGhlIG9wdGlvbnMgKENvbXBsZXRlIGJpdCkgDQo+ ID4gICAgNCkgUyBiaXQgKFNvbGljaXRhdGlvbiBiaXQpIHRvIGNvbmZpcm0gcmVhY2hhYmlsaXR5 IA0KPiB3aXRob3V0IE5TLyBOQSANCj4gPiAgICAgICBleGNoYW5nZQ0KPiA+IA0KPiA+IEkgZG9u J3QgYWdyZWUgd2l0aCB0aGUgcmVhY2hhYmlsaXR5IHN1Z2dlc3Rpb24gYnV0IGFsbCB0aGUgb3Ro ZXJzIA0KPiA+IGV4aXN0IHRvZGF5IGFuZCB3aGF0IGlzIG5lZWRlZCBpcyB0byBkZWZpbmUgYSBw b2xpY3kgd2hlbiBhbGwgdGhpcyANCj4gPiBtdXN0IGV4ZWN1dGUuDQo+IA0KPiBUaGVyZSBpcyBu b3RoaW5nIGZvciAzKSwgdG8gaW5kaWNhdGUgdGhlIGNvbXBsZXRlbmVzcyBvZiBhIFJBLiAgDQo+ IA0KPiBBbm90aGVyIHRoYW5rcyBmb3IgeW91ciBkZXRhaWxlZCBhbmQgaGVscGZ1bCBjb21tZW50 cy4gSXQgDQo+IGNsYXJpZmllcyBteSB0aG91Z2h0cy4gDQo+IA0KPiBCZXN0IHJlZ2FyZHMNCj4g DQo+IEppbkh5ZW9jaw0KPiANCj4gICDDgsWgwq7ihKLFoMWgwqZ6wq7FocKywrZFeuKAoMKzw4N6 wq5qasWgwp3FoA0KPiANCg== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Oct 25 17:55:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16569 for ; Sat, 25 Oct 2003 17:55:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADWNh-0004KT-4s for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 17:55:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9PLtXfF016638 for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 17:55:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADWNg-0004KH-UF for ipv6-web-archive@optimus.ietf.org; Sat, 25 Oct 2003 17:55:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16537 for ; Sat, 25 Oct 2003 17:55:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADWNe-0002wn-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 17:55:30 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADWNd-0002wk-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 17:55:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADWMD-0004BS-Qs; Sat, 25 Oct 2003 17:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADWLI-00049h-DU for ipv6@optimus.ietf.org; Sat, 25 Oct 2003 17:53:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16509 for ; Sat, 25 Oct 2003 17:52:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADWLF-0002vh-00 for ipv6@ietf.org; Sat, 25 Oct 2003 17:53:01 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1ADWLF-0002ve-00 for ipv6@ietf.org; Sat, 25 Oct 2003 17:53:01 -0400 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9PLqsed054087; Sat, 25 Oct 2003 23:52:54 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <3F99C926.3090200@iprg.nokia.com> References: <3F99C926.3090200@iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <99D382A8-0735-11D8-BE4E-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org From: Iljitsch van Beijnum Subject: Re: "RFC 2461bis" issue: MTU handling Date: Sat, 25 Oct 2003 23:53:00 +0200 To: Fred Templin X-Mailer: Apple Mail (2.604) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 25 okt 2003, at 2:51, Fred Templin wrote: >> So one approach would be something like having a router advertisement >> option that asserts "trust us; the L2 can in fact support 9k" >> resulting in individual hosts deciding to send out an option with >> their NS/NA saying "I can support receiving 9k". Right, that's what I was talking about. > Agree with the hosts sending ND messages saying: > "I can support receiving 9K" but not necessarily with the > rotuer saying "trust us; the L2 can in fact support 9k". The > router should be advertising the lowest-common-denominator > for all nodes on the link. It's already doing that today. The "L2 can do 9k" indication should go into a new message (option). > Nodes that can accept more than the lowest-common denominator > should negotiate a larger MTU with their neighbors - even if the > value they negotiate is larger than what is being sent in the MTU > option in RA's. Yes, but they must be aware of what the layer 2 equipment can handle. If I hook up two boxes that can do 9000 bytes over ethernet, but the switch is 1500 bytes only, I had better make sure those two boxes stick to 1500. > (Similarly, nodes that prefer smaller than the LCD > should negotiate a smaller MTU - even though they still need to > support the LCD for broadcast/multicast.) The good thing is that if we allow hosts to discover the maximum usable MTU between them, we can now use the regular RA MTU option to broadcast a much smaller MTU for this type of traffic. >> This still has the operational issue of what happens when >> I need extra ports in my office and I get a cheap 4-port hub; neither >> the IT department nor my hosts knows that this box is present and it >> might not support jumboframes. One way to cope with this particular >> topology, >> but no other topologies of varying frame size switches, would be >> for the host to exchange a 9k packet with the router before >> deciding that it should declare itself 9k capable. Who says the router can handle the maximum size packets on a link? In a SOHO environment it's not unusual to have some pretty fast boxes with gigabit ethernet that support 9000 bytes, but since the hookup to the internet is only a few megabits, the router has 100 Mpbs or even 10 Mbps ethernet, with no support for jumboframes. But an exchange using the advertised packet sizes between the two hosts wanting to use larger packets wouldn't be a bad idea. > You could use something like an IPv6 NS message that is artificially > inflated in size for this as we have discussed in the past. But, it's > not > a once-and-done deal; if you're going to be probing the MTU you need > to do it periodically so that L2 path changes don't result in black > holes. ND times out pretty quickly, right? Then this happens pretty much automatically. > General comment - it would be nice if folks would reveiw and comment > on my drafts: > http://www.ietf.org/internet-drafts/draft-templin-ndiscmtu-00.txt Well, you don't waste many words. This must be the shortest draft I've ever seen. You only consider the situation where the per-neighbor MTU is smaller than the "official" link MTU as defined by the relevant "IPv6 over ..." RFC or the MTU option in router advertisements. However, the situation where some hosts have the ability to use larger packets than others and/or the official MTU could also easily be addressed by the same mechanism. However, in that case there is the additional complication that devices operating at lower layers (so that they're unable to participate in IP layer mechanisms) may restrict the maximum packet size. Now hopefully at some point layer 2 mechanisms to deal with this will become available, but in the mean time we need to solve this in IP. (I can imagine adding information about the MTU to the ethernet autonegotiation protocol.) The way I see it, we can't touch the existing RA MTU option, because that would lead to trouble with hosts that don't understand the new way of handling the MTU. So the current RA MTU option would continue to be used to advertise the minimum MRU (maximum receive unit) that all hosts on the link must support. This value must be somewhere between 1280 bytes and the value listed in the IP over RFC. Then there would be a new RA option that would function as the "maximum MTU": hosts are not allowed to transmit packets larger than this. This value must be equal to or higher than the IP over RFC value if it's present. There could be a bit in this option that indicates "if lower layers tell you it's ok to use this value" or "forget what lower layers tell you, this value is the correct one". Finally there would be the per-neighbor MTU preference/capability option. If the advertised neighbor MTU is smaller than the link MRU this indicates that the neighbor is still able to receive packets upto the size of the link MRU, but it prefers to receive smaller packets. If the neighbor MTU is larger than the link MRU the neighbor is capable of and willing to receive packets larger than the link MRU. In that case, if the local system has a similar capability and willingness, it may send packets of a size that is the minimum of the local interface MTU, the link MMTU and the MTU advertised by the neighbor. And if we're going to do this anyway, we may want to provide for a way for routers to tell hosts what the largest packet size is that it can forward. For instance, a simple IPv6-capable ADSL router obviously supports a 1500 byte MTU on its ethernet interface, but if it uses a tunnel for IPv6 connectivity it can't forward IPv6 packets that are larger than 1480 bytes. So advertising this 1480 byte limit in a RA option saves hosts from hitting PMTUD on the first hop all the time. Also, if there is more than one router on the link and they support different maximum routable packet sizes, the host can select the router that supports the largest packets. Back to your draft. I would suggest making the draft a self-contained set of new capabilities rather than going for updates of RFC 2461. This should make both the technical and political aspects much less painful. (Adding a new ND option type is an obvious IANA cosideration, BTW.) Iljitsch van Beijnum -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Oct 25 18:18:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18269 for ; Sat, 25 Oct 2003 18:18:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADWjZ-0006hX-UH for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 18:18:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9PMI91H025753 for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 18:18:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADWjZ-0006hI-Mb for ipv6-web-archive@optimus.ietf.org; Sat, 25 Oct 2003 18:18:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18248 for ; Sat, 25 Oct 2003 18:17:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADWjW-0003K7-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 18:18:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADWjW-0003K3-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 18:18:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADWjS-0006To-45; Sat, 25 Oct 2003 18:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADWjE-0006T7-0H for ipv6@optimus.ietf.org; Sat, 25 Oct 2003 18:17:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18238 for ; Sat, 25 Oct 2003 18:17:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADWjA-0003JW-00 for ipv6@ietf.org; Sat, 25 Oct 2003 18:17:44 -0400 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by ietf-mx with esmtp (Exim 4.12) id 1ADWjA-0003JP-00 for ipv6@ietf.org; Sat, 25 Oct 2003 18:17:44 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 3F338A118 for ; Sat, 25 Oct 2003 18:17:41 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 25 Oct 2003 18:17:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: Review: draft-ietf-v6ops-v6onbydefault-00.txt Date: Sat, 25 Oct 2003 18:17:40 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA19D@tayexc13.americas.cpqcorp.net> Thread-Topic: Review: draft-ietf-v6ops-v6onbydefault-00.txt Thread-Index: AcObRdHmn5XB1BPyRyi/oaWkaOQmHw== From: "Bound, Jim" To: X-OriginalArrivalTime: 25 Oct 2003 22:17:40.0997 (UTC) FILETIME=[CE233B50:01C39B45] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Input on draft-ietf-v6ops-v6onbydefault-00.txt below. This will be a good BCP IPv6 Operational RFC to publish is my input. Neighbor Discovery's [ND] conceptual sending algorithm dictates that when sending a packet to a destination, if a host's default router list is empty, then the host assumes that the destination is on-link. Suggest replace "dictate" with "suggests or states" in the first sentence. Rationale is the conceptual sending algrithm is not required to be implemented in ND. Dictate as word seems inappropriate. For an IPv6 enabled host deployed on a network that has no IPv6 routers as is the case in this scenario, the result is that link-layer address resolution must be performed on all IPv6 addresses to which the host sends packets. If IPv6 is enabled this resolution in most cases before the node completes booting to the user interface. So link-layer address resolution was done anyway. I don't get what the negative concern is in the above sentences. The Application will not receive acknowledgment of the unreachability of destinations that are not on-link until at least address resolution has failed, which is no less than three seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER), plus any transport layer connection timeouts which could be minutes in the case of TCP. The delay with respect to TCP is discussed later in Section 2.3. It seems to me a real good implementation feature for a network OS subsystem kernel would be to have a conditional test if any IPv6 route exists early in the stack if dst is IPv6. If IPv6 hosts don't assume that destinations are on-link as described above, then communication with destinations that are not on-link and unreachable will immediately fail. Nodes should only assume this if they received an RA prefix set with L bit set. Otherwise they should not assume this or they are not compliant to ND. If nodes have received the L bit and prefixes after the check I suggest above the next check would be if any prefixes have been announced and if not rejection could take place then. But, some may suggest that always send the packet somewhere for some deployment scenarios I can think of, but not many. The IPv6 implementation should be able to immediately notify applications that it has no route to such IPv6 destinations, and applications won't waste time waiting for address resolution to fail. This is a good suggestion, given the dst address was not on link and known from the L bit. But, whether this works is dependent on the API capability of the application and passing up dst unreachable as a note. If hosts need to communicate with on-link destinations, then then they need to be explicitly configured to have on-link routes for those destinations This is a strong statement. So the spec is saying unless a node receives an L bit set with prefix set do not attempt communications with onlink nodes, I assume except for link-local addresses. As a general rule this might be good, but not as an absolute rule. The on-link assumption is problematic in ways not directly related to the scenario described, but they should still be briefly mentioned here. One problem is that default routes are not special. The on-link assumption as stated in [ND] would have a host assume that all destinations are on-link when its default router list is empty. I don't see ND stating that at all? Can you point to the text that causes you to believe this? Unless an L bit set with prefix set has been received a node can make no actual assumption except guess, when there is no default router available or router for a dst route. Clearly it shouldn't make this assumption if it has an off-link route that covers the destination and that route isn't a default route. The absence of a default route does not mean that destinations are not reachable through more specific routes. Agree. But isn't this just an example of a very bad implementation of IPv6 and common sense to most engineers that build IP stacks? But ok by me if we want to point this out. Another problem is that the on-link assumption behavior is undefined on multi-homed hosts.=20 Not quite absolute. Each link is known if it received an L bit with prefixes. on-link behavior has to be considered link by link case within an implementation, whether they are multihomed nodes or not. Whether the node knows that it has another link to send a packet to for IPv6 is orthognal to IPv6 being on be default, which is a premise for this spec. Not saying IPv6 does not have more work to do on multihoming, but possibly this problem is another section? It is not caused by on-link assumptions in the implementation. When such a host has no default routers and it is trying to reach a destination to which it has no route, should it try NUD on all interfaces at once? That is an implementation decision, not standards decision. Should it simply realize that the destination is unreachable? The latter is the simplest solution. Determining that a destination is unreachable when there is no route to that destination is the simple solution for all cases, not just the multi-homed case. But if node knows from L bit prefixes it can tell if the dst is on-link and an optimization that is important to several user network operations. Using the feature of ND L bit with prefix set helps avoid just sending directly on the link when no route is present for a dst or a default route. 3.2 Poor IPv6 Network Performance By default in dual stack nodes, applications will try IPv6 destinations first. I don't tbink we can say this nor is it required. This will be a configuration option is my belief for users to decide for their network. If the IPv6 connectivity to those destinations is poor while the IPv4 connectivity is better (i.e., the IPv6 traffic experiences higher latency, lower throughput, or more lost packets than IPv4 traffic), applications will still communicate over IPv6 at the expense of network performance. There is no information available to applications in this case to advise them to try another destination address. This is why a good implementation will permit address selection to be configured and dynamically too. Good Analysis and Work Thanks, /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Oct 25 18:39:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19016 for ; Sat, 25 Oct 2003 18:39:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADX3y-0000MJ-1D for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 18:39:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9PMdD3n001376 for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 18:39:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADX3x-0000M7-Si for ipv6-web-archive@optimus.ietf.org; Sat, 25 Oct 2003 18:39:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18986 for ; Sat, 25 Oct 2003 18:39:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADX3u-0003pO-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 18:39:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADX3u-0003pL-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 18:39:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADX3m-0000Bs-24; Sat, 25 Oct 2003 18:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADX3H-00005k-66 for ipv6@optimus.ietf.org; Sat, 25 Oct 2003 18:38:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18975 for ; Sat, 25 Oct 2003 18:38:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADX3E-0003oW-00 for ipv6@ietf.org; Sat, 25 Oct 2003 18:38:28 -0400 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by ietf-mx with esmtp (Exim 4.12) id 1ADX3D-0003oT-00 for ipv6@ietf.org; Sat, 25 Oct 2003 18:38:27 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 1C34D11128 for ; Sat, 25 Oct 2003 18:38:28 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 25 Oct 2003 18:38:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: Review: draft-ietf-v6ops-onlinkassumption-00.txt Date: Sat, 25 Oct 2003 18:38:27 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA19E@tayexc13.americas.cpqcorp.net> Thread-Topic: Review: draft-ietf-v6ops-onlinkassumption-00.txt Thread-Index: AcObSLk2Bhl3ZNsvSYCdxgumn+yyew== From: "Bound, Jim" To: X-OriginalArrivalTime: 25 Oct 2003 22:38:27.0905 (UTC) FILETIME=[B55A4B10:01C39B48] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Review input on draft-ietf-v6ops-onlinkassumption-00.txt and suggestions for next steps. 1. Introduction Neighbor Discovery for IPv6 [ND] defines a conceptual sending algorithm for hosts. This algorithm states that if a host's default router list is empty, then the host assumes that all destinations are on-link. This assumption creates problems for destination address selection as defined in [ADDRSEL], and adds connection delays associated with unnecessary address resolution and neighbor unreachability detection. The behavior associated with the assumption is undefined in multihomed scenarios, and has some subtle security implications. All of these issues are discussed in this document. This entire spec is predicated on statement in 2461 that are conceptual and not required as compliance to ND RFC 2461. In fact I know multiple implementations that approached some of the specifics of this differently, which is fine as this part of ND gets into a suggestion and not an IETF compliance to the standard. Also below is the wording I think relative I provide from 2461. I also want to note the caveat stated in section 5. below where ND clearly states it is not addressing the issues of source address selection and multihomed hosts. I recall when this was added to ND and the spec in review here is exactly why it made me nervous to put it in ND, thus the lower paragraph in section 5. inroduction below my comments. I believe the L bit with prefix options is an excellent optimzation for communications for IPv6 if used correctly. That is not the issue. So I would like to suggest that the title currently of the draft "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful" is not a good reference to the problem the spec is concerned with. At a minimum it should have something like "conceptual sending algorithm" should be checked or however best to denote this spec's issue. But the current title I feel is misleading. My input to the authors and the IPv6 WG is that providing a BCP update to section 5 for address selection, and then probably a different spec for multihomed hosts is the work to be done. ND section 5 is very clear as a spec this is a "conceptual" reference and that it is specifically not to be used for address selection or multihomed hosts. See 2461 references below. From 2461 5. Conceptual Model of a Host 5. CONCEPTUAL MODEL OF A HOST This section describes a conceptual model of one possible data structure organization that hosts (and to some extent routers) will maintain in interacting with neighboring nodes. The described organization is provided to facilitate the explanation of how the Neighbor Discovery protocol should behave. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document. This model is only concerned with the aspects of host behavior directly related to Neighbor Discovery. In particular, it does not concern itself with such issues as source address selection or the selecting of an outgoing interface on a multihomed host. From 2461 5.2 Conceptual Sending Algorithm Next-hop determination for a given unicast destination operates as follows. The sender performs a longest prefix match against the Prefix List to determine whether the packet's destination is on- or off-link. If the destination is on-link, the next-hop address is the same as the packet's destination address. Otherwise, the sender selects a router from the Default Router List (following the rules described in Section 6.3.6). If the Default Router List is empty, the sender assumes that the destination is on-link. Thanks, /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Oct 25 20:21:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20705 for ; Sat, 25 Oct 2003 20:21:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADYeB-0007VK-70 for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 20:20:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9Q0Khva028841 for ipv6-archive@odin.ietf.org; Sat, 25 Oct 2003 20:20:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADYeB-0007V6-03 for ipv6-web-archive@optimus.ietf.org; Sat, 25 Oct 2003 20:20:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20681 for ; Sat, 25 Oct 2003 20:20:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADYe8-0004er-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 20:20:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADYe8-0004eo-00 for ipv6-web-archive@ietf.org; Sat, 25 Oct 2003 20:20:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADYdY-0007N3-Hp; Sat, 25 Oct 2003 20:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADYd1-0007Ld-Em for ipv6@optimus.ietf.org; Sat, 25 Oct 2003 20:19:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20665 for ; Sat, 25 Oct 2003 20:19:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADYcz-0004eF-00 for ipv6@ietf.org; Sat, 25 Oct 2003 20:19:29 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1ADYcy-0004eC-00 for ipv6@ietf.org; Sat, 25 Oct 2003 20:19:28 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h9Q0IsK16383; Sun, 26 Oct 2003 02:18:54 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h9Q0ItHN076667; Sun, 26 Oct 2003 02:18:55 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200310260018.h9Q0ItHN076667@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli cc: Soliman Hesham , ipv6@ietf.org Subject: Re: RFC 2461- issue list In-reply-to: Your message of Fri, 24 Oct 2003 10:17:47 PDT. <3F995EBB.7010400@iprg.nokia.com> Date: Sun, 26 Oct 2003 02:18:55 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , In your previous mail you wrote: > In other words, is your suggestion that we add the support > for the R bit in the revised spec? no R bit. always include the global address configured from the prefix instead of just the prefix. the prefix can always be obtained using the prefix length field. it is probably more useful to mobile nodes. but not just MIPv6. it is useful whenever a node needs the global address of its access router. > I agree, the R bit or an equivalent (which is compatible because the zero interface ID is reserved for anycast) is very useful for point-to-point links where many softwares like to know the address of the peer. If we include something from Mobile IPv6 & co, the R bit feature is the one to consider. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Oct 26 00:44:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25398 for ; Sun, 26 Oct 2003 00:44:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADclR-0003xS-BV for ipv6-archive@odin.ietf.org; Sun, 26 Oct 2003 00:44:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9Q4iT3F015208 for ipv6-archive@odin.ietf.org; Sun, 26 Oct 2003 00:44:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADclR-0003xC-4t for ipv6-web-archive@optimus.ietf.org; Sun, 26 Oct 2003 00:44:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25342 for ; Sun, 26 Oct 2003 00:44:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADclO-0006zK-00 for ipv6-web-archive@ietf.org; Sun, 26 Oct 2003 00:44:26 -0400 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1ADcik-0006vR-01 for ipv6-web-archive@ietf.org; Sun, 26 Oct 2003 00:41:43 -0400 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1ADcSd-0008UX-TI for ipv6-web-archive@ietf.org; Sun, 26 Oct 2003 00:25:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADcRl-0001is-1R; Sun, 26 Oct 2003 00:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADc5D-00077H-D9 for ipv6@optimus.ietf.org; Sun, 26 Oct 2003 00:00:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24474 for ; Sun, 26 Oct 2003 00:00:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADc5B-0006aT-00 for ipv6@ietf.org; Sun, 26 Oct 2003 00:00:49 -0400 Received: from dsl092-066-068.bos1.dsl.speakeasy.net ([66.92.66.68] helo=cyteen.hactrn.net) by ietf-mx with esmtp (Exim 4.12) id 1ADc5A-0006Zr-00 for ipv6@ietf.org; Sun, 26 Oct 2003 00:00:48 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 426AE436 for ; Sun, 26 Oct 2003 00:00:13 -0400 (EDT) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 26 Oct 2003 00:00:13 -0400 Message-Id: <20031026040013.426AE436@cyteen.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Messages | Bytes | Who --------+------+--------+----------+------------------------ 7.95% | 14 | 11.18% | 117785 | jim.bound@hp.com 6.25% | 11 | 7.08% | 74621 | ftemplin@iprg.nokia.com 6.82% | 12 | 6.29% | 66262 | iljitsch@muada.com 6.82% | 12 | 5.52% | 58156 | pekkas@netcore.fi 5.68% | 10 | 5.29% | 55727 | h.soliman@flarion.com 4.55% | 8 | 4.62% | 48705 | soohong.park@samsung.com 5.11% | 9 | 3.83% | 40346 | erik.nordmark@sun.com 4.55% | 8 | 2.92% | 30745 | brian@innovationslab.net 3.41% | 6 | 3.21% | 33867 | tjc@ecs.soton.ac.uk 2.84% | 5 | 3.06% | 32249 | ipng-incoming@danlan.com 2.84% | 5 | 2.94% | 30945 | jeroen@unfix.org 2.27% | 4 | 3.25% | 34233 | jordi.palet@consulintel.es 1.70% | 3 | 3.72% | 39164 | athene@sait.samsung.co.kr 2.27% | 4 | 2.83% | 29836 | bob.hinden@nokia.com 2.84% | 5 | 1.70% | 17963 | michel@arneill-py.sacramento.ca.us 2.27% | 4 | 1.80% | 18996 | internet-drafts@ietf.org 1.70% | 3 | 2.27% | 23939 | vijayd@iprg.nokia.com 0.57% | 1 | 3.28% | 34604 | willtin@kisang.co.kr 2.27% | 4 | 1.42% | 14958 | suresh.krishnan@ericsson.ca 1.14% | 2 | 2.46% | 25950 | moore@cs.utk.edu 1.70% | 3 | 1.46% | 15389 | rdroms@cisco.com 1.70% | 3 | 1.37% | 14460 | jspark@pec.etri.re.kr 1.70% | 3 | 1.00% | 10582 | itojun@itojun.org 1.14% | 2 | 0.93% | 9803 | gene@nttmcl.com 1.14% | 2 | 0.91% | 9586 | mkshin@pec.etri.re.kr 1.14% | 2 | 0.91% | 9545 | john.loughney@nokia.com 1.14% | 2 | 0.89% | 9360 | ipng@uni-muenster.de 1.14% | 2 | 0.80% | 8475 | jinmei@isl.rdc.toshiba.co.jp 1.14% | 2 | 0.78% | 8209 | benny+nospam@amorsen.dk 1.14% | 2 | 0.74% | 7800 | zefram@fysh.org 1.14% | 2 | 0.66% | 6907 | ronald.vanderpol@rvdp.org 1.14% | 2 | 0.64% | 6741 | alain.durand@sun.com 0.57% | 1 | 0.96% | 10126 | jrh@it.uc3m.es 0.57% | 1 | 0.87% | 9207 | gih@telstra.net 0.57% | 1 | 0.86% | 9068 | elizabeth.rodriguez@dothill.com 0.57% | 1 | 0.73% | 7718 | todd@fries.net 0.57% | 1 | 0.69% | 7234 | pbarany@qualcomm.com 0.57% | 1 | 0.65% | 6812 | guruy@broadcom.com 0.57% | 1 | 0.53% | 5634 | brc@zurich.ibm.com 0.57% | 1 | 0.52% | 5435 | kruse@ohio.edu 0.57% | 1 | 0.51% | 5338 | peter.lewis@upperside.fr 0.57% | 1 | 0.49% | 5149 | sra+ipng@hactrn.net 0.57% | 1 | 0.45% | 4749 | huitema@windows.microsoft.com 0.57% | 1 | 0.42% | 4378 | ericlklein@softhome.net 0.57% | 1 | 0.41% | 4330 | stig.venaas@uninett.no 0.57% | 1 | 0.40% | 4173 | mansaxel@sunet.se 0.57% | 1 | 0.38% | 3993 | francis.dupont@enst-bretagne.fr 0.57% | 1 | 0.36% | 3757 | doc@albert.tavian.com 0.57% | 1 | 0.35% | 3645 | jdurand@renater.fr 0.57% | 1 | 0.33% | 3516 | lmcsukr@ericsson.ca 0.57% | 1 | 0.33% | 3479 | jaehoon_paul@yahoo.com --------+------+--------+----------+------------------------ 100.00% | 176 |100.00% | 1053649 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Oct 26 06:13:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14718 for ; Sun, 26 Oct 2003 06:13:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADipv-0000yl-Rc for ipv6-archive@odin.ietf.org; Sun, 26 Oct 2003 06:13:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9QBDVDi003757 for ipv6-archive@odin.ietf.org; Sun, 26 Oct 2003 06:13:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADipv-0000yW-MH for ipv6-web-archive@optimus.ietf.org; Sun, 26 Oct 2003 06:13:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14694 for ; Sun, 26 Oct 2003 06:13:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADipr-0002ND-00 for ipv6-web-archive@ietf.org; Sun, 26 Oct 2003 06:13:27 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADipr-0002N9-00 for ipv6-web-archive@ietf.org; Sun, 26 Oct 2003 06:13:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADipR-0000sJ-IV; Sun, 26 Oct 2003 06:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADipM-0000s4-IK for ipv6@optimus.ietf.org; Sun, 26 Oct 2003 06:12:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14685 for ; Sun, 26 Oct 2003 06:12:45 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADipI-0002N3-00 for ipv6@ietf.org; Sun, 26 Oct 2003 06:12:52 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ADipH-0002Mz-00 for ipv6@ietf.org; Sun, 26 Oct 2003 06:12:52 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9QBCrI16401 for ; Sun, 26 Oct 2003 13:12:53 +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, 26 Oct 2003 13:12:53 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 26 Oct 2003 13:12:52 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 26 Oct 2003 13:12:52 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: Updated Node Requirements doc available Date: Sun, 26 Oct 2003 13:12:51 +0200 Message-ID: Thread-Topic: RFC 2461- issue list Thread-Index: AcObVyACdbCQXBVKRQmpGUOfU7tI2AAWtFWw To: X-OriginalArrivalTime: 26 Oct 2003 11:12:52.0512 (UTC) FILETIME=[19293200:01C39BB2] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, I've just sent in the Node Requirements doc for publication. Until it is announced, it can be found here: http://www-nrc.nokia.com/sua/draft-ietf-ipv6-node-requirements-06.txt I've tried to answer all of Thomas' comments, so I hope it is now ready for IETF last call. thanks, John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Oct 26 10:03:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18602 for ; Sun, 26 Oct 2003 10:03:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADmQW-0001nK-QD for ipv6-archive@odin.ietf.org; Sun, 26 Oct 2003 10:03:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9QF3WfR006892 for ipv6-archive@odin.ietf.org; Sun, 26 Oct 2003 10:03:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADmQW-0001n5-KX for ipv6-web-archive@optimus.ietf.org; Sun, 26 Oct 2003 10:03:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18518 for ; Sun, 26 Oct 2003 10:03:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADmQU-0005Em-00 for ipv6-web-archive@ietf.org; Sun, 26 Oct 2003 10:03:30 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADmQU-0005Ej-00 for ipv6-web-archive@ietf.org; Sun, 26 Oct 2003 10:03:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADmQ1-0001fZ-Do; Sun, 26 Oct 2003 10:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADmPA-0001bw-FG for ipv6@optimus.ietf.org; Sun, 26 Oct 2003 10:02:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18479 for ; Sun, 26 Oct 2003 10:01:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADmP8-0005EO-00 for ipv6@ietf.org; Sun, 26 Oct 2003 10:02:06 -0500 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1ADmP7-0005EJ-00 for ipv6@ietf.org; Sun, 26 Oct 2003 10:02:05 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9QF1XXZ050860; Sun, 26 Oct 2003 16:01:33 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9QF1WTX256484; Sun, 26 Oct 2003 16:01:33 +0100 Received: from zurich.ibm.com (sig-9-145-138-16.de.ibm.com [9.145.138.16]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA44354; Sun, 26 Oct 2003 16:01:31 +0100 Message-ID: <3F999B33.A11F0964@zurich.ibm.com> Date: Fri, 24 Oct 2003 23:35:47 +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: Hans Kruse CC: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" References: <5.1.0.14.2.20031023182433.00b4ec48@kahuna.telstra.net> <2147483647.1066997649@dhcp-074-101.cns.ohiou.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Exactly. Either we put this solution on the standards track, eliminating many of the problems of both RFC 1918 and FEC0::/10, and meeting a range of needs, or we continue searching for the perfect solution. If we take the latter approach, we will surely see PA space used for these needs instead, or NAT6 devices, or both. Brian Hans Kruse wrote: > > Some notes on the draft as well as some of the comments on the list: > > 1. I think this draft is appropriately being prepared as Proposed > Standard. Trying to side-line local addressing to Experimental is not in > keeping with the declared consensus on work towards a "replacement for > site-locals" (which after all are on the standards track now). Also, this > document IMHO can be tweaked in pretty short order to qualify for Proposed > Standard status. > > 2. Several folks stumbled over the wording (in section 1.0) that > "applications may treat these address[sic] like global scoped addresses". > How about: > > "Applications may treat these addresses like global scoped addresses; such > applications will function correctly within the reach of the local > addresses. Sites using a mixture of Globally Routable and Local addresses > may experience sub-optimal application behaviour, see sections 8.0-10.0 for > further discussion". > > If that sounds better I am willing to volunteer wording/edits to tighten up > those sections (regarding applications in mixed environments). > > 3. Section 9.0 regarding DHCP6; suggest: "In order for hosts to > autoconfigure Local IPv6 addresses, routers have to be configured to > advertise Local IPv6 /64 prefixes in router advertisements, or DHCP6 must > have been configured to assign them." > > 4. Regarding DNS; there were some comments regarding RFC1918-style > lookups. I assume the concern was regarding reverse lookups (the 1918 root > server load issue). However, the Local addresses in this draft are unique > (FC00::/8) or nearly unique (FD00::/8). As such there is really no reason > not to allow reverse lookups for FC00::/8 in the global DNS. > > Hans Kruse, Associate Professor > J. Warren McClure School of Communication Systems Management > Adjunct Associate Professor of Electrical Engineering and Computer Science > Ohio University, Athens, OH, 45701 > 740-593-4891 voice, 740-593-4889 fax > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Oct 26 11:09:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20852 for ; Sun, 26 Oct 2003 11:09:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADnSO-0006VJ-AN for ipv6-archive@odin.ietf.org; Sun, 26 Oct 2003 11:09:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9QG9WxP025002 for ipv6-archive@odin.ietf.org; Sun, 26 Oct 2003 11:09:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADnSO-0006VB-67 for ipv6-web-archive@optimus.ietf.org; Sun, 26 Oct 2003 11:09:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20815 for ; Sun, 26 Oct 2003 11:09:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADnSL-0005g1-00 for ipv6-web-archive@ietf.org; Sun, 26 Oct 2003 11:09:29 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADnSL-0005fy-00 for ipv6-web-archive@ietf.org; Sun, 26 Oct 2003 11:09:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADnRt-0006NI-Dp; Sun, 26 Oct 2003 11:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADnQz-0006IO-9u for ipv6@optimus.ietf.org; Sun, 26 Oct 2003 11:08:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20793 for ; Sun, 26 Oct 2003 11:07:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADnQw-0005fO-00 for ipv6@ietf.org; Sun, 26 Oct 2003 11:08:02 -0500 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1ADnQw-0005fL-00 for ipv6@ietf.org; Sun, 26 Oct 2003 11:08:02 -0500 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9QG7dee065820; Sun, 26 Oct 2003 17:07:49 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <2147483647.1066997649@dhcp-074-101.cns.ohiou.edu> References: <5.1.0.14.2.20031023182433.00b4ec48@kahuna.telstra.net> <2147483647.1066997649@dhcp-074-101.cns.ohiou.edu> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6DFADCA0-07CE-11D8-95B0-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org From: Iljitsch van Beijnum Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Date: Sun, 26 Oct 2003 17:06:59 +0100 To: Hans Kruse X-Mailer: Apple Mail (2.604) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 24 okt 2003, at 18:14, Hans Kruse wrote: > 2. Several folks stumbled over the wording (in section 1.0) that > "applications may treat these address[sic] like global scoped > addresses". How about: > "Applications may treat these addresses like global scoped addresses; > such applications will function correctly within the reach of the > local addresses. Sites using a mixture of Globally Routable and Local > addresses may experience sub-optimal application behaviour, see > sections 8.0-10.0 for further discussion". I think this will only confuse people who aren't aware of all the details. But the problem is more fundamental than wording issues anyway. The problem is that there are two types of uses for local addresses: 1. To number systems/interfaces that are only accessible from withing the local network. 2. To have stable addresses for systems/interfaces regardless of intermittant external connectivity and renumbering. In the case of 1. the scope is site local, although the difinition of "site" may be subject to change. Being able to route these addresses throughout the internet would be more of a drawback than a usable feature, as packets using these addresses may not enter or leave the network. In the case of 2. having the addresses be globally routable throughout the internet would be extremely desirable: having addresses that are stable within the site is good, having addresses that are stable throughout the net is even better. If we recognize that unique local addresses will be used in both capacities and there is a significant chance that a locator/identifier separation mechanism could make these addresses globally usable (if not immediately routable), then it's obvious there are going to be problems. For instance, coming up with relatively simple filters that accommodate both uses of the addresses at the same time would be a big challenge. Having to change the default filtering policies that come with the OS for huge numbers of boxes would be another issue. I think that either it must be explicitly stated which type of addresses we're talking about here. It would probably be best to only specify type 1 and see what can be done for type 2 with locator/identifier separation mechanisms. > 4. Regarding DNS; there were some comments regarding RFC1918-style > lookups. I assume the concern was regarding reverse lookups (the 1918 > root server load issue). However, the Local addresses in this draft > are unique (FC00::/8) or nearly unique (FD00::/8). As such there is > really no reason not to allow reverse lookups for FC00::/8 in the > global DNS. It would make sense to delegate authority for the "nearly unique" type to a set of anycast addresses so that people can provide reverse mapping information for their own local address ranges through DNS servers listening to those anycast addresses. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Oct 26 12:32:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22373 for ; Sun, 26 Oct 2003 12:32:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADoke-0005Pk-Pk for ipv6-archive@odin.ietf.org; Sun, 26 Oct 2003 12:32:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9QHWSfG020806 for ipv6-archive@odin.ietf.org; Sun, 26 Oct 2003 12:32:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADoke-0005PV-KH for ipv6-web-archive@optimus.ietf.org; Sun, 26 Oct 2003 12:32:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22337 for ; Sun, 26 Oct 2003 12:32:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADokd-0006gG-00 for ipv6-web-archive@ietf.org; Sun, 26 Oct 2003 12:32:27 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADokc-0006gD-00 for ipv6-web-archive@ietf.org; Sun, 26 Oct 2003 12:32:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADokE-0005HV-90; Sun, 26 Oct 2003 12:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADojQ-0005Bo-GI for ipv6@optimus.ietf.org; Sun, 26 Oct 2003 12:31:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22316 for ; Sun, 26 Oct 2003 12:31:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADojO-0006fw-00 for ipv6@ietf.org; Sun, 26 Oct 2003 12:31:10 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADojO-0006fh-00 for ipv6@ietf.org; Sun, 26 Oct 2003 12:31:10 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9QHUcr29699; Sun, 26 Oct 2003 19:30:38 +0200 Date: Sun, 26 Oct 2003 19:30:38 +0200 (EET) From: Pekka Savola To: john.loughney@nokia.com cc: ipv6@ietf.org Subject: Re: Updated Node Requirements doc available In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Sun, 26 Oct 2003 john.loughney@nokia.com wrote: > I've just sent in the Node Requirements doc for publication. Until > it is announced, it can be found here: > > http://www-nrc.nokia.com/sua/draft-ietf-ipv6-node-requirements-06.txt > > I've tried to answer all of Thomas' comments, so I hope it is now > ready for IETF last call. FWIW, IETF last call is not necessary or even often done for Informational or Experimental WG submissions. So, if the folks think there are still issues worth raising, don't count on the IETF last call to happen :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Oct 26 22:56:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10893 for ; Sun, 26 Oct 2003 22:56:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADyU7-0003lo-Lr for ipv6-archive@odin.ietf.org; Sun, 26 Oct 2003 22:56:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9R3u35G014486 for ipv6-archive@odin.ietf.org; Sun, 26 Oct 2003 22:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADyU7-0003lZ-G0 for ipv6-web-archive@optimus.ietf.org; Sun, 26 Oct 2003 22:56:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10804 for ; Sun, 26 Oct 2003 22:55:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADyU3-0005dK-00 for ipv6-web-archive@ietf.org; Sun, 26 Oct 2003 22:56:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADyU3-0005dH-00 for ipv6-web-archive@ietf.org; Sun, 26 Oct 2003 22:55:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADyT9-0003Zh-7m; Sun, 26 Oct 2003 22:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADySg-0003XA-8C for ipv6@optimus.ietf.org; Sun, 26 Oct 2003 22:54:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10755 for ; Sun, 26 Oct 2003 22:54:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADySc-0005cL-00 for ipv6@ietf.org; Sun, 26 Oct 2003 22:54:30 -0500 Received: from out2.smtp.messagingengine.com ([66.111.4.26]) by ietf-mx with esmtp (Exim 4.12) id 1ADySc-0005cF-00 for ipv6@ietf.org; Sun, 26 Oct 2003 22:54:30 -0500 Received: from mail.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id D9D913662E4; Sun, 26 Oct 2003 22:54:27 -0500 (EST) Received: from 10.202.2.150 ([10.202.2.150] helo=mail.messagingengine.com) by messagingengine.com with SMTP; Sun, 26 Oct 2003 22:54:27 -0500 X-Mail-from: chirayu@chirayu.org X-Epoch: 1067226867 X-Sasl-enc: CusHc4oUH6tFAWVvTEPzcg Received: from moon (unknown [202.142.102.54]) by mail.messagingengine.com (Postfix) with ESMTP id 89BCC3662EC; Sun, 26 Oct 2003 22:54:24 -0500 (EST) From: "Chirayu Patel" To: Cc: "'Bound, Jim'" , "'Chirayu Patel'" Subject: RE: Review: draft-ietf-v6ops-v6onbydefault-00.txt Date: Mon, 27 Oct 2003 09:29:35 +0530 Message-ID: <010801c39c3e$c069a400$010aa8c0@chirayu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B047CA19D@tayexc13.americas.cpqcorp.net> Importance: Normal Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > If the IPv6 connectivity to those destinations > is poor while the IPv4 connectivity is better (i.e., the IPv6 = traffic > experiences higher latency, lower throughput, or more lost packets > than IPv4 traffic), applications will still communicate over IPv6 at > the expense of network performance. There is no information > available to applications in this case to advise them to try another > destination address. > >This is why a good implementation will permit address selection to be >configured and dynamically too. FYI, I had proposed dynamic configuration of address selection policy = table using RA's in http://www.ietf.org/internet-drafts/draft-cpatel-ipv6-automated-policy-ta= ble-c fg-00.txt. CP -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Oct 26 23:56:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12171 for ; Sun, 26 Oct 2003 23:56:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADzQj-0000oe-6W for ipv6-archive@odin.ietf.org; Sun, 26 Oct 2003 23:56:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9R4ubKq003131 for ipv6-archive@odin.ietf.org; Sun, 26 Oct 2003 23:56:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADzQi-0000oQ-VX for ipv6-web-archive@optimus.ietf.org; Sun, 26 Oct 2003 23:56:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12129 for ; Sun, 26 Oct 2003 23:56:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADzQg-0006Bj-00 for ipv6-web-archive@ietf.org; Sun, 26 Oct 2003 23:56:34 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADzQg-0006Bg-00 for ipv6-web-archive@ietf.org; Sun, 26 Oct 2003 23:56:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADzQB-0000gz-CK; Sun, 26 Oct 2003 23:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADzPp-0000el-Ce for ipv6@optimus.ietf.org; Sun, 26 Oct 2003 23:55:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12113 for ; Sun, 26 Oct 2003 23:55:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADzPn-0006BQ-00 for ipv6@ietf.org; Sun, 26 Oct 2003 23:55:39 -0500 Received: from [129.254.16.14] (helo=cms4.cms.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1ADzPm-0006BB-00 for ipv6@ietf.org; Sun, 26 Oct 2003 23:55:38 -0500 Received: from skylane1 (6ants6.etri.re.kr [129.254.112.240]) by cms4.cms.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VCN88NJH; Mon, 27 Oct 2003 13:51:49 +0900 From: "Byung-Yeob Kim" To: "JORDI PALET MARTINEZ" , "Soohong Daniel Park" Cc: Subject: RE: I-D ACTION:draft-bykim-ipv6-hpd-00.txt Date: Mon, 27 Oct 2003 13:55:04 +0900 Message-ID: <002101c39c46$7c564c20$f070fe81@skylane1> 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.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 In-Reply-To: <01af01c399d6$91e26410$b7cbdba8@daniel> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, all Happy monday, begining of a new week. I have just visited the project site (www.6power.org) and am very impressed. I agree that PLC would be a good starting point for IPv6 deployment. There are some domestic PLC manufacturers also here in Korea, but not yet interested in IPv6. Anyway, I hope they would join us too. Thank you for your comments. We'd welcome any coorperation. Regards, Byung-Yeob. -----Original Message----- From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Soohong Daniel Park Sent: Friday, October 24, 2003 11:29 AM To: 'JORDI PALET MARTINEZ'; ipv6@ietf.org Subject: RE: I-D ACTION:draft-bykim-ipv6-hpd-00.txt Hello Agreed with jordi's thought. It is a very valuable draft in the IPv6 WG. As far as the implementation is concerned, it was well done. Good job Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On > Behalf Of JORDI PALET MARTINEZ > Sent: Friday, October 24, 2003 1:03 AM > To: ipv6@ietf.org > Subject: Re: I-D ACTION:draft-bykim-ipv6-hpd-00.txt > > > Hi, > > I think this is a very interesting document. > > In fact, we have been working in something similar for some > time, but still not drafted it. > > Our case is a very good example, because we are working in a > project (www.6power.org) that deploys IPv6 PLC networks. In our case, > we may have different network configurations, with routers, > bridges (PLC repeaters) and CPEs. > > The idea is to configure the OSS system, in some cases in a > static way (with the subscriber parameters), some others automatically > (but keeping the security to avoid non registered users to > use the service). > > At this way, when the different devices are plugged into the > power network, there is no need to do ANY configuration at > the devices, > as they will learn (or "create") an adequate network > structure, all the way, until the CPE (that can be also a > router, of course). > > The idea is to extend the auto-configuration capabilities for > IPv6 to the complete network. Today we do an autoconfiguration at the > PLC level already. This could provide one very good reason to > deploy IPv6, specially in new networks, as will save a lot of > resources in the setup and operation/maintenance. > > I think is a very good example of the utility of this > document, and for sure we will be interested in cooperate on > it, and most > probably work on concrete implementations. > > Regards, > Jordi > > ----- Original Message ----- > From: > To: > Cc: > Sent: Thursday, October 23, 2003 11:32 PM > Subject: I-D ACTION:draft-bykim-ipv6-hpd-00.txt > > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > > > > Title : Hierarchical Prefix Delegation Protocol > > Author(s) : B. Kim, K. Lee, J. Park, H. Kim > > Filename : draft-bykim-ipv6-hpd-00.txt > > Pages : 12 > > Date : 2003-10-23 > > > > Stateless Autoconfiguration enables IPv6 hosts to send a > request for a prefix, a network identifier to a router on the subnet. > Using this ability a host can configure its IPv6 address. > Likewise, by defining a way to request for a prefix to an upper level > router, a router can get a prefix to be assigned to its subnet. > > > > This document describes a protocol for prefix delegation > between routers. It allows routers get prefixes from its upstream > routers, enabling the entire network and its belonging hosts > autoconfigure their own addresses. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-bykim-ipv6-hpd-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-bykim-ipv6-hpd-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-bykim-ipv6-hpd-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. > > > > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which may be > privileged or confidential. The information is intended to be > for the use of the individual(s) named above. If you are not > the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, > including attached files, is prohibited. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 05:07:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04691 for ; Mon, 27 Oct 2003 05:07:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE4Gt-0006T8-UT for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 05:06:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RA6l4P024860 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 05:06:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE4Gt-0006Ss-BP for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 05:06:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04651 for ; Mon, 27 Oct 2003 05:06:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE4Gq-0002EN-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 05:06:44 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE4Gm-0002EK-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 05:06:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE4GF-0006LT-Bz; Mon, 27 Oct 2003 05:06:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE4FU-0006Hu-Vj for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 05:05:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04607 for ; Mon, 27 Oct 2003 05:05:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE4FR-0002DZ-00 for ipv6@ietf.org; Mon, 27 Oct 2003 05:05:17 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1AE4FQ-0002D2-00 for ipv6@ietf.org; Mon, 27 Oct 2003 05:05:17 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9RA4exA015207; Mon, 27 Oct 2003 02:04:40 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9RA4dS14613; Mon, 27 Oct 2003 11:04:39 +0100 (MET) Date: Mon, 27 Oct 2003 11:04:26 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Review: draft-ietf-v6ops-onlinkassumption-00.txt To: "Bound, Jim" Cc: ipv6@ietf.org In-Reply-To: "Your message with ID" <9C422444DE99BC46B3AD3C6EAFC9711B047CA19E@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > This entire spec is predicated on statement in 2461 that are conceptual > and not required as compliance to ND RFC 2461. Well, the behavior is actually used in section 6.3.6 "Default Router Selection" where section 6 is "host specificatio", thus it isn't only a conceptual thing. 6.3.6 says: 3) If the Default Router List is empty, assume that all destinations are on-link as specified in Section 5.2. At a minimum the specification is unclear on the requirements in this space, but the way I read it (and wrote it :-) this is something that nodes are recommended to do. Thus I think we need to change that recommendation and make the specification clearer in the process. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 06:11:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06732 for ; Mon, 27 Oct 2003 06:11:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE5Hg-00054j-A7 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 06:11:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RBBecN019510 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 06:11:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE5Hf-00054b-Fg for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 06:11:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06691 for ; Mon, 27 Oct 2003 06:11:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE5Hb-00031J-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 06:11:35 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE5Hb-00031G-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 06:11:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE5H4-0004xN-1B; Mon, 27 Oct 2003 06:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE0hl-0002Av-69 for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 01:18:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14588 for ; Mon, 27 Oct 2003 01:18:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE0hi-00078A-00 for ipv6@ietf.org; Mon, 27 Oct 2003 01:18:14 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1AE0hh-000783-00 for ipv6@ietf.org; Mon, 27 Oct 2003 01:18:13 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HNE00H1DJXFTK@mailout2.samsung.com> for ipv6@ietf.org; Mon, 27 Oct 2003 15:12:51 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HNE00CO9JVT23@mailout2.samsung.com> for ipv6@ietf.org; Mon, 27 Oct 2003 15:11:54 +0900 (KST) Received: from OLNRAO ([107.108.4.198]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HNE00H8WJVQOJ@mmp2.samsung.com> for ipv6@ietf.org; Mon, 27 Oct 2003 15:11:53 +0900 (KST) Date: Mon, 27 Oct 2003 11:33:15 +0530 From: "O.L.N.Rao" Subject: RE: draft-syam-ipv6-state-model-00.txt To: jim.bound@hp.com, Soohong Daniel Park Cc: ipv6@ietf.org Message-id: <00b901c39c50$04a6c1a0$c6046c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: multipart/alternative; boundary="Boundary_(ID_AHimSjSJa1e91dkk7j+awg)" X-Priority: 3 X-MSMail-priority: Normal Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_AHimSjSJa1e91dkk7j+awg) Content-type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7BIT Hello Jim, Thanks for your effort in reviewing our draft and giving us a positive and precious feedback. This draft, we think, can be made as an informational RFC from IPv6 WG for IPv6 implementations. We, at SAMSUNG ISO, has implemented this and found ourselves comfortable with it. As you said, we shall look into "MIB Definitions for IPv6" to include the state information from this draft. Regards, O.L.N.Rao I believe it should have ietf in its name yes. /jim > -----Original Message----- > From: Soohong Daniel Park [mailto:soohong.park@samsung.com] > Sent: Saturday, October 25, 2003 12:29 AM > To: Bound, Jim; ipv6@ietf.org > Cc: 'O.L.N.Rao'; 'Soohong Daniel Park' > Subject: RE: draft-syam-ipv6-state-model-00.txt > > > Hello Jim > > > I have read this spec and don't see bugs at this point. Is this > > document to feed work on MIB definitions for SNMP and network > > management? Or just to describe as information the various > states in > > the draft? > > The original intent is to be a Informational RFC as a result > of our implementation but there is no any wall to refer > this document. As you indicated, no bug is there. > > Shoud this document have "ietf" in its name ? > > > Regards > > Daniel (Soohong Daniel Park) > Mobile Platform Laboratory, SAMSUNG Electronics > > > -----Original Message----- > > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On > > Behalf Of Bound, Jim > > Sent: Saturday, October 25, 2003 3:28 AM > > To: ipv6@ietf.org > > Subject: draft-syam-ipv6-state-model-00.txt > > > > > > > > > /jim > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 ------------------------------------------------------ --Boundary_(ID_AHimSjSJa1e91dkk7j+awg) Content-type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7BIT
Hello Jim,
 
    Thanks for your effort in reviewing our draft and
    giving us a positive and precious feedback.
 
    This draft, we think, can be made as an informational
    RFC from IPv6 WG for IPv6 implementations.  We,
    at SAMSUNG ISO, has implemented this and found
    ourselves comfortable with it. 
 
    As you said, we shall look into "MIB Definitions for IPv6"
    to include the state information from this draft. 
 
Regards,
O.L.N.Rao
 
 
I believe it should have ietf in its name yes.
/jim
> -----Original Message-----
> From: Soohong Daniel Park [mailto:soohong.park@samsung.com]
> Sent: Saturday, October 25, 2003 12:29 AM
> To: Bound, Jim; ipv6@ietf.org
> Cc: 'O.L.N.Rao'; 'Soohong Daniel Park'
> Subject: RE: draft-syam-ipv6-state-model-00.txt
>
>
> Hello Jim
>
> > I have read this spec and don't see bugs at this point.  Is this
> > document to feed work on MIB definitions for SNMP and network
> > management?  Or just to describe as information the various
> states in
> > the draft?
>
> The original intent is to be a Informational RFC as a result
> of our implementation but there is no any wall to refer
> this document.  As you indicated, no bug is there.
>
> Shoud this document have "ietf" in its name ?
>
>
> Regards
>
> Daniel (Soohong Daniel Park)
> Mobile Platform Laboratory, SAMSUNG Electronics
>
> > -----Original Message-----
> > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On
> > Behalf Of Bound, Jim
> > Sent: Saturday, October 25, 2003 3:28 AM
> > To: ipv6@ietf.org
> > Subject: draft-syam-ipv6-state-model-00.txt
> >
> >
>
> >
> > /jim
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
------------------------------------------------------
--Boundary_(ID_AHimSjSJa1e91dkk7j+awg)-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 06:58:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08218 for ; Mon, 27 Oct 2003 06:58:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE60h-0000qE-73 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 06:58:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RBwBSt003228 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 06:58:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE60g-0000pz-RW for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 06:58:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08196 for ; Mon, 27 Oct 2003 06:57:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE60c-0003a9-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 06:58:06 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE60c-0003a5-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 06:58:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE60X-0000m1-LS; Mon, 27 Oct 2003 06:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE60E-0000kr-Tf for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 06:57:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08189 for ; Mon, 27 Oct 2003 06:57:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE60A-0003Zv-00 for ipv6@ietf.org; Mon, 27 Oct 2003 06:57:38 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AE609-0003Zr-00 for ipv6@ietf.org; Mon, 27 Oct 2003 06:57:38 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9RBvWPh024350; Mon, 27 Oct 2003 04:57:32 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9RBvVS29427; Mon, 27 Oct 2003 12:57:31 +0100 (MET) Date: Mon, 27 Oct 2003 12:57:17 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: "RFC 2461bis" issue: MTU handling To: Fred Templin Cc: Erik Nordmark , Iljitsch van Beijnum , ipv6@ietf.org In-Reply-To: "Your message with ID" <3F99C50E.5010603@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > If you are probing to determine the initial PMTU, the answer is to send > periodic additional probes, of course. Routes are going to flap, and paths > are going to change - a once-probed MTU cannot be expected to remain > stable for any set length of time. Did you really mean that? Clearly there has to be some assumption about the frequency at which the MTU can decrease. If not, for every e.g. TCP packet you send you would need to send an MTU probe (with an ACK) to make sure that a (TCP) packet of that size can make it to the neighbor. And since this is the L2 MTU and there will be multiple L2 instances along the L3 path one would either need to do such probing end2end (doubling the number of packets on the Internet), or have routers on the path perform hop-by-hop MTU probing including from the last hop router towards the destination host. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 07:11:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08646 for ; Mon, 27 Oct 2003 07:11:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6DN-0002O6-2l for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 07:11:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RCBGi5009165 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 07:11:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6DM-0002NY-Mu for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 07:11:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08584 for ; Mon, 27 Oct 2003 07:11:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE6DI-0003mJ-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 07:11:12 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE6DH-0003mD-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 07:11:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6D9-0002Bi-4i; Mon, 27 Oct 2003 07:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6Cx-0002Ab-JI for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 07:10:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08560 for ; Mon, 27 Oct 2003 07:10:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE6Ct-0003lo-00 for ipv6@ietf.org; Mon, 27 Oct 2003 07:10:47 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AE6Cs-0003ll-00 for ipv6@ietf.org; Mon, 27 Oct 2003 07:10:46 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9RCAk5u007237; Mon, 27 Oct 2003 05:10:47 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9RCAjS29914; Mon, 27 Oct 2003 13:10:46 +0100 (MET) Date: Mon, 27 Oct 2003 13:10:32 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-hain-templin-ipv6-localcomm-03.txt To: Fred Templin Cc: ipv6@ietf.org In-Reply-To: "Your message with ID" <3F995CDB.2080406@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , I have some on draft-hain-templin-ipv6-limitedrange-02.txt which appear to apply to the new draft even though it has removed the explicit reference to the need for a local address format from the title and abstract/intro. The summary is that I think we need a discussion about the needs of sites in general and these "active sites" in particular, but this draft doesn't seem to do that. Details below. Comments on draft-hain-templin-ipv6-limitedrange-02.txt The document seems to make the case that there is a set of interested goals and requirements related to "active sites", and I agree that this is something that we need to understand better. But the document from the outset, and in every other paragraph, assumes that any and all solutions to to making such sites work better involve defining some local address space. As a result the document reads as an attempt to justify a particular solution to the problem, and not as a balanced attempt to understand the issues relating to such sites and the goals related to making them work better. Thus I think we instead need goals for "active sites" with local and global communication (taking into account that for different sites the relative importance of global and local communication is likely to be different). For those that think that there can't exist solutions which don't use a local address space I offer 4 different possible approaches where only 1 use local address space (and another uses local locators which are invisible to the applications): - unique local addresses plus TBD mechanisms for name resolution (DNS) and application impact; a rather large TBD IMHO. See Keith's recent mail. - for sites which are naturally part of some larger site using Nemo (or just tunneling with delegated global addresses from the larger site) just work. This approach doesn't handle all types of active sites, but it doesn't seem to require any additional standardizion - running DHCPv6 prefix delegation over IPv6-in-IPv6 tunnels seems to be sufficient. - relying on some multi6 solution (see draft-nordmark-multi6-noid and draft-nordmark-multi6-sim as existance proof that such solutions can be created, if nothing else [Thus this is not an endorsement that I think those particular approaches are the best.]) by using global locators plus standard filtering, renumbering the *locators* on attachment in a new place (keeping the old locator prefix alive while the new locators are propagated). - as above but also using unique local *locators* to make the locator renumbering smoother. This introduces the need to be able to discover those local locators in addition to discovering the global locators. I hope the above list shows that defining some unique local address space is not the only approach to making "active sites" work better. Is anybody interested in producing a document about "Issues and goals for active sites" without assuming that the solution is some new address space? FWIW I find it odd that while the multi6 problem statement is related to the overloading of location and identity in the IP address space (which made sense 25 years ago) and folks are trying to figure out how to add a layer of indirection to solve that problem, the local address discussion is about overloading addresses with yet more functionality and semantics. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 07:11:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08647 for ; Mon, 27 Oct 2003 07:11:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6DN-0002ON-Ar for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 07:11:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RCBHui009189 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 07:11:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6DN-0002O8-4c for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 07:11:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08590 for ; Mon, 27 Oct 2003 07:11:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE6DI-0003mS-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 07:11:12 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE6DH-0003mE-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 07:11:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6DA-0002Bu-Eq; Mon, 27 Oct 2003 07:11:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6D3-0002As-1f for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 07:10:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08563 for ; Mon, 27 Oct 2003 07:10:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE6Cy-0003lu-00 for ipv6@ietf.org; Mon, 27 Oct 2003 07:10:52 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1AE6Cy-0003lj-00 for ipv6@ietf.org; Mon, 27 Oct 2003 07:10:52 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9RCALxA023023; Mon, 27 Oct 2003 04:10:22 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9RCALS29906; Mon, 27 Oct 2003 13:10:21 +0100 (MET) Date: Mon, 27 Oct 2003 13:10:07 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: "RFC 2461bis" issue: MTU handling To: Iljitsch van Beijnum Cc: Fred Templin , ipv6@ietf.org In-Reply-To: "Your message with ID" <99D382A8-0735-11D8-BE4E-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > > You could use something like an IPv6 NS message that is artificially > > inflated in size for this as we have discussed in the past. But, it's > > not > > a once-and-done deal; if you're going to be probing the MTU you need > > to do it periodically so that L2 path changes don't result in black > > holes. > > ND times out pretty quickly, right? Then this happens pretty much > automatically. FWIW RFC 2461 does not have any timeout associated with the neighbor cache entries or destination cache entries. They can be garbage collected when the node runs low on memory. And stale link-layer addresses in the neighbor cache are detected when the link-layer address is used by triggering Neighbor Unreachability Detection. Thus if you'd want some mechanisms to peridically "reprobe" the path to the neighbor you'd have to explicitly add such a mechanism. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 07:11:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08673 for ; Mon, 27 Oct 2003 07:11:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6DN-0002O7-2z for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 07:11:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RCBGuk009167 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 07:11:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6DM-0002NZ-OW for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 07:11:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08586 for ; Mon, 27 Oct 2003 07:11:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE6DI-0003mL-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 07:11:12 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE6DH-0003mF-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 07:11:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6DC-0002EX-C1; Mon, 27 Oct 2003 07:11:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6D5-0002B9-6y for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 07:10:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08566 for ; Mon, 27 Oct 2003 07:10:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE6D0-0003m0-00 for ipv6@ietf.org; Mon, 27 Oct 2003 07:10:54 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AE6D0-0003lx-00 for ipv6@ietf.org; Mon, 27 Oct 2003 07:10:54 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9RCAq5u007261; Mon, 27 Oct 2003 05:10:52 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9RCApS29920; Mon, 27 Oct 2003 13:10:51 +0100 (MET) Date: Mon, 27 Oct 2003 13:10:37 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: RFC 2461- issue list To: Vijay Devarapalli Cc: Soliman Hesham , ipv6@ietf.org In-Reply-To: "Your message with ID" <3F995EBB.7010400@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > no R bit. always include the global address configured from the > prefix instead of just the prefix. the prefix can always be > obtained using the prefix length field. Two issues: - The router might not have an address in every prefix it advertises. Should a host still that the prefix field is indeed a useful address for the router in that case? - Existing routers do not put their address in the prefix option even when the router has an address in that prefix. Should a host still that the prefix field is indeed a useful address for the router in that case? If we want to add this to 2461bis I think we must add the "R" bit as well. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 07:33:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09612 for ; Mon, 27 Oct 2003 07:33:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6Ym-0004ff-By for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 07:33:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RCXOpn017949 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 07:33:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6Ym-0004fQ-83 for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 07:33:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09584 for ; Mon, 27 Oct 2003 07:33:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE6Yl-00049N-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 07:33:23 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE6Yl-00049H-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 07:33:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6YQ-0004Yp-4w; Mon, 27 Oct 2003 07:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6Xi-0004X8-5M for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 07:32:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09563 for ; Mon, 27 Oct 2003 07:32:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE6Xh-00048k-00 for ipv6@ietf.org; Mon, 27 Oct 2003 07:32:17 -0500 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1AE6Xg-00048Q-00 for ipv6@ietf.org; Mon, 27 Oct 2003 07:32:16 -0500 Received: from tyre (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.10/8.12.1) with SMTP id h9RCVdlr017223 for ; Mon, 27 Oct 2003 21:31:40 +0900 (KST) Message-ID: <00df01c39c87$55538200$ec2f024b@tyre> From: "JinHyeock Choi" To: References: Subject: Re: A list of issues for RFC2462 update: L=0 and A=1 Date: Mon, 27 Oct 2003 21:39:14 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: base64 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RGVhciBKSU5NRUkNCg0KSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgZm9sbG93aW5nIGlzc3VlIG5l ZWRzIGZ1cnRoZXIgY2xhcmlmaWNhdGlvbi4gDQogDQotIFNlbWFudGljcyBhYm91dCB0aGUgTD0w IGFuZCBBPTEgY2FzZQ0KICBieSBGcmVkIFRlbXBsaW4sIEZlYiAyMDAzDQoNCkkgdGhpbmsgdGhl IHByZWZpeCBvZiBMPTAgYW5kIEE9MSAgbWF5IGNhdXNlIGFuIHVuZGV0ZWN0ZWQgYWRkcmVzcyBk dXBsaWNhdGlvbi4gIA0KQmVjYXVzZSB0aGUgY3VycmVuZCBEQUQgc2NoZW1lIHVzZXMgTlMvIE5B IGV4Y2hhbmdlLCB3aGljaCBjYW4ndCBnbyBvdmVyIA0KYSByb3V0ZXIsIGEgZHVwbGljYXRlIGFk ZHJlc3MgbWF5IGJlIGNvbmZpZ3VyZWQgb24gYSBzZXBhcmF0ZSBsaW5rLCB3aGVuIGEgcm91dGVy IA0KYWR2ZXJ0aXNlcyBhIHByZWZpeCB3aXRoIEwgPSAwIGFuZCBBID0gMS4gDQoNCkhlcmUgaXMg YW4gZXhhbXBsZS4gQXNzdW1lIGEgcm91dGVyIGhhcyB0d28gaW50ZXJmYWNlIHdoaWNoIGFyZSBh dHRhY2hlZCB0byB0d28gDQpzZXBhcmF0ZSBsaW5rcy4gSXQgYXNzaWducyB0aGUgc2FtZSBwcmVm aXggQTo6IHRvIHRoZW0gYW5kIGFkdmVydGlzZXMgdGhlIFJvdXRlciANCkFkdmVydGlzZW1lbnQg bWVzc2FnZXMgd2l0aCB0aGUgcHJlZml4IEE6OiB3aXRoIEwgYml0IChvbi1saW5rIGZsYWcpIG9m ZiBhbmQgQSBiaXQgDQooYXV0b25vbW91cyBhZGRyZXNzLWNvbmZpZ3VyYXRpb24gZmxhZykgb24u DQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLSsNCiAg ICAgICAgICAgICAgICAgICAgICAgICBBOjogICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAg ICBBOjoNCiAgICAgICAgICAgIC0tLS0tLS0tLSstLS0tLSsgIFJvdXRlciAgKy0tLS0tKy0tLS0t LS0tLQ0KICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAgICAg ICB8ICAgICAgICAgfA0KICAgICAgICAgICAgICAgICBBOjoxICAgfCAgICAgICAgKy0tLS0tLS0t LS0rICAgICAgICB8ICBBOjoxDQogICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgKy0tLSstLS0r ICAgICAgICAgICAgICAgICAgICArLS0tKy0tLSsNCiAgICAgICAgICAgICAgICAgICB8IEhvc3Qx ICAgfCAgICAgICAgICAgICAgICAgICAgICB8IEhvc3QyICB8DQogICAgICAgICAgICAgICAgICAg Ky0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0rDQoNCkFzc3VtZSB0aGVyZSBp cyBhIGhvc3Qgd2l0aCBhZGRyZXNzIEE6OjEgaW4gdGhlIGZpcnN0IGxpbmsuIFRoZW4gYW5vdGhl ciBob3N0IGFycml2ZXMgDQphdCB0aGUgc2Vjb25kIGxpbmsgYW5kIGZvcm1zIGFuIGFkZHJlc3Mg d2l0aCBzdGF0ZWxlc3MgYWRkcmVzcyBhdXRvY29uZmlndXJhdGlvbi4gDQpUaGUgc2Vjb25kIGhv c3QgaGFwcGVucyB0byBoYXZlIDEgYXMgaXRzIGludGVyZmFjZSBpZCBhbmQgcGlja3MgQTo6MSBh cyBpdHMgYWRkcmVzcy4gDQpUaGVuLCBldmVuIHRob3VnaCB0aGUgc2Vjb25kIGhvc3QgcGVyZm9y bXMgREFELCBpdCBjYW4gbm90IGRldGVjdCB0aGUgZHVwbGljYXRlIA0KYWRkcmVzcyBvbiB0aGUg Zmlyc3QgbGluay4gDQoNClRoZSBjdXJyZW50IERBRCBzY2hlbWUgY2FuIGd1YXJhbnRlZSB0aGUg dW5pcXVlbmVzcyBvZiBhbiBhZGRyZXNzIG9ubHkgaW5zaWRlDQphIGxpbmsuIEl0IHVzZXMgdGhl IE5laWdoYm9yIFNvbGljaXRhdGlvbi9OZWlnaGJvciBBZHZlcnRpc2VtZW50IG1lc3NhZ2UgZXhj aGFuZ2UgDQp0byBkZXRlY3QgZHVwbGljYXRlIGFkZHJlc3MuIEJlY2F1c2UgdGhlIG1lc3NhZ2Vz IGNhbid0IGdvIG92ZXIgYSByb3V0ZXIsIERBRCBtYXkgDQpub3QgZGV0ZWN0IGEgZHVwbGljYXRl IGFkZHJlc3MgaW4gYW4gYW5vdGhlciBsaW5rLg0KDQp0aGVyZSBpcyBzb21lIGRpc2N1c3Npb24g b24gdGhpcyBhdCBTZWMgMi40IG9mIA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtamluY2hvaS1pcHY2LWNyYS0wMC50eHQNCg0KQmVzdCByZWdhcmRzDQoNCkppbkh5 ZW9jaw== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 07:34:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09736 for ; Mon, 27 Oct 2003 07:34:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6ZR-00052J-7C for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 07:34:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RCY4OZ019231 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 07:34:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6ZQ-0004yV-IK for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 07:34:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09653 for ; Mon, 27 Oct 2003 07:33:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE6ZP-0004AH-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 07:34:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE6ZP-0004AE-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 07:34:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6ZP-0004tN-CF; Mon, 27 Oct 2003 07:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6Z3-0004lm-4n for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 07:33:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09591 for ; Mon, 27 Oct 2003 07:33:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE6Z2-00049l-00 for ipv6@ietf.org; Mon, 27 Oct 2003 07:33:40 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AE6Z1-00048w-00 for ipv6@ietf.org; Mon, 27 Oct 2003 07:33:40 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RDMTH>; Mon, 27 Oct 2003 07:32:58 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E29@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Erik Nordmark'" , Vijay Devarapalli Cc: Soliman Hesham , ipv6@ietf.org Subject: RE: RFC 2461- issue list Date: Mon, 27 Oct 2003 07:32:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > > no R bit. always include the global address configured from the > > prefix instead of just the prefix. the prefix can always be > > obtained using the prefix length field. > > Two issues: > - The router might not have an address in every prefix it > advertises. > Should a host still that the prefix field is indeed a useful > address for the router in that case? > - Existing routers do not put their address in the prefix > option even > when the router has an address in that prefix. > Should a host still that the prefix field is indeed a useful > address for the router in that case? > > If we want to add this to 2461bis I think we must add the > "R" bit as well. => Yes, given that we can put the R bit in the spec this seems like a good way to move forwad. Vijay, I'm assuming that you don't have an objection to adding the R bit anyway. So let's do that. Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 07:50:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10471 for ; Mon, 27 Oct 2003 07:50:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6p9-0006ue-Pq for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 07:50:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RCoJ7T026566 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 07:50:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6p9-0006uP-JR for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 07:50:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10433 for ; Mon, 27 Oct 2003 07:50:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE6p8-0004QO-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 07:50:18 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE6p8-0004QK-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 07:50:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6ot-0006kv-9P; Mon, 27 Oct 2003 07:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6o9-0006hq-Mq for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 07:49:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10412 for ; Mon, 27 Oct 2003 07:49:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE6o8-0004Q9-00 for ipv6@ietf.org; Mon, 27 Oct 2003 07:49:16 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE6o7-0004Q0-00 for ipv6@ietf.org; Mon, 27 Oct 2003 07:49:16 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9RCm7N09632; Mon, 27 Oct 2003 14:48:07 +0200 Date: Mon, 27 Oct 2003 14:48:07 +0200 (EET) From: Pekka Savola To: Fred Templin cc: Jun-ichiro itojun Hagino , , Subject: Re: "RFC 2461bis" issue: MTU handling In-Reply-To: <3F999EC3.8020508@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Fri, 24 Oct 2003, Fred Templin wrote: > 1) Peer-to-peer wireless (e.g. IEEE 802.11): > On certain wireless media, receiver A can sense QoS metrics (e.g. SNR) > for the packets it receives from senders B and C. If the SNR for B > is strong, > A may wish to inform B that a larger MTU (e.g. 1500 bytes) is > acceptable. > Conversely, if the SNR for C is weak, A may wish to inform C that a > smaller > MTU (e.g. 1300 bytes) is desired. This kind of dynamic MTU negotiation (requires at least one round-trip!) seems rather complex to me. Even more so that the original proposal seemed to be ("node A advertises that a larger MTU is OK"). > 2) Constrained nodes on large links: > On large-MTU media (e.g., HiPPI, Gig-E, etc.), nodes with small > receive buffers > (e.g. boot ROMs, embedded devices) may wish to receive smaller > packets than > the MTU for the link. For example, a constrained node on a link with > MTU of > 64KB may wish to inform a neighbor that an MTU of 10KB is desired. Are you sure such deployments are feasible to begin with? Such low-end equipment is very unlikely equipped with e.g. Gig-E interfaces. (Note: Gig-E MTU maximum is about 9K already, so it's a bit more reasonable than 64K.) (from Fred's another message on the list:) > We must face facts that there are multiple access, shared-media links > out there and will continue to be for the forseeable future. We can wish > for a densely-connected mesh of point-to-point links (e.g., ATM PVCs) > but we needs-be have to support the L2 infrastructure that is already > deployed. (Otherwise, we would have to go through an L2 transition > before we even begin to tackle the IPv6 transition.) Sure. There are tradeoffs in every kind of media. A typical assumption for most kinds of multi-access shared-media links is that they have similar properties regarding MTU. This is also the case for larger MTU's. This problem is nowhere near non-trivial. Consider e.g. an IPv6 link which is separated by two Ethernet switches, one which supports jumboframes (MTU=9K) and one which does not. How would the hosts be able to, with simple and robust mechanisms, to determine the MTUs to be used on such environment? The dynamic, wireless multiple-access media seems to have even more challenging problems of having to probe and adjust MTU's all the time. Think about an application using UDP (ie., has to do optimize for the MTU value itself) that runs longer than the lifetime of this probing. You expect these to adjust all the time as well? This approach seems to be adding complexity of L2 to IP layer where it doesn't belong. If we need to tackle this issue at L3, why not just simply use MTU 1280 or MTU 1500 and fragment the packet when needed? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 09:06:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13410 for ; Mon, 27 Oct 2003 09:06:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE80A-0004eV-I4 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 09:05:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RE5kWX017877 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 09:05:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE80A-0004eG-BL for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 09:05:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13368 for ; Mon, 27 Oct 2003 09:05:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE808-0005KE-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 09:05:44 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE808-0005KB-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 09:05:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE7zS-0004SM-CC; Mon, 27 Oct 2003 09:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE7yc-0004LA-42 for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 09:04:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13259 for ; Mon, 27 Oct 2003 09:03:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE7ya-0005IL-00 for ipv6@ietf.org; Mon, 27 Oct 2003 09:04:08 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE7yZ-0005Hg-00 for ipv6@ietf.org; Mon, 27 Oct 2003 09:04:07 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9RE3XQ10629; Mon, 27 Oct 2003 16:03:34 +0200 Date: Mon, 27 Oct 2003 16:03:32 +0200 (EET) From: Pekka Savola To: ipv6@ietf.org cc: jim.bound@hp.com Subject: discussion on v6ops-v6onbydefault and v6ops-onlinkassumption In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B047CA19E@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Sat, 25 Oct 2003, Bound, Jim wrote: > Review input on draft-ietf-v6ops-onlinkassumption-00.txt and suggestions > for next steps. (For information to those who'd like to follow up on Jim's two review messages..) I think it would be useful to continue the debate on: draft-ietf-v6ops-onlinkassumption and draft-ietf-v6ops-v6onbydefault .. documents on the v6ops list, v6ops@ops.ietf.org, to ensure that the document editors and the WG don't miss any parts of discussion on these documents. The draft-ietf-v6ops-onlinkassumption could also be additionally Cc:'ed to th IPv6 WG as it's more pertinent to the current discussion of revising RFC2461 and the IPv6 WG members may be interested to stay on the loop.. Writing as *visiting* v6ops WG co-chair :-), Pekka -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 11:02:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21765 for ; Mon, 27 Oct 2003 11:02:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE9oL-0001Uv-VZ for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 11:01:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RG1fqT005751 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 11:01:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE9oL-0001Ug-PE for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 11:01:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21734 for ; Mon, 27 Oct 2003 11:01:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE9oJ-00077e-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 11:01:39 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE9oI-00077Z-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 11:01:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE9ni-0001Jt-Vj; Mon, 27 Oct 2003 11:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE9mu-0001Ad-9p for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 11:00:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21566 for ; Mon, 27 Oct 2003 10:59:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE9mo-00075h-00 for ipv6@ietf.org; Mon, 27 Oct 2003 11:00:06 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AE9mn-00075G-00 for ipv6@ietf.org; Mon, 27 Oct 2003 11:00:05 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9RFxVe28308; Mon, 27 Oct 2003 07:59:31 -0800 X-mProtect: <200310271559> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZVsSp0; Mon, 27 Oct 2003 07:59:30 PST Message-ID: <3F9D4178.3030403@iprg.nokia.com> Date: Mon, 27 Oct 2003 08:02:00 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: Soliman Hesham , ipv6@ietf.org Subject: Re: RFC 2461- issue list References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>no R bit. always include the global address configured from the >>prefix instead of just the prefix. the prefix can always be >>obtained using the prefix length field. > > > Two issues: > - The router might not have an address in every prefix it advertises. > Should a host still that the prefix field is indeed a useful > address for the router in that case? > - Existing routers do not put their address in the prefix option even > when the router has an address in that prefix. > Should a host still that the prefix field is indeed a useful > address for the router in that case? it is easy for a host to distinguish between a 128 bit address and a prefix. > > If we want to add this to 2461bis I think we must add the "R" bit as well. either way is fine with me. I was trying to see if it can be done without using a bit. Vijay -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 13:36:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29036 for ; Mon, 27 Oct 2003 13:36:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AECDO-00005K-7u for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 13:35:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RIZg5h000320 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 13:35:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AECDO-000055-2z for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 13:35:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28967 for ; Mon, 27 Oct 2003 13:35:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AECDL-0001gn-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 13:35:39 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AECDL-0001gh-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 13:35:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AECCl-0008Ou-GC; Mon, 27 Oct 2003 13:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AECCd-0008Nt-6y for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 13:34:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28927 for ; Mon, 27 Oct 2003 13:34:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AECCa-0001g4-00 for ipv6@ietf.org; Mon, 27 Oct 2003 13:34:52 -0500 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1AECCa-0001fT-00 for ipv6@ietf.org; Mon, 27 Oct 2003 13:34:52 -0500 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9RIYBee083066; Mon, 27 Oct 2003 19:34:21 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2A5F7E62-08AC-11D8-AD90-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: "" From: Iljitsch van Beijnum Subject: Re: "RFC 2461bis" issue: MTU handling Date: Mon, 27 Oct 2003 19:34:14 +0100 To: Pekka Savola X-Mailer: Apple Mail (2.604) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 27 okt 2003, at 13:48, Pekka Savola wrote: >> If the SNR for B is strong, A may wish to inform B that a larger MTU >> (e.g. 1500 bytes) is acceptable. Conversely, if the SNR for C is >> weak, A may wish to inform C that a smaller MTU (e.g. 1300 bytes) is >> desired. > This kind of dynamic MTU negotiation (requires at least one > round-trip!) > seems rather complex to me. Even more so that the original proposal > seemed to be ("node A advertises that a larger MTU is OK"). There is no need for any full-blown negotiation. A node can simply announce the desired/supported maximum packet size at the time of neighbor discovery and be done with it. >> 2) Constrained nodes on large links: On large-MTU media (e.g., HiPPI, >> Gig-E, etc.), nodes with small receive buffers (e.g. boot ROMs, >> embedded devices) may wish to receive smaller packets than >> the MTU for the link. > Are you sure such deployments are feasible to begin with? Such low-end > equipment is very unlikely equipped with e.g. Gig-E interfaces. (Note: > Gig-E MTU maximum is about 9K already, so it's a bit more reasonable > than 64K.) Hm, if we look back 15 years we see that hosts needed to support 1500 bytes for 10 Mbps ethernet. A typical example of such a host was a PC with less than 1 MB memory. Today networks are 100 times as fast (GE is now cheaper than 10 Mbps 15 years ago), we typically have 500 times as much memory but our maximum packet size has increased by a whopping six times... I agree that it is unlikely a host with GE or similar would be unable to support a decent maximum packet size, but it can't hurt to have the option of triggering a smaller packet size. > A typical assumption > for most kinds of multi-access shared-media links is that they have > similar properties regarding MTU. Shared media? That is sooo last century... > This is also the case for larger MTU's. > This problem is nowhere near non-trivial. Consider e.g. an IPv6 link > which is separated by two Ethernet switches, one which supports > jumboframes (MTU=9K) and one which does not. How would the hosts be > able > to, with simple and robust mechanisms, to determine the MTUs to be > used on > such environment? This is why we need routers to explicitly advertise the maximum MTU using a new option. It is unlikely that people who need the extra performance gained by the use of jumboframes are also the ones that hook up a $20 switch to a $600 one. It wouldn't hurt if the IEEE picked this up, though. > The dynamic, wireless multiple-access media seems to have even more > challenging problems of having to probe and adjust MTU's all the time. 802.11 does this at layer 2, which seems the right thing to do. > Think about an application using UDP (ie., has to do optimize for the > MTU > value itself) that runs longer than the lifetime of this probing. You > expect these to adjust all the time as well? > This approach seems to be adding complexity of L2 to IP layer where it > doesn't belong. If we need to tackle this issue at L3, why not just > simply use MTU 1280 or MTU 1500 and fragment the packet when needed? In IPv6, fragmentation overhead is too hideous and probably not supported below 1280 bytes without changes anyway. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 13:39:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29299 for ; Mon, 27 Oct 2003 13:39:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AECGn-0000zt-9l for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 13:39:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RIdDkc003827 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 13:39:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AECGn-0000ze-2x for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 13:39:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29253 for ; Mon, 27 Oct 2003 13:39:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AECGk-0001kL-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 13:39:10 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AECGk-0001kI-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 13:39:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AECGd-0000tP-BU; Mon, 27 Oct 2003 13:39:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AECGF-0000pD-Gt for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 13:38:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29220 for ; Mon, 27 Oct 2003 13:38:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AECGD-0001kC-00 for ipv6@ietf.org; Mon, 27 Oct 2003 13:38:37 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AECGC-0001jl-00 for ipv6@ietf.org; Mon, 27 Oct 2003 13:38:36 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9RIbuT13516; Mon, 27 Oct 2003 10:37:56 -0800 X-mProtect: <200310271837> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpvMxSK; Mon, 27 Oct 2003 10:37:55 PST Message-ID: <3F9D6738.3010901@iprg.nokia.com> Date: Mon, 27 Oct 2003 10:43:04 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bound, Jim" CC: Iljitsch van Beijnum , ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: MTU handling References: <9C422444DE99BC46B3AD3C6EAFC9711B051221A9@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks Jim, Fred ftemplin@iprg.nokia.com Bound, Jim wrote: >I believe there is another option. Develop new spec that does number 3 >below to add to 2461 and leave 2461 alone. This would be a spec >defining a new option for 2461. > >/jim > > > >>-----Original Message----- >>From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On >>Behalf Of Fred Templin >>Sent: Friday, October 24, 2003 9:06 PM >>To: Iljitsch van Beijnum >>Cc: ipv6@ietf.org >>Subject: Re: "RFC 2461bis" issue: MTU handling >> >> >>I see (at least) three ways for the neighbor-to-neighbor MTU >>negotiation; two were presented in my drafts and the third is >>presented by Iljitsch here. The methods are: >> >> 1) Change RFC 2461 to allow NA messages to include MTU options: >> Advantages: >> - Unambiguous mechanism for NA's to inform of a >>per-neighbor MTU value >> Disadvantages: >> - Requires modification to RFC 2461 >> - May require extra ND messages, since the interpretation of >> MTU options is different for RAs >> >> 2) No changes to RFC 2461; allow "IPv6-over-foo" documents to >> specify different interpretations of the MTU option in RA's: >> Advantages: >> - No modifications to RFC 2461 >> Disadvantages: >> - Ambiguous interpretation of MTU options in RAs, or the >> specified interpretation (MTU for the entire link) is disabled >> - MTU option only available for RAs; not NAs >> >> 3) Change RFC 2461 to specify a new "NBR_MTU" option that >> can be sent with either NA's or RAs: >> Advantages: >> - Unambiguous mechanism to inform of a per-neighbor MTU value >> - Can be used with either NAs or RAs w/o altering the >>interpretation >> of the existing MTU option >> - Maximum efficiency, since it can be used with either >>NAs or RAs >> Disadvantages: >> - Requires modifications to RFC 2461 >> >>So, it should be clear from the above analysis that I support >>Iljitsch's proposal in terms of what should go into RFC 2461. >>It is a sensible approach for a valuable mechanism and I >>think folks should give it the consideration it deserves. >> >>Fred >>ftemplin@iprg.nokia.com >> >>Iljitsch van Beijnum wrote: >> >> >> >>>I'm not sure this should go into a replacement specification for RFC >>>2461, but I'll bring it up anyway: >>> >>>Currently, routers can advertise an MTU for a link. That's nice. But >>>what we really need is a way for hosts to find out the MTU each >>>individual neighbor can handle. 100 Mbps and slower ethernet >>>interfaces can typically handle only the standard 1500 byte >>> >>> >>ethernet >> >> >>>MTU, while gigabit ethernet interfaces usually support a >>> >>> >>much larger MTU. >> >> >>>However, in most cases hosts with different MTUs are present on the >>>same subnet, so simply advertising a larger MTU wouldn't >>> >>> >>solve this. >> >> >>>(Not that this would work anyway as hosts are instructed to only >>>listen to MTU advertisements where the MTU is between 1280 and 1500 >>>(for ethernet).) >>> >>>But if hosts can tell each other the MTU they support, each >>> >>> >>set of two >> >> >>>hosts is always able to use the largest possible MTU between them. >>>(This would also require a new link MTU option that conveys the >>>maximum MTU the lower layer equipment supports. Switches have their >>>own MTU and even some hubs start doing strange things when a larger >>>than expected MTU is used.) >>> >>>BTW, some duplication seems to have crept into the document: >>> >>> variable MTU - a link that does not have a >>> >>> >>well-defined MTU (e.g., >> >> >>> IEEE 802.5 token rings). Many links (e.g., >>> Ethernet) have a standard MTU defined >>> >>> >>by the link- >> >> >>> layer protocol or by the specific document >>> describing how to run IP over the link layer. >>> >>> variable MTU - Neighbor Discovery allows routers to >>> >>> >>specify a MTU >> >> >>> for the link, which all nodes then >>> >>> >>use. All nodes >> >> >>> on a link must use the same MTU (or Maximum >>> Receive Unit) in order for multicast to work >>> properly. Otherwise when >>> >>> >>multicasting a sender, >> >> >>> which can not know which nodes will >>> >>> >>receive the >> >> >>> packet, could not determine a minimum >>> >>> >>packet size >> >> >>> all receivers can process. >>> >>> >>>-------------------------------------------------------------------- >>>IETF IPv6 working group mailing list >>>ipv6@ietf.org >>>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>>-------------------------------------------------------------------- >>> >>> >> >> >>-------------------------------------------------------------------- >>IETF IPv6 working group mailing list >>ipv6@ietf.org >>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>-------------------------------------------------------------------- >> >> >> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 13:54:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00200 for ; Mon, 27 Oct 2003 13:54:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AECVE-0003Md-VI for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 13:54:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RIs8ux012926 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 13:54:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AECVE-0003MP-Ql for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 13:54:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00166 for ; Mon, 27 Oct 2003 13:53:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AECVC-00022Z-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 13:54:06 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AECVB-00022W-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 13:54:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AECV7-0003HT-30; Mon, 27 Oct 2003 13:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AECUm-0003Ce-7W for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 13:53:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00128 for ; Mon, 27 Oct 2003 13:53:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AECUj-00021r-00 for ipv6@ietf.org; Mon, 27 Oct 2003 13:53:37 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AECUj-000211-00 for ipv6@ietf.org; Mon, 27 Oct 2003 13:53:37 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9RIr3H15170; Mon, 27 Oct 2003 20:53:03 +0200 Date: Mon, 27 Oct 2003 20:53:03 +0200 (EET) From: Pekka Savola To: Iljitsch van Beijnum cc: "" Subject: Re: "RFC 2461bis" issue: MTU handling In-Reply-To: <2A5F7E62-08AC-11D8-AD90-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Mon, 27 Oct 2003, Iljitsch van Beijnum wrote: > There is no need for any full-blown negotiation. A node can simply > announce the desired/supported maximum packet size at the time of > neighbor discovery and be done with it. Some seem to want a full-blown option as well. Whether there would consensus to support it would be a different topic.. > I agree that it is unlikely a host with GE or similar would be unable > to support a decent maximum packet size, but it can't hurt to have the > option of triggering a smaller packet size. If such nodes are not expected to be common, it would seem to make sense to separate these very constrained nodes to a separate subnet (not necessarily even a separate link) if the full MTU size seems like a lucrative option. > > This is also the case for larger MTU's. This problem is nowhere near > > non-trivial. Consider e.g. an IPv6 link which is separated by two > > Ethernet switches, one which supports jumboframes (MTU=9K) and one > > which does not. How would the hosts be able to, with simple and > > robust mechanisms, to determine the MTUs to be used on such > > environment? > > This is why we need routers to explicitly advertise the maximum MTU > using a new option. No need for that, already supported now :-). > It is unlikely that people who need the extra > performance gained by the use of jumboframes are also the ones that > hook up a $20 switch to a $600 one. You would be surprised which vendors don't support jumbograms. The bit more expensive ones as well, for example, HP (very widely used around here at least). > > This approach seems to be adding complexity of L2 to IP layer where it > > doesn't belong. If we need to tackle this issue at L3, why not just > > simply use MTU 1280 or MTU 1500 and fragment the packet when needed? > > In IPv6, fragmentation overhead is too hideous and probably not > supported below 1280 bytes without changes anyway. But if this was only needed for very constrained nodes, one could argue that such nodes probably don't need do heavy communication anyway (otherwise they wouldn't be constrained nodes :-), so this shouldn't be a problem.. :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 14:47:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03389 for ; Mon, 27 Oct 2003 14:47:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEDKs-0008Dw-Ip for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 14:47:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RJlUEw031612 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 14:47:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEDKs-0008Dm-8D for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 14:47:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03349 for ; Mon, 27 Oct 2003 14:47:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEDKp-00034J-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 14:47:27 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEDKp-00034G-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 14:47:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEDKP-00087H-P0; Mon, 27 Oct 2003 14:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEDJd-00084G-Kb for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 14:46:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03292 for ; Mon, 27 Oct 2003 14:46:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEDJa-000335-00 for ipv6@ietf.org; Mon, 27 Oct 2003 14:46:10 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AEDJa-00032b-00 for ipv6@ietf.org; Mon, 27 Oct 2003 14:46:10 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9RJjXs08213; Mon, 27 Oct 2003 11:45:33 -0800 X-mProtect: <200310271945> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVUS1vf; Mon, 27 Oct 2003 11:45:31 PST Message-ID: <3F9D7711.7080904@iprg.nokia.com> Date: Mon, 27 Oct 2003 11:50:41 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: ipv6@ietf.org Subject: Re: draft-templin-tunnelmtu-01.txt References: <3F99C926.3090200@iprg.nokia.com> <23720522-070E-11D8-BE4E-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > On 25 okt 2003, at 2:51, Fred Templin wrote: > >> General comment - it would be nice if folks would reveiw and comment >> on my drafts: >> http://www.ietf.org/internet-drafts/draft-templin-ndiscmtu-00.txt >> http://www.ietf.org/internet-drafts/draft-templin-tunnelmtu-01.txt > > > Ok, the second one first: > > As far as I can tell, not being someone who builds routers, some of > the mechanisms outlined here are problematic. For instance, > determining whether the IP packet that carries a tunneled packet was > fragmented means transferring information from one place in the > architecture (reception and reassembly of IP packets) to another > (handling protocol 41). (We are talking here about the specific instance of IPv4 used as a link-layer for IPv6.) Your point about instrumenting the IPv4 reassembly code is well taken. But, this is just one option and perhaps not the best for all architectues. For example, Linux offers a "packet socket" abstraction ("man 7 packet") whereby an application can capture selected L2 packets based on filters. It is a rather trivial thing to write a Linux packet socket filter that captures all IPv4 packets with fragment headers for ip-proto-41 w/o having to touch a line of kernel code. The only arguement then becomes one of performance, since ip-proto-41 fragmented packets would be handled at the application level. But, the protocol is designed to naturally minimize the number of fragmented packets for ip-proto-41 so fast-path processing is not necessary. > Another: doing a router sollicitation triggered by wanting to transmit > a packet of a certain size is not a good thing. You've gotten wires crossed between Method 1 (section 3.3.1) and Method 2 (section 3.2) in my draft. Method 1 uses fragmentation sensing in the receiver as the method for detecting path MTU changes and does not require the encapsulator to send an RS triggered by wanting to send a packet of a certain size. In the fragmentation sensing method, each data packet also serves as a probe packet w/o having to introduce any additional messages. (Method 2 does suggest on-demand probing based on the arrival of large packets, but it is intended only for those circumstances in which the fragmentation-sensing scheme is not supported.) > But why bother in the first place? > > Presonally, I would happily let my tunnel packets be fragmented as > this way I don't incur a reduced MTU when using a tunnel. Yes, *you* might be happy about letting your tunnel packets be fragmented, but would the *network* be happy about it? Certainly not. A quick read of "Fragmentation Considered Harmful" and "Beyond Folklore: Observations on Fragmented Traffic" should easily convince you of this. See: http://research.compaq.com/wrl/techreports/abstracts/87.3.html http://www.caida.org/outreach/papers/2002/Frag/ > Sure, this costs extra CPU time for the tunnel endpoints but in most > cases this isn't a problem. See the above documents. It isn't so much the CPU time for the tunnel endpoints we are concerned with as the case of fragments lost due to congestion which results in a loss unit (a packet fragment) that is smaller than the retransmission unit (a packet). So, I take back my statement above that "you" might be happy about letting your tunneled packets be fragmented since the original source of the large packets will also suffer in the long run. > And when it is, the tunnel endpoints should be able to do PMTUD over > the tunnel. IPv4 PMTUD you mean? If so, please see the second paragraph in the introduction of my document for why this is undesireable in terms of efficiency and robustness. > And if that doesn't work, it's always possible to configure a smaller MTU. Well, the smallest static MTU we can assign for IPv6-in-IPv4 tunnels is 1280 bytes, since 1280 is the min MTU for IPv6 interfaces. Even at that size, however, it is still possible that we might encounter IPv4 paths that will fragment the 1280byte packets due to, e.g., too many nested layers of encapsulation. > Don't forget that tunnels are typically pretty static so once > everything is set up, there shouldn't be too many surprises. The only static thing about the tunnels is the endpoints. The intervening IPv4 path may be arbitrarily long and dynamically fluctuating. That's why path MTU discovery can never be a once-and-done deal but must be continuous throughout the tunnel's operational lifetime. > I think this draft is solving a non-problem. Please re-read and reconsider in light of the above. Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 15:08:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04906 for ; Mon, 27 Oct 2003 15:08:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEDer-0002Lm-Mc for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 15:08:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RK89H6009028 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 15:08:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEDer-0002LG-1M for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 15:08:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04817 for ; Mon, 27 Oct 2003 15:07:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEDen-0003Pt-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 15:08:06 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEDen-0003Pq-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 15:08:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEDek-0002Dr-G1; Mon, 27 Oct 2003 15:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEDe7-00023C-Qf for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 15:07:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04717 for ; Mon, 27 Oct 2003 15:07:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEDe4-0003PB-00 for ipv6@ietf.org; Mon, 27 Oct 2003 15:07:20 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AEDe4-0003P8-00 for ipv6@ietf.org; Mon, 27 Oct 2003 15:07:20 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:806f:7e97:fbcc:e7ff]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4629215214 for ; Tue, 28 Oct 2003 05:07:17 +0900 (JST) Date: Tue, 28 Oct 2003 05:07:17 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: rfc2462bis-00 User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hello, I submitted an update version of RFC2462 as an individual draft on Oct. 20th (and received an acknowledgment of the submission), but I've never seen an announcement of the draft. The announcement may just be delayed, but I now suspect something unexpected happened and the submitted draft was lost. So I've put a copy of the draft at the following URL: http://www.jinmei.org/draft-jinmei-ipv6-rfc2462bis-00.txt Comments are welcome, though it basically just contains the issue list I posted the other day. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 15:22:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06721 for ; Mon, 27 Oct 2003 15:22:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEDsT-0004fS-UM for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 15:22:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RKMDgh017936 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 15:22:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEDsT-0004fD-NM for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 15:22:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06619 for ; Mon, 27 Oct 2003 15:22:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEDsS-0003hM-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 15:22:12 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEDsR-0003hG-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 15:22:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEDsI-0004Vg-4a; Mon, 27 Oct 2003 15:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEDrt-0004Se-MV for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 15:21:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06553 for ; Mon, 27 Oct 2003 15:21:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEDrr-0003fu-00 for ipv6@ietf.org; Mon, 27 Oct 2003 15:21:35 -0500 Received: from [195.167.170.152] (helo=bowl.fysh.org ident=mail) by ietf-mx with esmtp (Exim 4.12) id 1AEDrr-0003fW-00 for ipv6@ietf.org; Mon, 27 Oct 2003 15:21:35 -0500 Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 1AEDrj-0005Im-00; Mon, 27 Oct 2003 20:21:27 +0000 Date: Mon, 27 Oct 2003 20:21:27 +0000 To: "JINMEI Tatuya / ?$B?@L@C#:H" Cc: ipv6@ietf.org Subject: Re: rfc2462bis-00 Message-ID: <20031027202127.GA20198@fysh.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: Zefram Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , JINMEI Tatuya / ?$B?@L@C#:H wrote: >I submitted an update version of RFC2462 as an individual draft on >Oct. 20th That was the cutoff date for initial-version submissions, so you probably just missed it. -zefram -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 16:01:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10106 for ; Mon, 27 Oct 2003 16:01:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEETx-0000uR-BZ for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 16:00:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RL0v3Q003489 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 16:00:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEETx-0000uC-6P for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 16:00:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10024 for ; Mon, 27 Oct 2003 16:00:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEETv-0004WT-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 16:00:55 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEETu-0004WQ-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 16:00:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEET8-0000le-IM; Mon, 27 Oct 2003 16:00:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEESm-0000jl-Ii for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 15:59:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09942 for ; Mon, 27 Oct 2003 15:59:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEESk-0004WA-00 for ipv6@ietf.org; Mon, 27 Oct 2003 15:59:42 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AEESk-0004W7-00 for ipv6@ietf.org; Mon, 27 Oct 2003 15:59:42 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:806f:7e97:fbcc:e7ff]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 873A515210 for ; Tue, 28 Oct 2003 05:59:40 +0900 (JST) Date: Tue, 28 Oct 2003 05:59:40 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: Re: rfc2462bis-00 In-Reply-To: <20031027202127.GA20198@fysh.org> References: <20031027202127.GA20198@fysh.org> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >>>>> On Mon, 27 Oct 2003 20:21:27 +0000, >>>>> Zefram said: >> I submitted an update version of RFC2462 as an individual draft on >> Oct. 20th > That was the cutoff date for initial-version submissions, so you probably > just missed it. I know, but in that case, the auto-reply acknowledgment should say I missed the cutoff deadline, as far as I know. I got an "ordinary" acknowledgment, so I assumed the draft was accepted. wg members: I apologize in advance if you feel noisy on this "submission procedure" stuff. I won't make any further post on this particular topic. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 18:10:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26660 for ; Mon, 27 Oct 2003 18:10:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEGUn-0005zO-0p for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 18:10:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RN9uJd023022 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 18:09:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEGUm-0005zF-Qu for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 18:09:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26597 for ; Mon, 27 Oct 2003 18:09:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEGUj-0001Ud-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 18:09:53 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEGUj-0001Ua-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 18:09:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEGTu-0005ir-71; Mon, 27 Oct 2003 18:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEGT3-0005bp-Lt for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 18:08:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26369 for ; Mon, 27 Oct 2003 18:07:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEGT0-0001TJ-00 for ipv6@ietf.org; Mon, 27 Oct 2003 18:08:06 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AEGSz-0001ST-00 for ipv6@ietf.org; Mon, 27 Oct 2003 18:08:06 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9RN7Rr27734; Mon, 27 Oct 2003 15:07:27 -0800 X-mProtect: <200310272307> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJizDdg; Mon, 27 Oct 2003 15:07:26 PST Message-ID: <3F9DA665.6000403@iprg.nokia.com> Date: Mon, 27 Oct 2003 15:12:37 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: MTU handling References: <3F99C926.3090200@iprg.nokia.com> <99D382A8-0735-11D8-BE4E-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > On 25 okt 2003, at 2:51, Fred Templin wrote: > >>> So one approach would be something like having a router >>> advertisement option that asserts "trust us; the L2 can in fact >>> support 9k" resulting in individual hosts deciding to send out an >>> option with their NS/NA saying "I can support receiving 9k". >> > > Right, that's what I was talking about. > >> Agree with the hosts sending ND messages saying: >> "I can support receiving 9K" but not necessarily with the >> rotuer saying "trust us; the L2 can in fact support 9k". The >> router should be advertising the lowest-common-denominator >> for all nodes on the link. > > > It's already doing that today. The "L2 can do 9k" indication should go > into a new message (option). >> Nodes that can accept more than the lowest-common denominator >> should negotiate a larger MTU with their neighbors - even if the >> value they negotiate is larger than what is being sent in the MTU >> option in RA's. > > > Yes, but they must be aware of what the layer 2 equipment can handle. > If I hook up two boxes that can do 9000 bytes over ethernet, but the > switch is 1500 bytes only, I had better make sure those two boxes > stick to 1500. Yes, I know. By "negotiate a larger MTU" I mean not only an initial indication of how much the *neighbor* can handle but also ongoing and continuous attention to how much the *L2 media* can handle. >> (Similarly, nodes that prefer smaller than the LCD >> should negotiate a smaller MTU - even though they still need to >> support the LCD for broadcast/multicast.) > > > The good thing is that if we allow hosts to discover the maximum > usable MTU between them, we can now use the regular RA MTU option to > broadcast a much smaller MTU for this type of traffic. But, if there are many routers on the link, what do you do if they aren't all broadcasting a consistent smaller MTU? RFC 2461 says to accept the most recently heard MTU - is that good enough? >>> This still has the operational issue of what happens when >>> I need extra ports in my office and I get a cheap 4-port hub; neither >>> the IT department nor my hosts knows that this box is present and it >>> might not support jumboframes. One way to cope with this particular >>> topology, >>> but no other topologies of varying frame size switches, would be >>> for the host to exchange a 9k packet with the router before >>> deciding that it should declare itself 9k capable. >> > > Who says the router can handle the maximum size packets on a link? In > a SOHO environment it's not unusual to have some pretty fast boxes > with gigabit ethernet that support 9000 bytes, but since the hookup to > the internet is only a few megabits, the router has 100 Mpbs or even > 10 Mbps ethernet, with no support for jumboframes. > > But an exchange using the advertised packet sizes between the two > hosts wanting to use larger packets wouldn't be a bad idea. Agreed. >> You could use something like an IPv6 NS message that is artificially >> inflated in size for this as we have discussed in the past. But, it's >> not >> a once-and-done deal; if you're going to be probing the MTU you need >> to do it periodically so that L2 path changes don't result in black >> holes. > > > ND times out pretty quickly, right? Then this happens pretty much > automatically. > >> General comment - it would be nice if folks would reveiw and comment >> on my drafts: >> http://www.ietf.org/internet-drafts/draft-templin-ndiscmtu-00.txt > > > Well, you don't waste many words. This must be the shortest draft I've > ever seen. Economy and effectiveness in written expression are ideals I continue to strive for. > You only consider the situation where the per-neighbor MTU is smaller > than the "official" link MTU as defined by the relevant "IPv6 over > ..." RFC or the MTU option in router advertisements. > > However, the situation where some hosts have the ability to use larger > packets than others and/or the official MTU could also easily be > addressed by the same mechanism. However, in that case there is the > additional complication that devices operating at lower layers (so > that they're unable to participate in IP layer mechanisms) may > restrict the maximum packet size. Now hopefully at some point layer 2 > mechanisms to deal with this will become available, but in the mean > time we need to solve this in IP. (I can imagine adding information > about the MTU to the ethernet autonegotiation protocol.) > > The way I see it, we can't touch the existing RA MTU option, because > that would lead to trouble with hosts that don't understand the new > way of handling the MTU. So the current RA MTU option would continue > to be used to advertise the minimum MRU (maximum receive unit) that > all hosts on the link must support. This value must be somewhere > between 1280 bytes and the value listed in the IP over RFC. Agreed. > Then there would be a new RA option that would function as the > "maximum MTU": hosts are not allowed to transmit packets larger than > this. This value must be equal to or higher than the IP over RFC value > if it's present. There could be a bit in this option that indicates > "if lower layers tell you it's ok to use this value" or "forget what > lower layers tell you, this value is the correct one". I'm afraid I'm not bought into this one as being necessary (yet). We know from our physical/logical point of attachment what the largest possible MTU for the attached L2 media is - this is a given. So, to supply a maximum MTU that is larger than the attached L2 media can support in a single packet is saying that we expect the sender to do L2 fragmentation locally. Is this what you are saying, and is this really desireable? (Maybe; I'm willing to be convinced.) > Finally there would be the per-neighbor MTU preference/capability > option. If the advertised neighbor MTU is smaller than the link MRU > this indicates that the neighbor is still able to receive packets upto > the size of the link MRU, but it prefers to receive smaller packets. > If the neighbor MTU is larger than the link MRU the neighbor is > capable of and willing to receive packets larger than the link MRU. In > that case, if the local system has a similar capability and > willingness, it may send packets of a size that is the minimum of the > local interface MTU, the link MMTU and the MTU advertised by the neighbor. Sure. > And if we're going to do this anyway, we may want to provide for a way > for routers to tell hosts what the largest packet size is that it can > forward. For instance, a simple IPv6-capable ADSL router obviously > supports a 1500 byte MTU on its ethernet interface, but if it uses a > tunnel for IPv6 connectivity it can't forward IPv6 packets that are > larger than 1480 bytes. So advertising this 1480 byte limit in a RA > option saves hosts from hitting PMTUD on the first hop all the time. > Also, if there is more than one router on the link and they support > different maximum routable packet sizes, the host can select the > router that supports the largest packets. Right - this goes along with a question I asked above. > Back to your draft. I would suggest making the draft a self-contained > set of new capabilities rather than going for updates of RFC 2461. > This should make both the technical and political aspects much less > painful. > > (Adding a new ND option type is an obvious IANA cosideration, BTW.) OK. Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 18:27:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27894 for ; Mon, 27 Oct 2003 18:27:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEGlZ-0007Oq-Dh for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 18:27:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RNRHcV028438 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 18:27:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEGlZ-0007Ob-77 for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 18:27:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27867 for ; Mon, 27 Oct 2003 18:27:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEGlW-0001jK-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 18:27:14 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEGlV-0001jH-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 18:27:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEGlK-0007Ko-FZ; Mon, 27 Oct 2003 18:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEGl4-0007K4-KD for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 18:26:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27819 for ; Mon, 27 Oct 2003 18:26:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEGl1-0001ix-00 for ipv6@ietf.org; Mon, 27 Oct 2003 18:26:43 -0500 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1AEGl0-0001iu-00 for ipv6@ietf.org; Mon, 27 Oct 2003 18:26:42 -0500 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9RNQZed086508; Tue, 28 Oct 2003 00:26:35 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <05693FDE-08D5-11D8-AD90-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: "" From: Iljitsch van Beijnum Subject: Re: "RFC 2461bis" issue: MTU handling Date: Tue, 28 Oct 2003 00:26:41 +0100 To: Pekka Savola X-Mailer: Apple Mail (2.604) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 27 okt 2003, at 19:53, Pekka Savola wrote: >>> This is also the case for larger MTU's. This problem is nowhere near >>> non-trivial. Consider e.g. an IPv6 link which is separated by two >>> Ethernet switches, one which supports jumboframes (MTU=9K) and one >>> which does not. How would the hosts be able to, with simple and >>> robust mechanisms, to determine the MTUs to be used on such >>> environment? >> This is why we need routers to explicitly advertise the maximum MTU >> using a new option. > No need for that, already supported now :-). No, the existing option is only usable for lowering the MTU used within a subnet to a value lower than what the "IP over ..." RFC prescribes. We also need a way to convey the maximum packet size that layer 2 equipment can handle. I think this should be an option that is similar to, but different from the existing MTU option. >> It is unlikely that people who need the extra >> performance gained by the use of jumboframes are also the ones that >> hook up a $20 switch to a $600 one. > You would be surprised which vendors don't support jumbograms. The bit > more expensive ones as well, for example, HP (very widely used around > here at least). Well in that case you have nothing to worry about and stick to 1500 bytes. :-) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 18:30:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28124 for ; Mon, 27 Oct 2003 18:30:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEGoM-00082u-Mp for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 18:30:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RNUASc030922 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 18:30:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEGoM-00082f-Hy for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 18:30:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28058 for ; Mon, 27 Oct 2003 18:29:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEGoJ-0001of-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 18:30:07 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEGoJ-0001oc-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 18:30:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEGoG-0007wp-8F; Mon, 27 Oct 2003 18:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEGnp-0007uf-GY for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 18:29:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28041 for ; Mon, 27 Oct 2003 18:29:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEGnm-0001ns-00 for ipv6@ietf.org; Mon, 27 Oct 2003 18:29:34 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AEGnl-0001le-00 for ipv6@ietf.org; Mon, 27 Oct 2003 18:29:33 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9RNStN10600; Mon, 27 Oct 2003 15:28:55 -0800 X-mProtect: <200310272328> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdDM9xz7; Mon, 27 Oct 2003 15:28:53 PST Message-ID: <3F9DAB6C.60702@iprg.nokia.com> Date: Mon, 27 Oct 2003 15:34:04 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: Iljitsch van Beijnum , ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: MTU handling References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>If you are probing to determine the initial PMTU, the answer is to send >>periodic additional probes, of course. Routes are going to flap, and paths >>are going to change - a once-probed MTU cannot be expected to remain >>stable for any set length of time. >> >> > >Did you really mean that? >Clearly there has to be some assumption about the frequency at which >the MTU can decrease. If not, for every e.g. TCP packet you send you would need >to send an MTU probe (with an ACK) to make sure that a (TCP) packet of that >size can make it to the neighbor. > No, we don't want to send an additional probe packet along with *every* data packet. If we can somehow use the data packets themselves as probe packets, then that would be a different story of course. One case in which data packets could be used as probe packets is when IPv4 is used as an L2 media for IPv6. In this case, we could send IPv6-in-IPv4 encapsulated packets with the DF bit NOT set in the IPv4 header expecting that the decapsulator would send us some sort of indication if it sensed fragmentation. But this begs the question of a fundamental design point: do we need to support sub-L2 media elements (i.e., the physical elements that sit below IPv4) that neither support IPv4 fragmentation nor send IPv4 "frag needed" messages when they can't forward a packet? Based on the 1Gbps/100Mbps Ethernet bridge example, I believe the answer to this is "yes" - would you agree? Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 18:46:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28972 for ; Mon, 27 Oct 2003 18:46:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEH3z-0001me-Ds for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 18:46:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RNkJ4J006850 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 18:46:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEH3z-0001mP-8t for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 18:46:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28945 for ; Mon, 27 Oct 2003 18:46:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEH3w-00026u-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 18:46:16 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEH3v-00026r-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 18:46:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEH3j-0001cs-6S; Mon, 27 Oct 2003 18:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEH3d-0001cA-CO for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 18:45:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28915 for ; Mon, 27 Oct 2003 18:45:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEH3a-00026V-00 for ipv6@ietf.org; Mon, 27 Oct 2003 18:45:54 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AEH3Z-000268-00 for ipv6@ietf.org; Mon, 27 Oct 2003 18:45:53 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9RNjMO23389; Mon, 27 Oct 2003 15:45:22 -0800 X-mProtect: <200310272345> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdWUmz4N; Mon, 27 Oct 2003 15:45:21 PST Message-ID: <3F9DAF48.9060902@iprg.nokia.com> Date: Mon, 27 Oct 2003 15:50:32 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: ipv6@ietf.org Subject: Re: draft-hain-templin-ipv6-localcomm-03.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Erik, Erik Nordmark wrote: >I have some on draft-hain-templin-ipv6-limitedrange-02.txt >which appear to apply to the new draft even though it has removed >the explicit reference to the need for a local address format >from the title and abstract/intro. > >The summary is that I think we need a discussion about the needs of >sites in general and these "active sites" in particular, but this >draft doesn't seem to do that. Details below. > >Comments on draft-hain-templin-ipv6-limitedrange-02.txt > >The document seems to make the case that there is a set of >interested goals and requirements related to "active sites", >and I agree that this is something that we need to understand >better. > >But the document from the outset, and in every other paragraph, >assumes that any and all solutions to to making such sites work better >involve defining some local address space. As a result the document reads >as an attempt to justify a particular solution to the problem, and not >as a balanced attempt to understand the issues relating to such sites and >the goals related to making them work better. > We have received this particular comment many times and from many different sources. The document has undergone significant modifications based on specific comments in a best effort to eliminate any perceived links to any specific solution alternative(s). If you are still seeing the document as advocating a particular solution alternative, please send specific text change suggestions as that is not the document's intention. >Thus I think we instead need goals for "active sites" with local and >global communication (taking into account that for different sites the >relative importance of global and local communication is likely to be >different). > >For those that think that there can't exist solutions which don't use >a local address space I offer 4 different possible approaches where only 1 >use local address space (and another uses local locators which are invisible >to the applications): > - unique local addresses plus TBD mechanisms for name resolution (DNS) > and application impact; a rather large TBD IMHO. See Keith's recent mail. > - for sites which are naturally part of some larger site using > Nemo (or just tunneling with delegated global addresses from the > larger site) just work. This approach doesn't handle > all types of active sites, but it doesn't seem to require any additional > standardizion - running DHCPv6 prefix delegation over IPv6-in-IPv6 > tunnels seems to be sufficient. > - relying on some multi6 solution (see draft-nordmark-multi6-noid and > draft-nordmark-multi6-sim as existance proof that such solutions can be > created, if nothing else [Thus this is not an endorsement that I think > those particular approaches are the best.]) > by using global locators plus standard filtering, renumbering the *locators* > on attachment in a new place (keeping the old locator prefix alive while > the new locators are propagated). > - as above but also using unique local *locators* to make the locator > renumbering smoother. This introduces the need to be able to discover > those local locators in addition to discovering the global locators. >I hope the above list shows that defining some unique local address space >is not the only approach to making "active sites" work better. > > >Is anybody interested in producing a document about "Issues and goals >for active sites" without assuming that the solution is some new address >space? > Yes - me. Defining issues and goals for active sites w/o assuming a solution alternative is exactly what we are striving to accomplish in the 'hain-templin' document. If you are not seeing this, please send specific text change suggestions. Fred ftemplin@iprg.nokia.com >FWIW I find it odd that while the multi6 problem statement is related to >the overloading of location and identity in the IP address space (which >made sense 25 years ago) and folks are trying to figure out how >to add a layer of indirection to solve that problem, the local >address discussion is about overloading addresses with yet more functionality >and semantics. > > Erik > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 19:16:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00220 for ; Mon, 27 Oct 2003 19:16:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEHXI-0004Wt-W5 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 19:16:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S0GaUN017405 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 19:16:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEHXI-0004We-Ql for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 19:16:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00185 for ; Mon, 27 Oct 2003 19:16:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEHXH-0002al-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 19:16:35 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEHXG-0002ai-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 19:16:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEHWm-0004PG-2T; Mon, 27 Oct 2003 19:16:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEHWY-0004Nx-Lu for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 19:15:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00141 for ; Mon, 27 Oct 2003 19:15:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEHWX-0002Zz-00 for ipv6@ietf.org; Mon, 27 Oct 2003 19:15:49 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AEHWV-0002Zi-00 for ipv6@ietf.org; Mon, 27 Oct 2003 19:15:48 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9S0Eod08525; Mon, 27 Oct 2003 16:14:50 -0800 X-mProtect: <200310280014> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxLDNaO; Mon, 27 Oct 2003 16:14:49 PST Message-ID: <3F9DB631.20202@iprg.nokia.com> Date: Mon, 27 Oct 2003 16:20:01 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Jun-ichiro itojun Hagino , iljitsch@muada.com, ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: MTU handling References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola wrote: >On Fri, 24 Oct 2003, Fred Templin wrote: > > >> 1) Peer-to-peer wireless (e.g. IEEE 802.11): >> On certain wireless media, receiver A can sense QoS metrics (e.g. SNR) >> for the packets it receives from senders B and C. If the SNR for B >>is strong, >> A may wish to inform B that a larger MTU (e.g. 1500 bytes) is >>acceptable. >> Conversely, if the SNR for C is weak, A may wish to inform C that a >>smaller >> MTU (e.g. 1300 bytes) is desired. >> >> > >This kind of dynamic MTU negotiation (requires at least one round-trip!) >seems rather complex to me. Even more so that the original proposal >seemed to be ("node A advertises that a larger MTU is OK"). > No; the proposal is that node A initially advertises to B and C the largest packet size it would like to receive from each of them. A then sits back and passively accepts packets from B and C until it senses some change in conditions (e.g., B's SNR degrades or C's SNR improves). A can then send an *unsolicited* message to B and/or C to inform that a new maximum packet size is desired. (A should of course give some consideration to rate limiting the unsolicited messages it sends.) >> 2) Constrained nodes on large links: >> On large-MTU media (e.g., HiPPI, Gig-E, etc.), nodes with small >>receive buffers >> (e.g. boot ROMs, embedded devices) may wish to receive smaller >>packets than >> the MTU for the link. For example, a constrained node on a link with >>MTU of >> 64KB may wish to inform a neighbor that an MTU of 10KB is desired. >> >> > >Are you sure such deployments are feasible to begin with? Such low-end >equipment is very unlikely equipped with e.g. Gig-E interfaces. (Note: >Gig-E MTU maximum is about 9K already, so it's a bit more reasonable >than 64K.) > Well, every node on a link should at least be able to receive a packet as large as the MTU of the link. But, some nodes might prefer to receive smaller packets and so should have some means of telling neighbors that smaller packets are desired. >(from Fred's another message on the list:) > > >>We must face facts that there are multiple access, shared-media links >>out there and will continue to be for the forseeable future. We can wish >>for a densely-connected mesh of point-to-point links (e.g., ATM PVCs) >>but we needs-be have to support the L2 infrastructure that is already >>deployed. (Otherwise, we would have to go through an L2 transition >>before we even begin to tackle the IPv6 transition.) >> >> > >Sure. There are tradeoffs in every kind of media. A typical assumption >for most kinds of multi-access shared-media links is that they have >similar properties regarding MTU. This is also the case for larger MTU's. >This problem is nowhere near non-trivial. Consider e.g. an IPv6 link >which is separated by two Ethernet switches, one which supports >jumboframes (MTU=9K) and one which does not. How would the hosts be able >to, with simple and robust mechanisms, to determine the MTUs to be used on >such environment? > You are entering the realm of bridging L2 media with diverse MTUs; IPv6/IPv4 path MTU discovery doesn't work in this case unless the bridges are "transluscent" and send ICMP "packet too big" messages as they drop the too-big packets. (Note that a "transparent" bridge would not look into the L3 header and simply drop the too-big packet w/o sending any error message at all.) Can we augment path MTU discovery to work with transparent bridges that connect media with diverse MTUs? Seems like we need to - whether the links are multi-access shared media or point-to-point. >The dynamic, wireless multiple-access media seems to have even more >challenging problems of having to probe and adjust MTU's all the time. >Think about an application using UDP (ie., has to do optimize for the MTU >value itself) that runs longer than the lifetime of this probing. You >expect these to adjust all the time as well? > As I said above, consideration to rate limiting the unsolicited MTU change messages needs to be given in order to dampen the frequency. >This approach seems to be adding complexity of L2 to IP layer where it >doesn't belong. If we need to tackle this issue at L3, why not just >simply use MTU 1280 or MTU 1500 and fragment the packet when needed? > We will miss out on the opportunity to take advantage of larger MTUs if we set a static MTU and just let IP fragment the packets. Also, if we have transparent bridges in the path we won't have the required IP fragmentation support at all forwarding nodes and we'll get black holes. Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Oct 27 21:22:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04285 for ; Mon, 27 Oct 2003 21:22:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEJV8-0004g3-EI for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 21:22:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S2MUFa017973 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 21:22:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEJV8-0004fo-AX for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 21:22:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04248 for ; Mon, 27 Oct 2003 21:22:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEJV5-0004Eb-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 21:22:27 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEJV5-0004EY-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 21:22:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEJUe-0004Xa-Re; Mon, 27 Oct 2003 21:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEJUW-0004WK-0a for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 21:21:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04226 for ; Mon, 27 Oct 2003 21:21:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEJUT-0004Ds-00 for ipv6@ietf.org; Mon, 27 Oct 2003 21:21:49 -0500 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1AEJUS-0004DT-00 for ipv6@ietf.org; Mon, 27 Oct 2003 21:21:48 -0500 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 27 Oct 2003 18:21:18 -0800 Received: from 157.54.8.109 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 27 Oct 2003 18:21:18 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 27 Oct 2003 18:21:18 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 27 Oct 2003 18:21:28 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 27 Oct 2003 18:21:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: NDproxy issues and draft update Date: Mon, 27 Oct 2003 18:21:14 -0800 Message-ID: Thread-Topic: NDproxy issues and draft update thread-index: AcOc+irysoJ8fX/vS5iVD/Fyv/5WnA== From: "Dave Thaler" To: Cc: X-OriginalArrivalTime: 28 Oct 2003 02:21:17.0638 (UTC) FILETIME=[2B292660:01C39CFA] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable http://www.icir.org/dthaler/NDProxyIssues.htm contains=20 the technical issues raised with=20 draft-thaler-ipv6-ndproxy-00.txt Chirayu Patel also made a number of editorial suggestions and has been brought on board as a co-author. As a result the editorial issues are not mentioned at the above page but have been incorporated into draft -01. draft-thaler-ipv6-ndproxy-01.txt was submitted last weekend and is also available at the above URL. Most of the issues raised previously are addressed in this version. -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 00:43:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12895 for ; Tue, 28 Oct 2003 00:43:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEMd4-0003iX-Jo for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 00:42:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S5gsZo014283 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 00:42:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEMd4-0003iI-F3 for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 00:42:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12845 for ; Tue, 28 Oct 2003 00:42:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEMd1-0007aj-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 00:42:51 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEMd1-0007ag-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 00:42:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEMcC-0003ai-SH; Tue, 28 Oct 2003 00:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEMbz-0003Yo-Kv for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 00:41:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12767 for ; Tue, 28 Oct 2003 00:41:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEMbw-0007YL-00 for ipv6@ietf.org; Tue, 28 Oct 2003 00:41:45 -0500 Received: from evrtwa1-ar8-4-62-057-007.evrtwa1.dsl-verizon.net ([4.62.57.7] helo=tndh.net) by ietf-mx with esmtp (Exim 4.12) id 1AEMbw-0007YI-00 for ipv6@ietf.org; Tue, 28 Oct 2003 00:41:44 -0500 Received: from eaglet (127.0.0.1:3212) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Mon, 27 Oct 2003 21:41:44 -0800 From: "Tony Hain" To: "Erik Nordmark" , "Pekka Savola" Cc: Subject: RE: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Date: Mon, 27 Oct 2003 21:41:42 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I now have time to catch up transiting back & forth to jury duty for the next few weeks. On Monday, September 22, Erik Nordmark wrote: > Pekka, > > I think there is an overarching issue about deployment/transition > that relates to the NAT thing; > providing a new service/feature/capability by only adding one box to > the network is a lot easier sell than for instance > - requring a box in the peer's network > - requring all the routers in the path to do something new > - requring the ISP to do something new > > Thus even though NATs cause lots of problems, many would be swayed by > the low entry cost of just adding a box to get some particular > new capability. > And NATs are used as a technology as part of providing different > user visible capabilities such as > - "connection sharing" from home > - load balancers (without needing any support in the servers > behind the LB) > - multihoming boxes (some combining NAT and a DNS server for inbound and > outbound multihoming support without ISP involvement or host awareness) > > It isn't clear to me at what point the pain caused by NAT in > different cases > will be high enough to motivate a transition to some different > technology, or > whether there must be new capabilities (such as the ability to have > multiple servers at the same port number in a home) that are perceived > important enough to cause migration away from NAT solutions. While your earlier comments start addressing it, this last comment clearly misses the point, and is consistent with Geoff's issue that technologists dont' grok market economics. The market doesn't pick technology for technologies sake, it picks tools that solve an acute problem. This means that nat will be with us until it becomes part of the problem that needs solving. Consumer friendly p2p is the obvious catalyst, so the answer to your 'at what point' question becomes, when there are applications that consumers want to deploy. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 03:57:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10016 for ; Tue, 28 Oct 2003 03:57:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPed-0007ou-SN for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 03:56:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S8uhR0030058 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 03:56:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPed-0007na-CS for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 03:56:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09951 for ; Tue, 28 Oct 2003 03:56:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEPea-0005ch-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 03:56:40 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEPeZ-0005ce-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 03:56:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPe0-0007dG-2W; Tue, 28 Oct 2003 03:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPdO-0007ab-VQ for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 03:55:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09890 for ; Tue, 28 Oct 2003 03:55:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEPdM-0005ar-00 for ipv6@ietf.org; Tue, 28 Oct 2003 03:55:24 -0500 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1AEPdL-0005ao-00 for ipv6@ietf.org; Tue, 28 Oct 2003 03:55:23 -0500 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9S8tGed093094; Tue, 28 Oct 2003 09:55:16 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <3F9DA665.6000403@iprg.nokia.com> References: <3F99C926.3090200@iprg.nokia.com> <99D382A8-0735-11D8-BE4E-00039388672E@muada.com> <3F9DA665.6000403@iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7645C2B0-0924-11D8-AD90-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org From: Iljitsch van Beijnum Subject: Re: "RFC 2461bis" issue: MTU handling Date: Tue, 28 Oct 2003 09:55:21 +0100 To: Fred Templin X-Mailer: Apple Mail (2.604) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 28 okt 2003, at 0:12, Fred Templin wrote: > > If I hook up two boxes that can do 9000 bytes over ethernet, but the > > switch is 1500 bytes only, I had better make sure those two boxes > > stick to 1500. > Yes, I know. By "negotiate a larger MTU" I mean not only an > initial indication of how much the *neighbor* can handle but > also ongoing and continuous attention to how much the *L2 > media* can handle. But unfortunately this isn't something that can easily be determined. Is it ok to just send large probe packets, or can sending packets that are too large be harmful? > > The good thing is that if we allow hosts to discover the maximum > > usable MTU between them, we can now use the regular RA MTU option to > > broadcast a much smaller MTU for this type of traffic. > But, if there are many routers on the link, what do you do if > they aren't all broadcasting a consistent smaller MTU? Beat the administrator. > RFC 2461 says to accept the most recently heard MTU - is that > good enough? I'd say: trust the router you've chosen as your default gateway. I considered picking the lowest from those advertised, but this would make it trivial to do "MTU reduction attacks". > > Then there would be a new RA option that would function as the > > "maximum MTU": hosts are not allowed to transmit packets larger than > > this. This value must be equal to or higher than the IP over RFC > value > > if it's present. There could be a bit in this option that indicates > > "if lower layers tell you it's ok to use this value" or "forget what > > lower layers tell you, this value is the correct one". > I'm afraid I'm not bought into this one as being necessary (yet). We > know > from our physical/logical point of attachment what the largest possible > MTU for the attached L2 media is - this is a given. Yes, but who is "we"? The administrator knows this after perusing the documentation and obviously the box itself knows at some level. We currently don't have any mechanisms to transfer this knowledge to the layer 3 on hosts that are considering using jumboframes. The IEEE was understandably reluctant to increase the gigabit ethernet MTU beyond 1500 bytes because this would break interoperation with existing 10 and 100 Mbps ethernet. But at some point something has to give, because two hosts that want to utilize 10 gigabit ethernet between them would have to transmit/receive almost a million packets per second with a 1500 byte MTU. > So, to supply a maximum > MTU that is larger than the attached L2 media can support in a single > packet > is saying that we expect the sender to do L2 fragmentation locally. Obviously announcing an MTU that's larger than what layer 2 can support doesn't make sense. But often layer 2 can support a larger MTU than what is specified for that particular layer 2 protocol and/or for IP over that protocol. This "unofficial" MTU is the one we're interested in. (At least when increasing the MTU.) > Is this what you are saying, and is this really desireable? (Maybe; > I'm willing to be convinced.) If layer 2 fragmentation is done there should also be layer 2 reassembly. Then the whole procedure becomes transparent to IP so we don't have a problem. This is what 802.11 does to achieve interference robustness. AAL5 in ATM is basically the same thing. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 04:48:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12270 for ; Tue, 28 Oct 2003 04:48:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEQSZ-0004tQ-2t for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 04:48:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S9mJGL018807 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 04:48:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEQSY-0004tG-Kn for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 04:48:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12222 for ; Tue, 28 Oct 2003 04:48:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEQSV-0006V2-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 04:48:15 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEQSU-0006Uz-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 04:48:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEQSH-0004ja-FF; Tue, 28 Oct 2003 04:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEQS0-0004iG-Oq for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 04:47:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12212 for ; Tue, 28 Oct 2003 04:47:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEQRx-0006Uh-00 for ipv6@ietf.org; Tue, 28 Oct 2003 04:47:41 -0500 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1AEQRw-0006UR-00 for ipv6@ietf.org; Tue, 28 Oct 2003 04:47:41 -0500 Content-class: urn:content-classes:message Subject: RE: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] MIME-Version: 1.0 Date: Tue, 28 Oct 2003 01:47:11 -0800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Thread-Index: AcOdFjspB2uIo8quQRWsJNOjCyNf+QAH9M7g From: "Michel Py" To: "Tony Hain" Cc: Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Tony Hain wrote: > The market doesn't pick technology for technologies sake, it > picks tools that solve an acute problem. Indeed. > This means that nat will be with us until it becomes part of > the problem that needs solving. Consumer friendly p2p is the > obvious catalyst, so the answer to your 'at what point' > question becomes, when there are applications that consumers > want to deploy. Note that p2p is not that unfriendly as of now. I just had a look at one of the pieces of p2p I use at home; there are some 230k users on the server I connect to, plus a load of other ones with 100k+ users. Some of the files have 500+ simultaneous sources. These guys are not all network geeks, and a fair number have broadband and are behind NATs or behind some kind of a firewall (I ran a few probes). It means that the point where Joe-six-pack that bought a $50 NAT box is able to type "http://192.168.1.1", figure out that the password is "admin" and use the web interface to open the one port that the p2p app needs open has been reached. Out of the million something users I see right now on _one_ p2p app, I'd be damned if there are not 100k Joes and Janes that don't understand squat about networks but that spent the time to read what they had to do in order to get free pr0n, warez or free mp3s. If it has reached that kind of mass acceptance, it must be easy enough. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 04:51:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12411 for ; Tue, 28 Oct 2003 04:51:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEQVM-0005Rb-1b for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 04:51:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S9pCI8020928 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 04:51:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEQVL-0005RG-7p for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 04:51:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12355 for ; Tue, 28 Oct 2003 04:50:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEQVH-0006Xm-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 04:51:07 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEQVH-0006Xj-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 04:51:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEQVD-0005Df-PC; Tue, 28 Oct 2003 04:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEQUb-0005Aa-Nn for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 04:50:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12322 for ; Tue, 28 Oct 2003 04:50:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEQUY-0006Ww-00 for ipv6@ietf.org; Tue, 28 Oct 2003 04:50:22 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AEQUX-0006Wq-00 for ipv6@ietf.org; Tue, 28 Oct 2003 04:50:21 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9S9oKPh011072; Tue, 28 Oct 2003 02:50:21 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9S9oKS13400; Tue, 28 Oct 2003 10:50:20 +0100 (MET) Date: Tue, 28 Oct 2003 10:50:04 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-hain-templin-ipv6-localcomm-03.txt To: Fred Templin Cc: Erik Nordmark , ipv6@ietf.org In-Reply-To: "Your message with ID" <3F9DAF48.9060902@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > If you are still seeing the document as advocating a particular solution > alternative, please send specific text change suggestions as that is not > the document's intention. Fred, The question in my mind is not what one would change in the document but instead what parts one could retain. The problem is that the document was originally written as an argument for why local addressing in general, and site-local addressing in particular, was required. Doing incremental edits to change the document to have a completely different perspective isn't likely to be efficient. Better to start over with a blank slate and import the part of the existing document that make sense with that new perspective. (Just to make it clear, I think the document includes many perceived important aspects desirable properties for active sites, but the history of the documents colors things in ways that makes the document confusing and not very succinct.) Another high-order bit which I perhaps didn't make sufficiently explicit in my note is that the document is completely silent on the desirable properties of global communication for these active sites. I think we can assume that the importance of global communication is greater than zero; those sites which don't need any global communication aren't part of the Internet even though they use IP technology (and IPv4 is fine for them as long as long as they have only a few hundered million nodes or so :-) Thus I think it makes sense to describe the desirable properties for global communication as well even though different individual sites will place different relative importance on local and global communication; in some cases local will be much more important and in other cases global might be the more important one. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 05:38:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15008 for ; Tue, 28 Oct 2003 05:38:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AERF0-0001Bi-T9 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 05:38:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SAcM4g004563 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 05:38:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AERF0-0001BW-8i for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 05:38:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14981 for ; Tue, 28 Oct 2003 05:38:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEREw-0007eT-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 05:38:18 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEREw-0007eQ-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 05:38:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEREf-00013W-Rw; Tue, 28 Oct 2003 05:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AERDy-0000r2-UA for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 05:37:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14918 for ; Tue, 28 Oct 2003 05:37:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AERDv-0007cX-00 for ipv6@ietf.org; Tue, 28 Oct 2003 05:37:15 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AERDu-0007cQ-00 for ipv6@ietf.org; Tue, 28 Oct 2003 05:37:14 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9SAbEPh027744; Tue, 28 Oct 2003 03:37:14 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9SAbDS21264; Tue, 28 Oct 2003 11:37:13 +0100 (MET) Date: Tue, 28 Oct 2003 11:36:58 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: "RFC 2461bis" issue: MTU handling To: Iljitsch van Beijnum Cc: Pekka Savola , "" In-Reply-To: "Your message with ID" <05693FDE-08D5-11D8-AD90-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > No, the existing option is only usable for lowering the MTU used within > a subnet to a value lower than what the "IP over ..." RFC prescribes. > We also need a way to convey the maximum packet size that layer 2 > equipment can handle. I think this should be an option that is similar > to, but different from the existing MTU option. Just to restate what you are saying differently so that others might understand it. Today with have a MTU specified in the IPv6 over foo documents. We have an MTU option in router advertisements that can be used to lower that number - which is useful(?) for the last century problem of bridging Ethernet and FDDI together with half-broken fragmenting bridges - can get the FDDI attached nodes to use 1500. What Iljitsch is sayin is that if the L2 might support a larger MTU e.g. by ensuring that all the switches support Ethernet jumboframes one could add an option (which he calls "MAX MTU" - "maximum L2 packet size" might be a more differentiated term). But if the routers advertised this option, it still wouldn't mean that a given host was capable of receiving L2 packets of that size. Hence the need for each host to advertise their MRU in NS/NA type packets. I think this works as long as the network admin can ensure that all the switches in an L2 in fact support the larger size. Whether it is important to solve this using additional protocol mechanisms, or whether it is sufficient to have folks hand-craft VLANs containing the hosts that support the larger size, is hard to tell. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 06:27:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16518 for ; Tue, 28 Oct 2003 06:27:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AES0O-00061h-Lo for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 06:27:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SBRKMK023159 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 06:27:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AES0O-00061S-7B for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 06:27:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16469 for ; Tue, 28 Oct 2003 06:27:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AES0K-00013n-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 06:27:16 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AES0J-00013i-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 06:27:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AES06-0005rb-7B; Tue, 28 Oct 2003 06:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AERza-0005oO-Fu for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 06:26:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16462 for ; Tue, 28 Oct 2003 06:26:17 -0500 (EST) From: matthew.ford@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AERzW-00012T-00 for ipv6@ietf.org; Tue, 28 Oct 2003 06:26:26 -0500 Received: from [217.32.164.137] (helo=i2kc01-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1AERzV-00011d-00 for ipv6@ietf.org; Tue, 28 Oct 2003 06:26:25 -0500 Received: from i2km96-ukbr.domain1.systemhost.net ([193.113.197.84]) by i2kc01-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Oct 2003 11:25:57 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km96-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Oct 2003 11:25:56 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: "RFC 2461bis" issue: DNS configuration Date: Tue, 28 Oct 2003 11:25:56 -0000 Message-ID: <0AAF93247C75E3408638B965DEE11A70035EA6E4@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: "RFC 2461bis" issue: DNS configuration Thread-Index: AcOZSepeSpPe4f9QSeeKjh7BVvPC9gD/B87Q To: Cc: X-OriginalArrivalTime: 28 Oct 2003 11:25:56.0669 (UTC) FILETIME=[41618ED0:01C39D46] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ronald,=20 > This keeps popping up and we don't seem to be converging. Just before > reading this thread I contacted some people about trying DHCPv6 on the > MSP IETF network. I have no strong preference (yet) for either DHCPv6 > or RA. Let's just give DHCPv6 a try. >=20 > What do you think of this idea? It worked fine when we ran it at IETF51 in London. Mat -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 07:31:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18213 for ; Tue, 28 Oct 2003 07:31:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AET0X-0003fy-SR for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 07:31:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SCVX1X014124 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 07:31:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AET0X-0003fj-MA for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 07:31:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18184 for ; Tue, 28 Oct 2003 07:31:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AET0X-00021P-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 07:31:33 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AET0W-00021L-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 07:31:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AET03-0003Xz-Mi; Tue, 28 Oct 2003 07:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AESzh-0003Vd-MO for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 07:30:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18148 for ; Tue, 28 Oct 2003 07:30:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AESzh-00020o-00 for ipv6@ietf.org; Tue, 28 Oct 2003 07:30:41 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AESzg-000202-00 for ipv6@ietf.org; Tue, 28 Oct 2003 07:30:40 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9SCU6432719; Tue, 28 Oct 2003 14:30:06 +0200 Date: Tue, 28 Oct 2003 14:30:05 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: ipv6@ietf.org Subject: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi, (Cc:'ed to ipv6@ietf.org as well, because this seems to have significant impact with the IPv6 APIs as well..) When revising my "transarch" document, I noticed another issue v6 on-by-default might cause. If v6 is enabled by default, all the implementations I know generate the link-local addresses for all the interfaces automatically, unless explicitly configured otherwise (some don't have this knob). This seems to cause an unintended consequence with getaddrinfo and its AI_ADDRCONFIG hint (as specified in the basic socket API RFC). That is, AI_ADDRCONFIG hint causes AAAA DNS queries to be made only if an IPv6 address is configured on the node (similar with v4). Loopback addresses are excluded from this. However, these typically autoconfigured link-local addresses are *not* excluded. In consequence, AI_ADDRCONFIG seems to be of less utility than at least I had hoped. The only reason I could think of for AI_ADDRCONFIG *not* excluding the link-locals as well could be that if a node is expected to be able to communicate using regular, getaddrinfo() -using apps, using the link-local addresses (this would eliminate this possibility). IMHO, using link-local addresses for anything except well-specified purposes (e.g. routing protocols, RFC2461/2, etc.) is really, really counter-productive -- as you'll have to make those apps be able to distinguish the zone identifiers as well, and that's probably something we DON'T want to do. But your mileage may vary. So, I'll conclude by a few questions to give food for thought: - does this seem like a problem, that is, should getaddrinfo() + AI_ADDRCONFIG perform AAAA DNS queries etc. if the node only has v6 link-local/loopback addresses? - is getaddrinfo() + link-local addresses something we should support? - should this be fixed by e.g.: a) recommending that the implementations filter out link-locals as well when doing AI_ADDRCONFIG (a BCP/Info document) b) specifying additional semantics for AI_ADDRCONFIG c) specifying a new hint which would perform this Note: if we go select any of these (especially the latter two), it might make sense to bring this discussion up in the relevant API forums like POSIX as well, because the IETF API documents are just Informational RFCs. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 08:47:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20042 for ; Tue, 28 Oct 2003 08:47:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUC2-00052V-Qq for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 08:47:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SDlUq0019365 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 08:47:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUC2-00052G-MO for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 08:47:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20016 for ; Tue, 28 Oct 2003 08:47:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEUC1-0002vO-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 08:47:29 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEUC1-0002vL-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 08:47:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUBa-0004rt-62; Tue, 28 Oct 2003 08:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUAj-0004mM-Bt for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 08:46:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19973 for ; Tue, 28 Oct 2003 08:45:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEUAi-0002uJ-00 for ipv6@ietf.org; Tue, 28 Oct 2003 08:46:08 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AEUAh-0002tr-00 for ipv6@ietf.org; Tue, 28 Oct 2003 08:46:07 -0500 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h9SDjb4S018146; Tue, 28 Oct 2003 07:45:37 -0600 (CST) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Oct 2003 07:44:38 -0600 Received: from [142.133.72.18] (142.133.72.18 [142.133.72.18]) by eammlex033.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id VNTRXAFH; Tue, 28 Oct 2003 08:48:39 -0500 Date: Tue, 28 Oct 2003 08:43:49 -0500 (EST) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: Suresh Krishnan To: Alain Durand cc: ipv6@ietf.org Subject: Re: RFC 2460 issue In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF830BD628BC@eammlex037.lmc.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi Alain, Since the hop limit is analogous to TTL in IPv4 the answer should be no. But you will not find the answer in RFC 2460 as this was not covered in RFC 791. This should be covered in the node requirements draft (draft-ietf-ipv6-node-requirements-06.txt) that John is editing. I checked the draft but it did not have a section regarding this(analogous to RFC 1122 section 3.2.1.7). Maybe this can be added to that draft. I am curious as to why you would want to do that though. Regards Suresh On Fri, 24 Oct 2003, Alain Durand wrote: >I had this question yesterday and I couldn't find an answer in RFC2460: > >Is it valid for a host to send a packet with Hop Count set to zero? > > - Alain. > > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 09:01:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20509 for ; Tue, 28 Oct 2003 09:01:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUPP-0007D9-MJ for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 09:01:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SE1JZD027716 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 09:01:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUPO-00079i-Ep for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 09:01:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20476 for ; Tue, 28 Oct 2003 09:01:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEUPN-000368-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 09:01:17 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEUPM-000365-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 09:01:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUP8-0006z9-CI; Tue, 28 Oct 2003 09:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUOF-0006u5-Gd for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 09:00:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20423 for ; Tue, 28 Oct 2003 08:59:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEUOE-00035U-00 for ipv6@ietf.org; Tue, 28 Oct 2003 09:00:06 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AEUOD-00035O-00 for ipv6@ietf.org; Tue, 28 Oct 2003 09:00:05 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id F41C66A909; Tue, 28 Oct 2003 15:59:57 +0200 (EET) Message-ID: <3F9E7564.6010104@kolumbus.fi> Date: Tue, 28 Oct 2003 15:55:48 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Suresh Krishnan Cc: Alain Durand , ipv6@ietf.org Subject: Re: RFC 2460 issue References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Suresh Krishnan wrote: > Hi Alain, > Since the hop limit is analogous to TTL in IPv4 the answer should > be no. But you will not find the answer in RFC 2460 as this was not > covered in RFC 791. This should be covered in the node requirements draft > (draft-ietf-ipv6-node-requirements-06.txt) that John is editing. I > checked the draft but it did not have a section regarding this(analogous > to RFC 1122 section 3.2.1.7). Maybe this can be added to that draft. I am > curious as to why you would want to do that though. I think we have agreed now that the node requirements document is not a place to list all updates and deficiencies of existing RFCs -- those existing RFCs should be updated instead. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 09:09:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20952 for ; Tue, 28 Oct 2003 09:09:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUX1-0008Pf-KA for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 09:09:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SE9B3L032333 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 09:09:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUX1-0008PQ-EP for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 09:09:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20898 for ; Tue, 28 Oct 2003 09:09:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEUWz-0003Cz-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 09:09:10 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEUWz-0003Cw-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 09:09:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUWr-0008IV-2l; Tue, 28 Oct 2003 09:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUWT-0008HF-8D for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 09:08:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20888 for ; Tue, 28 Oct 2003 09:08:25 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEUWR-0003Cf-00 for ipv6@ietf.org; Tue, 28 Oct 2003 09:08:35 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AEUWQ-0003CO-00 for ipv6@ietf.org; Tue, 28 Oct 2003 09:08:35 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9SE8XI21150 for ; Tue, 28 Oct 2003 16:08:33 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 28 Oct 2003 16:08:32 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 28 Oct 2003 16:08:32 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 28 Oct 2003 16:08:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC 2460 issue Date: Tue, 28 Oct 2003 16:08:31 +0200 Message-ID: Thread-Topic: RFC 2460 issue Thread-Index: AcOdXAdxjzGwVOK0QoGh2MKhBIWwowAAOAHg To: , Cc: , X-OriginalArrivalTime: 28 Oct 2003 14:08:32.0213 (UTC) FILETIME=[F8237050:01C39D5C] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jari, > Suresh Krishnan wrote: > > Hi Alain, > > Since the hop limit is analogous to TTL in IPv4 the answer should=20 > > be no. But you will not find the answer in RFC 2460 as this was not=20 > > covered in RFC 791. This should be covered in the node requirements = draft=20 > > (draft-ietf-ipv6-node-requirements-06.txt) that John is editing. I=20 > > checked the draft but it did not have a section regarding = this(analogous=20 > > to RFC 1122 section 3.2.1.7). Maybe this can be added to that draft. = I am=20 > > curious as to why you would want to do that though. >=20 > I think we have agreed now that the node requirements document is > not a place to list all updates and deficiencies of existing RFCs -- > those existing RFCs should be updated instead. I agree. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 09:16:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21597 for ; Tue, 28 Oct 2003 09:16:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUdo-0001Dl-R1 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 09:16:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SEGC3D004687 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 09:16:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUdo-0001DW-Mo for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 09:16:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21562 for ; Tue, 28 Oct 2003 09:16:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEUdn-0003MQ-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 09:16:11 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEUdm-0003MN-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 09:16:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUde-00014F-PR; Tue, 28 Oct 2003 09:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUcp-000103-Mu for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 09:15:11 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21427; Tue, 28 Oct 2003 09:14:59 -0500 (EST) Message-Id: <200310281414.JAA21427@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-node-requirements-06.txt Date: Tue, 28 Oct 2003 09:14:59 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Node Requirements Author(s) : J. Loughney Filename : draft-ietf-ipv6-node-requirements-06.txt Pages : 20 Date : 2003-10-27 This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-node-requirements-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-node-requirements-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28093416.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-node-requirements-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-node-requirements-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28093416.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 09:52:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25966 for ; Tue, 28 Oct 2003 09:52:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVCH-0007JT-Ac for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 09:51:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SEpnHB028105 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 09:51:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVCH-0007JE-5W for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 09:51:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25856 for ; Tue, 28 Oct 2003 09:51:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEVCF-0004bg-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 09:51:47 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEVCE-0004bY-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 09:51:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVAZ-0006nL-GJ; Tue, 28 Oct 2003 09:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVAL-0006lg-2G for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 09:49:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25565 for ; Tue, 28 Oct 2003 09:49:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEVAJ-0004V6-00 for ipv6@ietf.org; Tue, 28 Oct 2003 09:49:47 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1AEVAI-0004UN-00 for ipv6@ietf.org; Tue, 28 Oct 2003 09:49:46 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 1AEEF7B07F; Tue, 28 Oct 2003 15:49:15 +0100 (CET) Received: from james (unknown [212.201.47.4]) by merkur.iu-bremen.de (Postfix) with ESMTP id D42B27B07A; Tue, 28 Oct 2003 15:49:12 +0100 (CET) Received: by james (Postfix, from userid 1000) id BC2457E6D; Tue, 28 Oct 2003 15:49:12 +0100 (CET) Date: Tue, 28 Oct 2003 15:49:12 +0100 From: Juergen Schoenwaelder To: ipv6@ietf.org Subject: comments on draft-ietf-ipv6-scoping-arch-00.txt Message-ID: <20031028144912.GA2088@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: ipv6@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , I have reviewed and have the following two comments: a) I think it would be helpful if the document would refer to in places where it explains why it does not cover site-local unicast addresses. b) I have a more serious issue with the default zone. The text says in several places that the zone index zero might be used to indicate the default zone but it explicitely allows to use other values. In section six, it says: Similarly, an implementation may choose an index value other than zero to represent the default zone. I am not sure why this is helpful. Is there a particular reason why we can not just say that the default zone is indicated by a zone index which MUST (or SHOULD if we have to compromise) be zero? Note that I am editing some textual conventions for MIBs where the language in place right now is much clearer that zero means default zone. This means that an implementation which chooses a different value to denote the default would have to translate this value for the MIB interface, which really seems awkward. Hence, I would prefer if the scoping architecture document could be more precise here. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 10:32:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00226 for ; Tue, 28 Oct 2003 10:32:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVpZ-0003YS-LR for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 10:32:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SFWPq7013658 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 10:32:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVpZ-0003YD-AK for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 10:32:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00111 for ; Tue, 28 Oct 2003 10:32:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEVpX-0005sG-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 10:32:23 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEVpW-0005sC-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 10:32:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVpC-0003OG-4O; Tue, 28 Oct 2003 10:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVoj-0003M2-N3 for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 10:31:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00013 for ; Tue, 28 Oct 2003 10:31:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEVoh-0005pt-00 for ipv6@ietf.org; Tue, 28 Oct 2003 10:31:31 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AEVog-0005ph-00 for ipv6@ietf.org; Tue, 28 Oct 2003 10:31:30 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id ABDAF6A90B; Tue, 28 Oct 2003 17:31:26 +0200 (EET) Message-ID: <3F9E8AD5.3010703@kolumbus.fi> Date: Tue, 28 Oct 2003 17:27:17 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: MTU handling References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > This still has the operational issue of what happens when > I need extra ports in my office and I get a cheap 4-port hub; neither > the IT department nor my hosts knows that this box is present and it > might not support jumboframes. I'd favor robustness a lot more than optimization for the highest available MTU size. Whatever we do, lets make sure the protocol can deal with the above case. > One way to cope with this particular topology, > but no other topologies of varying frame size switches, would be > for the host to exchange a 9k packet with the router before > deciding that it should declare itself 9k capable. Yes. But somehow I'm worried about this, particularly when the MTU size field in ND is 32 bits. Is there any danger that a false claim of a large MTU size will lead to something bad happening? Or are we relying on the sender's hardware to not accept overly large packets for transmission? Also, if the IP header is 40 bytes/packet, one exchange of two 9k packets consumes as much bandwidth as the overhead from 225 packets -- a 337 K transmission at 1500 byte MTU. So perhaps you wouldn't like to do this every time. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 12:45:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11858 for ; Tue, 28 Oct 2003 12:45:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEXtZ-0001E2-Ue for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 12:44:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SHif9v004704 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 12:44:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEXtZ-0001Dn-Nr for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 12:44:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11798 for ; Tue, 28 Oct 2003 12:44:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEXtY-0002X3-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 12:44:40 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEXtX-0002X0-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 12:44:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEXsv-00016b-CA; Tue, 28 Oct 2003 12:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEXs5-00013Q-KC for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 12:43:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11677 for ; Tue, 28 Oct 2003 12:42:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEXs3-0002Sz-00 for ipv6@ietf.org; Tue, 28 Oct 2003 12:43:07 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AEXs2-0002RN-00 for ipv6@ietf.org; Tue, 28 Oct 2003 12:43:06 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9SHgX712045; Tue, 28 Oct 2003 09:42:33 -0800 X-mProtect: <200310281742> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdyRBGCf; Tue, 28 Oct 2003 09:42:32 PST Message-ID: <3F9EABC3.1070400@iprg.nokia.com> Date: Tue, 28 Oct 2003 09:47:47 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: ipv6@ietf.org Subject: Re: draft-hain-templin-ipv6-localcomm-03.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>If you are still seeing the document as advocating a particular solution >>alternative, please send specific text change suggestions as that is not >>the document's intention. >> >> > >Fred, > >The question in my mind is not what one would change in the >document but instead what parts one could retain. >The problem is that the document was originally written as an argument >for why local addressing in general, and site-local addressing >in particular, was required. > The above statement is false. The document in question came about by combining two earlier works of the co-authors. The earlier works are still in the I-D repository - see for yourself: http://www.ietf.org/internet-drafts/draft-hain-ipv6-sitelocal-01.txt http://www.ietf.org/internet-drafts/draft-templin-lsareqts-00.txt >Doing incremental edits to change the document to have a completely different >perspective isn't likely to be efficient. Better to start over with a blank >slate and import the part of the existing document that make sense with that >new perspective. (Just to make it clear, I think the document includes >many perceived important aspects desirable properties for active sites, but >the history of the documents colors things in ways that makes the document >confusing and not very succinct.) > >Another high-order bit which I perhaps didn't make sufficiently explicit in >my note is that the document is completely silent on the desirable >properties of global communication for these active sites. >I think we can assume that the importance of global communication >is greater than zero; those sites which don't need any global communication >aren't part of the Internet even though they use IP technology (and IPv4 >is fine for them as long as long as they have only a few hundered million nodes >or so :-) > Global communications are out of scope for the document in question; a quick read of the document title makes this abundantly clear. Of course, support for global communications is vitally important, but that is a topic for another document. >Thus I think it makes sense to describe the desirable properties for global >communication as well even though different individual sites will place >different relative importance on local and global communication; >in some cases local will be much more important and in other cases >global might be the more important one. > If you want a document on global communications goals for sites, by all means go ahead and write one. We already have a document on local communications goals for sites. Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 13:00:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13231 for ; Tue, 28 Oct 2003 13:00:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEY8f-0003EV-Iq for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 13:00:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SI0G6m012388 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 13:00:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEY8c-0003Ca-2O for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 13:00:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13176 for ; Tue, 28 Oct 2003 13:00:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEY8a-00034W-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 13:00:12 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEY8Z-00034S-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 13:00:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEY8U-00037M-Li; Tue, 28 Oct 2003 13:00:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEY85-00033j-Jj for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 12:59:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13131 for ; Tue, 28 Oct 2003 12:59:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEY83-00033l-00 for ipv6@ietf.org; Tue, 28 Oct 2003 12:59:39 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AEY83-00031W-00 for ipv6@ietf.org; Tue, 28 Oct 2003 12:59:39 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Tue, 28 Oct 2003 09:58:51 -0800 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 28 Oct 2003 09:59:18 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 28 Oct 2003 09:59:18 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 28 Oct 2003 09:59:15 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 28 Oct 2003 09:59:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: "RFC 2461bis" issue: DNS configuration Date: Tue, 28 Oct 2003 09:59:20 -0800 Message-ID: Thread-Topic: "RFC 2461bis" issue: DNS configuration thread-index: AcOZSepeSpPe4f9QSeeKjh7BVvPC9gD/B87QAA2/DJA= From: "Christian Huitema" To: , Cc: X-OriginalArrivalTime: 28 Oct 2003 17:59:14.0452 (UTC) FILETIME=[32C17D40:01C39D7D] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > This keeps popping up and we don't seem to be converging. Just before > > reading this thread I contacted some people about trying DHCPv6 on the > > MSP IETF network. I have no strong preference (yet) for either DHCPv6 > > or RA. Let's just give DHCPv6 a try. > > > > What do you think of this idea? >=20 > It worked fine when we ran it at IETF51 in London. You do mean DHCPv6 for DNS configuration, right? Many platforms do not support address assignment via DHCPv6... -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 13:33:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15212 for ; Tue, 28 Oct 2003 13:33:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEYe3-0006cz-2p for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 13:32:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SIWhXK025471 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 13:32:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEYe2-0006ck-S2 for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 13:32:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15120 for ; Tue, 28 Oct 2003 13:32:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEYe0-0003rr-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 13:32:40 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEYe0-0003ro-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 13:32:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEYcQ-0006P1-BG; Tue, 28 Oct 2003 13:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEYc4-0006Lx-3f for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 13:30:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15006 for ; Tue, 28 Oct 2003 13:30:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEYc1-0003oj-00 for ipv6@ietf.org; Tue, 28 Oct 2003 13:30:37 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AEYc1-0003nV-00 for ipv6@ietf.org; Tue, 28 Oct 2003 13:30:37 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9SITua28039; Tue, 28 Oct 2003 10:29:56 -0800 X-mProtect: <200310281829> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdn7HV8K; Tue, 28 Oct 2003 10:29:54 PST Message-ID: <3F9EB6DE.5010406@iprg.nokia.com> Date: Tue, 28 Oct 2003 10:35:10 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: MTU handling References: <3F99C926.3090200@iprg.nokia.com> <99D382A8-0735-11D8-BE4E-00039388672E@muada.com> <3F9DA665.6000403@iprg.nokia.com> <7645C2B0-0924-11D8-AD90-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > On 28 okt 2003, at 0:12, Fred Templin wrote: > >> > If I hook up two boxes that can do 9000 bytes over ethernet, but the >> > switch is 1500 bytes only, I had better make sure those two boxes >> > stick to 1500. > > >> Yes, I know. By "negotiate a larger MTU" I mean not only an >> initial indication of how much the *neighbor* can handle but >> also ongoing and continuous attention to how much the *L2 >> media* can handle. > > > But unfortunately this isn't something that can easily be determined. > Is it ok to just send large probe packets, or can sending packets that > are too large be harmful? Well, there's no use in sending large probe packets if you aren't going to allow sending large data packets. The purpose of the probes is to determine a window of opportunity during which it should be OK to send large data packets. >> > The good thing is that if we allow hosts to discover the maximum >> > usable MTU between them, we can now use the regular RA MTU option to >> > broadcast a much smaller MTU for this type of traffic. > > >> But, if there are many routers on the link, what do you do if >> they aren't all broadcasting a consistent smaller MTU? > > > Beat the administrator. I wish! >> RFC 2461 says to accept the most recently heard MTU - is that >> good enough? > > > I'd say: trust the router you've chosen as your default gateway. I > considered picking the lowest from those advertised, but this would > make it trivial to do "MTU reduction attacks". > > >> > Then there would be a new RA option that would function as the >> > "maximum MTU": hosts are not allowed to transmit packets larger than >> > this. This value must be equal to or higher than the IP over RFC value >> > if it's present. There could be a bit in this option that indicates >> > "if lower layers tell you it's ok to use this value" or "forget what >> > lower layers tell you, this value is the correct one". > > >> I'm afraid I'm not bought into this one as being necessary (yet). We >> know >> from our physical/logical point of attachment what the largest possible >> MTU for the attached L2 media is - this is a given. > > > Yes, but who is "we"? The administrator knows this after perusing the > documentation and obviously the box itself knows at some level. We > currently don't have any mechanisms to transfer this knowledge to the > layer 3 on hosts that are considering using jumboframes. By "we", I was referring to the interface that is configured over the L2 link. In the case of Ethernet - I hear you and Erik telling me that the interface has no way of knowing whether the physical link is capable of supporting an MTU of 9KB for jumboframes or only 1500bytes - do I have this correct? > The IEEE was understandably reluctant to increase the gigabit ethernet > MTU beyond 1500 bytes because this would break interoperation with > existing 10 and 100 Mbps ethernet. But at some point something has to > give, because two hosts that want to utilize 10 gigabit ethernet > between them would have to transmit/receive almost a million packets > per second with a 1500 byte MTU. So, you are saying that the IEEE was reluctant to increase the Gig-E MTU beyond 1500 bytes. The MTU speaks only to the *send* side - but, what about the MRU (receive side)? Can Ethernet interfaces determine whether they are configured over a Gig-E link and (if so) make sure the MRU is at least 9KB? >> So, to supply a maximum >> MTU that is larger than the attached L2 media can support in a single >> packet >> is saying that we expect the sender to do L2 fragmentation locally. > > > Obviously announcing an MTU that's larger than what layer 2 can > support doesn't make sense. But often layer 2 can support a larger MTU > than what is specified for that particular layer 2 protocol and/or for > IP over that protocol. This "unofficial" MTU is the one we're > interested in. (At least when increasing the MTU.) Well, if an L2 infrastructure has a mix of 10/100 and Gig-E Ethernet elements then I suppose routers on the L2 could advertise Max/Min MTU values such that: 1280 <= Min_MTU <= 1500 <= Max_MTU <= 9KB Then, each neighbor could announce a per-neighbor MTU such that: 1280 <= NBR_MTU <= Max_MTU Do I have this right? >> Is this what you are saying, and is this really desireable? (Maybe; >> I'm willing to be convinced.) > > > If layer 2 fragmentation is done there should also be layer 2 > reassembly. Then the whole procedure becomes transparent to IP so we > don't have a problem. This is what 802.11 does to achieve interference > robustness. AAL5 in ATM is basically the same thing. Yes, if the L2 supports fragmentation then the L3 can send and receive whole packets transparently - but this should only be allowed up to the point that triggering the L2 fragmentation does not impart issues such as excessive fragment loss due to congestion. See sections 3.4 ("Use of Transparent Fragmentation") and 3.5 ("Careful use of Intentional Fragmentation) of "Fragmentation Considered Harmful" for more thorough discussion on this. Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 13:38:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15513 for ; Tue, 28 Oct 2003 13:38:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEYjW-0007ey-E9 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 13:38:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SIcM10029444 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 13:38:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEYjW-0007eo-6U for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 13:38:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15455 for ; Tue, 28 Oct 2003 13:38:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEYjT-00042f-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 13:38:19 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEYjT-00042c-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 13:38:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEYjE-0007Vf-35; Tue, 28 Oct 2003 13:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEYiI-00078H-II for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 13:37:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15428 for ; Tue, 28 Oct 2003 13:36:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEYiE-000414-00 for ipv6@ietf.org; Tue, 28 Oct 2003 13:37:02 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AEYiD-0003zr-00 for ipv6@ietf.org; Tue, 28 Oct 2003 13:37:02 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9SIaF401792; Tue, 28 Oct 2003 10:36:15 -0800 X-mProtect: <200310281836> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4F8BOf; Tue, 28 Oct 2003 10:36:13 PST Message-ID: <3F9EB859.4040301@iprg.nokia.com> Date: Tue, 28 Oct 2003 10:41:29 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: Iljitsch van Beijnum , ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: MTU handling References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>One case in which data packets could be used as probe packets >>is when IPv4 is used as an L2 media for IPv6. In this case, we could >>send IPv6-in-IPv4 encapsulated packets with the DF bit NOT set >>in the IPv4 header expecting that the decapsulator would send us >>some sort of indication if it sensed fragmentation. >> >> > >Yes, you have that option for the L2 which is known as IPv4. > > > >>But this begs the question of a fundamental design point: do we need >>to support sub-L2 media elements (i.e., the physical elements that sit >>below IPv4) that neither support IPv4 fragmentation nor send IPv4 >>"frag needed" messages when they can't forward a packet? Based on >>the 1Gbps/100Mbps Ethernet bridge example, I believe the answer >>to this is "yes" - would you agree? >> >> > >I think the high-order bit question for those L2s is first how important >the problem is to solve, and then what simplying assumptions we can make. >(such as "does the network admin control all the switches i.e. does s/he >know whether all are jumbo frame capable"). > I think you've already given a prime example in an earlier message - suppose I slap a 10/100 bridge onto the network in my cubile w/o telling the network admin about it? As another example, in large corporate networks the L2 infrastructure is often under the control of regional adminstrative domains and sometimes these regional domains don't coordinate with one another as well as they should. So, I think the answer to your second question is that it would be a bit naive to assume that any one network admin controls all the switches. Fred ftempin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 13:50:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16266 for ; Tue, 28 Oct 2003 13:50:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEYv1-0000aH-Gi for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 13:50:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SIoFQU002239 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 13:50:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEYv1-0000a2-Bj for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 13:50:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16225 for ; Tue, 28 Oct 2003 13:50:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEYuz-0004JZ-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 13:50:13 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEYuy-0004JW-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 13:50:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEYup-0000Qj-Mi; Tue, 28 Oct 2003 13:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEYu3-0000Nb-He for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 13:49:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16171 for ; Tue, 28 Oct 2003 13:49:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEYu1-0004IP-00 for ipv6@ietf.org; Tue, 28 Oct 2003 13:49:13 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEYu0-0004I7-00 for ipv6@ietf.org; Tue, 28 Oct 2003 13:49:12 -0500 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA28719 for ; Tue, 28 Oct 2003 18:49:10 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA28564 for ; Tue, 28 Oct 2003 18:49:09 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h9SIn9I16503 for ipv6@ietf.org; Tue, 28 Oct 2003 18:49:09 GMT Date: Tue, 28 Oct 2003 18:49:09 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: DNS configuration Message-ID: <20031028184909.GD12272@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, Oct 28, 2003 at 09:59:20AM -0800, Christian Huitema wrote: > > > > It worked fine when we ran it at IETF51 in London. > > You do mean DHCPv6 for DNS configuration, right? Many platforms do not > support address assignment via DHCPv6... I think the idea is for DNS resolver discovery... but even less probably support that? Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 14:08:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17224 for ; Tue, 28 Oct 2003 14:08:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZCc-0003G0-D2 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 14:08:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SJ8POK012504 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 14:08:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZCb-0003FT-BN for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 14:08:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17167 for ; Tue, 28 Oct 2003 14:08:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEZCY-0004e7-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 14:08:22 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEZCY-0004e4-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 14:08:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZCE-0002yz-MO; Tue, 28 Oct 2003 14:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZBG-0002jW-81 for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 14:07:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17103 for ; Tue, 28 Oct 2003 14:06:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEZBD-0004ch-00 for ipv6@ietf.org; Tue, 28 Oct 2003 14:06:59 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AEZBD-0004bb-00 for ipv6@ietf.org; Tue, 28 Oct 2003 14:06:59 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9SJ5rH25710; Tue, 28 Oct 2003 11:05:53 -0800 X-mProtect: <200310281905> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdYcEm4f; Tue, 28 Oct 2003 11:05:51 PST Message-ID: <3F9EBF4B.6050402@iprg.nokia.com> Date: Tue, 28 Oct 2003 11:11:07 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: Iljitsch van Beijnum , Pekka Savola , "" Subject: Re: "RFC 2461bis" issue: MTU handling References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>No, the existing option is only usable for lowering the MTU used within >>a subnet to a value lower than what the "IP over ..." RFC prescribes. >>We also need a way to convey the maximum packet size that layer 2 >>equipment can handle. I think this should be an option that is similar >>to, but different from the existing MTU option. >> >> > >Just to restate what you are saying differently so that others might understand >it. Today with have a MTU specified in the IPv6 over foo documents. >We have an MTU option in router advertisements that can be used to >lower that number - which is useful(?) for the last century problem of >bridging Ethernet and FDDI together with half-broken fragmenting >bridges - can get the FDDI attached nodes to use 1500. > These are what I referred to as "transluscent bridges" in an earlier message. Perhaps that term (circa 1988/89) was only used within certain limited enclaves, e.g., Digital Equipment Corporation. >What Iljitsch is sayin is that if the L2 might support a larger MTU >e.g. by ensuring that all the switches support Ethernet jumboframes >one could add an option (which he calls "MAX MTU" - "maximum L2 packet size" >might be a more differentiated term). > I don't agree that ensuring that all switches support Ethernet jumboframes is a pre-requisite for routers to advertise a larger Max_MTU. Even if only *some* of the switches support the jumboframes, it should be OK as long as... >But if the routers advertised this option, it still wouldn't mean >that a given host was capable of receiving L2 packets of that size. >Hence the need for each host to advertise their MRU in NS/NA type >packets. > ...as long as the hosts *also* do this. >I think this works as long as the network admin can ensure that all the >switches in an L2 in fact support the larger size. > Well, I just don't see this as realistic except in certain constrained enclaves. So, even if we have each host advertising its MRU (e.g., in NS/NA type packets) we still have to verify that packets of that size actually arrive and w/o incurring harmful levels of L2 fragmentation. Also, since L2 paths can fluctuate, we would need to re-verify periodically. >Whether it is important to solve this using additional protocol mechanisms, >or whether it is sufficient to have folks hand-craft VLANs containing >the hosts that support the larger size, is hard to tell. > I fall on the side of the former. Even if folks hand-craft the VLANs, they can still get instances of link MTU reductions in the L2 path between any pair of hosts unless they have complete assurance that all of the switches in the path support the larger MTU - and, that the L2 paths can't fluctuate such that links with smaller MTUs are incorporated. Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 14:17:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17644 for ; Tue, 28 Oct 2003 14:17:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZL0-0004Yf-Df for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 14:17:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SJH6Ja017521 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 14:17:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZL0-0004YV-7f for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 14:17:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17594 for ; Tue, 28 Oct 2003 14:16:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEZKx-0004o8-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 14:17:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEZKx-0004o5-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 14:17:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZKv-0004PQ-HU; Tue, 28 Oct 2003 14:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZKa-0004MM-Ir for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 14:16:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17589 for ; Tue, 28 Oct 2003 14:16:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEZKX-0004nz-00 for ipv6@ietf.org; Tue, 28 Oct 2003 14:16:38 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AEZKX-0004nT-00 for ipv6@ietf.org; Tue, 28 Oct 2003 14:16:37 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9SJG3a00848; Tue, 28 Oct 2003 11:16:03 -0800 X-mProtect: <200310281916> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBPCA5K; Tue, 28 Oct 2003 11:16:02 PST Message-ID: <3F9EC1AD.4010109@iprg.nokia.com> Date: Tue, 28 Oct 2003 11:21:17 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko CC: Erik Nordmark , ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: MTU handling References: <3F9E8AD5.3010703@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > Erik Nordmark wrote: > > > This still has the operational issue of what happens when > > I need extra ports in my office and I get a cheap 4-port hub; neither > > the IT department nor my hosts knows that this box is present and it > > might not support jumboframes. > > I'd favor robustness a lot more than optimization for the highest > available MTU size. Whatever we do, lets make sure the protocol > can deal with the above case. > > > One way to cope with this particular topology, > > but no other topologies of varying frame size switches, would be > > for the host to exchange a 9k packet with the router before > > deciding that it should declare itself 9k capable. > > Yes. But somehow I'm worried about this, particularly when > the MTU size field in ND is 32 bits. Is there any danger that > a false claim of a large MTU size will lead to something > bad happening? Or are we relying on the sender's hardware > to not accept overly large packets for transmission? False claims can be mitigated by employing mechanisms to authenticate ND messages, e.g., SEND. > Also, if the IP header is 40 bytes/packet, one exchange > of two 9k packets It is not an exchange of two 9K packets; it is a 9K probe packet followed by a much smaller acknowledgement packet - on the order of the size of a NA message. The MTU/MRU probing is unidirectional. > consumes as much bandwidth as > the overhead from 225 packets -- a 337 K transmission > at 1500 byte MTU. So perhaps you wouldn't like to do this > every time. I didn't quite catch this - can you re-phrase? Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 14:31:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18303 for ; Tue, 28 Oct 2003 14:31:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZYr-00069R-4o for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 14:31:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SJVPp1023639 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 14:31:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZYq-00069C-VM for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 14:31:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18252 for ; Tue, 28 Oct 2003 14:31:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEZYo-00052j-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 14:31:22 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEZYn-00052g-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 14:31:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZYU-0005vG-Js; Tue, 28 Oct 2003 14:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZXw-0005sp-L2 for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 14:30:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18152 for ; Tue, 28 Oct 2003 14:30:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEZXt-00051B-00 for ipv6@ietf.org; Tue, 28 Oct 2003 14:30:25 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AEZXs-00050e-00 for ipv6@ietf.org; Tue, 28 Oct 2003 14:30:25 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9SJTrR11768; Tue, 28 Oct 2003 11:29:53 -0800 X-mProtect: <200310281929> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdl6B3eF; Tue, 28 Oct 2003 11:29:52 PST Message-ID: <3F9EC4EB.7010200@iprg.nokia.com> Date: Tue, 28 Oct 2003 11:35:07 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alain Durand CC: ipv6@ietf.org Subject: Re: RFC 2460 issue References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Don't know about the sending host, but perhaps the next forwarding hop should send an ICMPv6 parameter problem message (RFC 2463, section 3.4) if it gets a packet with Hop Count = 0? Trouble is, the original source of the IPv6 packet might be different than the previous hop which made the mistake forwarding the packet with Hop Count = 0. So, the ICMPv6 parameter problem message might be of little value to the original source. Fred ftemplin@iprg.nokia.com Alain Durand wrote: > I had this question yesterday and I couldn't find an answer in RFC2460: > > Is it valid for a host to send a packet with Hop Count set to zero? > > - Alain. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 14:47:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19019 for ; Tue, 28 Oct 2003 14:47:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZoa-00082j-92 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 14:47:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SJle9M030911 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 14:47:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZoa-00082U-3F for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 14:47:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18973 for ; Tue, 28 Oct 2003 14:47:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEZoX-0005HV-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 14:47:37 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEZoW-0005HS-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 14:47:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZnx-0007pY-WF; Tue, 28 Oct 2003 14:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZne-0007lL-0v for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 14:46:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18951 for ; Tue, 28 Oct 2003 14:46:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEZnb-0005Gz-00 for ipv6@ietf.org; Tue, 28 Oct 2003 14:46:39 -0500 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 1AEZna-0005Gf-00 for ipv6@ietf.org; Tue, 28 Oct 2003 14:46:38 -0500 Message-ID: From: Dimitry Haskin To: "'Fred Templin'" , Alain Durand Cc: ipv6@ietf.org Subject: RE: RFC 2460 issue Date: Tue, 28 Oct 2003 14:45:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , It is perfectly valid to originate packets with Hop Count set to zero. Such packets, if received, must not be forwarded. However they should be accepted by a receiving node to which these packets are sent to. Dimitry > -----Original Message----- > From: Fred Templin [mailto:ftemplin@iprg.nokia.com] > Sent: Tuesday, October 28, 2003 2:35 PM > To: Alain Durand > Cc: ipv6@ietf.org > Subject: Re: RFC 2460 issue > > > Don't know about the sending host, but perhaps the next forwarding > hop should send an ICMPv6 parameter problem message (RFC 2463, > section 3.4) if it gets a packet with Hop Count = 0? > > Trouble is, the original source of the IPv6 packet might be different > than the previous hop which made the mistake forwarding the packet > with Hop Count = 0. So, the ICMPv6 parameter problem message > might be of little value to the original source. > > Fred > ftemplin@iprg.nokia.com > > > Alain Durand wrote: > > > I had this question yesterday and I couldn't find an answer > in RFC2460: > > > > Is it valid for a host to send a packet with Hop Count set to zero? > > > > - Alain. > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 14:49:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19116 for ; Tue, 28 Oct 2003 14:49:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZq0-00006d-Qc for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 14:49:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SJn8h4000408 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 14:49:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZpz-00006K-4y for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 14:49:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19069 for ; Tue, 28 Oct 2003 14:48:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEZpw-0005J8-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 14:49:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEZpv-0005J5-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 14:49:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZpu-0008L2-HN; Tue, 28 Oct 2003 14:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZpX-0008Gv-5x for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 14:48:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19052 for ; Tue, 28 Oct 2003 14:48:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEZpU-0005Ic-00 for ipv6@ietf.org; Tue, 28 Oct 2003 14:48:36 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AEZpT-0005Hp-00 for ipv6@ietf.org; Tue, 28 Oct 2003 14:48:35 -0500 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h9SJm54S004924; Tue, 28 Oct 2003 13:48:05 -0600 (CST) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Oct 2003 13:47:06 -0600 Received: from [142.133.72.18] (142.133.72.18 [142.133.72.18]) by eammlex033.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id VNTRXCX8; Tue, 28 Oct 2003 14:51:07 -0500 Date: Tue, 28 Oct 2003 14:46:16 -0500 (EST) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: Suresh Krishnan To: john.loughney@nokia.com cc: jari.arkko@kolumbus.fi, , Subject: RE: RFC 2460 issue In-Reply-To: Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830CCE42C8-100000@eammlex037.lmc.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, 28 Oct 2003 john.loughney@nokia.com wrote: Hi Jari/John, That sounds fine but it is not just RFC 2460 that needs to be updated but perhaps many others. Off the top of my head I know that RFC3493 needs to be updated since the IPV6_UNICAST_HOPS socket option now accepts 0 as a valid hop count. I really do not understand what a hop count of 0 implies and why we should bother updating the RFCs. Regards Suresh >Hi Jari, > >> Suresh Krishnan wrote: >> > Hi Alain, >> > Since the hop limit is analogous to TTL in IPv4 the answer should >> > be no. But you will not find the answer in RFC 2460 as this was not >> > covered in RFC 791. This should be covered in the node requirements draft >> > (draft-ietf-ipv6-node-requirements-06.txt) that John is editing. I >> > checked the draft but it did not have a section regarding this(analogous >> > to RFC 1122 section 3.2.1.7). Maybe this can be added to that draft. I am >> > curious as to why you would want to do that though. >> >> I think we have agreed now that the node requirements document is >> not a place to list all updates and deficiencies of existing RFCs -- >> those existing RFCs should be updated instead. > >I agree. > >John > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 14:50:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19212 for ; Tue, 28 Oct 2003 14:50:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZqx-0000aJ-D4 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 14:50:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SJo7A5002135 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 14:50:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZqw-0000V0-2K for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 14:50:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19153 for ; Tue, 28 Oct 2003 14:49:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEZqt-0005Ku-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 14:50:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEZqs-0005Kr-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 14:50:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZqt-0000MT-LE; Tue, 28 Oct 2003 14:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZq7-00007J-9O for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 14:49:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19080 for ; Tue, 28 Oct 2003 14:49:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEZq4-0005JR-00 for ipv6@ietf.org; Tue, 28 Oct 2003 14:49:12 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AEZpy-0005IT-00 for ipv6@ietf.org; Tue, 28 Oct 2003 14:49:09 -0500 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h9SJmX4S004980 for ; Tue, 28 Oct 2003 13:48:33 -0600 (CST) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Oct 2003 13:47:34 -0600 Received: from [142.133.72.18] (142.133.72.18 [142.133.72.18]) by eammlex033.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id VNTRXCYA; Tue, 28 Oct 2003 14:51:34 -0500 Date: Tue, 28 Oct 2003 14:46:43 -0500 (EST) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: suresh.krishnan@ericsson.ca To: ipv6@ietf.org Subject: Router selection dead? Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830CCE42C9-100000@eammlex037.lmc.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This draft has expired and I do not know what happened to it. I checked the archives and could not find out where this is going. draft-ietf-ipv6-router-selection-02.txt Since this has implications on neighbor discovery it might make sense to add this onto RFC2461bis. Regards Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 15:02:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20082 for ; Tue, 28 Oct 2003 15:02:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEa2w-00027M-Cp for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 15:02:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SK2UFB008134 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 15:02:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEa2v-000272-W0 for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 15:02:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20039 for ; Tue, 28 Oct 2003 15:02:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEa2s-0005dp-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 15:02:26 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEa2s-0005dm-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 15:02:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEa2U-0001oT-MH; Tue, 28 Oct 2003 15:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEa1a-0001kZ-Gg for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 15:01:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19986 for ; Tue, 28 Oct 2003 15:00:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEa1X-0005cu-00 for ipv6@ietf.org; Tue, 28 Oct 2003 15:01:03 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AEa1W-0005cT-00 for ipv6@ietf.org; Tue, 28 Oct 2003 15:01:02 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9SK0NZ05930; Tue, 28 Oct 2003 12:00:23 -0800 X-mProtect: <200310282000> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd3Hlu6D; Tue, 28 Oct 2003 12:00:22 PST Message-ID: <3F9ECC12.8040306@iprg.nokia.com> Date: Tue, 28 Oct 2003 12:05:38 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dimitry Haskin CC: Alain Durand , ipv6@ietf.org Subject: Re: RFC 2460 issue References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dimitry Haskin wrote: >It is perfectly valid to originate packets with Hop Count set to zero. Such >packets, if received, must not be forwarded. However they should be accepted >by a receiving node to which these packets are sent to. > Is this a feature or a bug? Fred ftemplin@iprg.nokia.com >Dimitry > > > >>-----Original Message----- >>From: Fred Templin [mailto:ftemplin@iprg.nokia.com] >>Sent: Tuesday, October 28, 2003 2:35 PM >>To: Alain Durand >>Cc: ipv6@ietf.org >>Subject: Re: RFC 2460 issue >> >> >>Don't know about the sending host, but perhaps the next forwarding >>hop should send an ICMPv6 parameter problem message (RFC 2463, >>section 3.4) if it gets a packet with Hop Count = 0? >> >>Trouble is, the original source of the IPv6 packet might be different >>than the previous hop which made the mistake forwarding the packet >>with Hop Count = 0. So, the ICMPv6 parameter problem message >>might be of little value to the original source. >> >>Fred >>ftemplin@iprg.nokia.com >> >> >>Alain Durand wrote: >> >> >> >>>I had this question yesterday and I couldn't find an answer >>> >>> >>in RFC2460: >> >> >>>Is it valid for a host to send a packet with Hop Count set to zero? >>> >>> - Alain. >>> >>> >>> >>>-------------------------------------------------------------------- >>>IETF IPv6 working group mailing list >>>ipv6@ietf.org >>>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>>-------------------------------------------------------------------- >>> >>> >> >> >>-------------------------------------------------------------------- >>IETF IPv6 working group mailing list >>ipv6@ietf.org >>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>-------------------------------------------------------------------- >> >> >> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 15:22:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22368 for ; Tue, 28 Oct 2003 15:22:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEaM8-0004p4-67 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 15:22:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKMKHp018526 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 15:22:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEaM7-0004oe-PQ for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 15:22:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22320 for ; Tue, 28 Oct 2003 15:22:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEaM6-00060a-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 15:22:18 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEaM5-00060W-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 15:22:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEaLq-0004bh-1J; Tue, 28 Oct 2003 15:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEaL2-0004XP-OP for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 15:21:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22251 for ; Tue, 28 Oct 2003 15:21:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEaL1-0005zF-00 for ipv6@ietf.org; Tue, 28 Oct 2003 15:21:11 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AEaL0-0005yf-00 for ipv6@ietf.org; Tue, 28 Oct 2003 15:21:10 -0500 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h9SKKdV32585 for ; Tue, 28 Oct 2003 12:20:39 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h9SKNOtX002732 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 28 Oct 2003 12:23:28 -0800 Message-ID: <3F9ECF3B.8070501@innovationslab.net> Date: Tue, 28 Oct 2003 15:19:07 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: 3rd Call for Agenda Items Content-Type: multipart/mixed; boundary="------------030904020400030601010306" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------030904020400030601010306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit All, Below is the tentative agenda for the IPv6 WG meetings at IETF 58. Any changes, additions, or deletions should be directed to the chairs. Regards, Brian & Bob --------------030904020400030601010306 Content-Type: text/plain; name="Agenda.txt" Content-Disposition: inline; filename="Agenda.txt" Content-Transfer-Encoding: 7bit Tuesday (11/11/03) 1700-1800 ------------------------------ Intro & Agenda Bashing 5 minutes Milestone Review and Document Status 10 minutes Tunnel MIB 10 minutes Proxy RA 10 minutes ICMP Updates 10 minutes Node Requirements 10 minutes Wednesday (11/12/03) 1300-1500 ------------------------------ Intro & Agenda Bashing 5 minutes Flow Label IESG Comments 10 minutes Identifier/Locator Separation 15 minutes NDP/Stateless Autoconfig Updates 30 minutes Scoped Address Arch Document 10 minutes Local Addressing Requirements 20 minutes SL Deprecation Document 20 minutes ULA Document 15 minutes Address Architecture Update 15 minutes --------------030904020400030601010306-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 15:22:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22377 for ; Tue, 28 Oct 2003 15:22:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEaM8-0004p5-6L for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 15:22:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKMKBi018527 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 15:22:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEaM7-0004of-R3 for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 15:22:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22321 for ; Tue, 28 Oct 2003 15:22:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEaM6-00060d-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 15:22:18 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEaM5-00060Y-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 15:22:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEaLs-0004dD-0Z; Tue, 28 Oct 2003 15:22:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEaLG-0004Yw-6A for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 15:21:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22269 for ; Tue, 28 Oct 2003 15:21:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEaLE-0005zd-00 for ipv6@ietf.org; Tue, 28 Oct 2003 15:21:25 -0500 Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AEaLE-0005zV-00 for ipv6@ietf.org; Tue, 28 Oct 2003 15:21:24 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9SKLEXO020431; Tue, 28 Oct 2003 22:21:14 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.6) id h9SKLEb7020427; Tue, 28 Oct 2003 22:21:14 +0200 Date: Tue, 28 Oct 2003 22:21:14 +0200 Message-Id: <200310282021.h9SKLEb7020427@burp.tkv.asdf.org> From: Markku Savela To: suresh.krishnan@ericsson.ca CC: john.loughney@nokia.com, jari.arkko@kolumbus.fi, Alain.Durand@Sun.COM, ipv6@ietf.org In-reply-to: <7B2A7784F4B7F0409947481F3F3FEF830CCE42C8-100000@eammlex037.lmc.ericsson.se> (message from Suresh Krishnan on Tue, 28 Oct 2003 14:46:16 -0500 (EST)) Subject: Re: RFC 2460 issue References: <7B2A7784F4B7F0409947481F3F3FEF830CCE42C8-100000@eammlex037.lmc.ericsson.se> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > Off the top of my head I know that RFC3493 needs to be updated since > the IPV6_UNICAST_HOPS socket option now accepts 0 as a valid hop > count. I really do not understand what a hop count of 0 implies and > why we should bother updating the RFCs. Heh, yes. I too wondered about what I should do if application sets TTL = 0. There are two choices a) Packets go to /dev/null (perhaps some obscure testing feature?) b) Just let packets with TTL=0 go out. I chose (b), because - TTL is naturally checked only on fowarding, not when sending own packets out. Thus, any TTL just gets accepted and sent. If packet with TTL=0 is for this node, it is accepted (again, because TTL test is only for forwarding). Forwarding decrements TTL and if result is 0 or < 0, packet dropped (with appropriate ICMP if needed). I'm happy with above semantics. I don't see any need to worry about it too much. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 15:44:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25343 for ; Tue, 28 Oct 2003 15:44:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEah7-0000hA-Sp for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 15:44:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKi1dJ002663 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 15:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEah7-0000gs-9q for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 15:44:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25277 for ; Tue, 28 Oct 2003 15:43:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEah5-0006gS-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 15:44:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEah5-0006gP-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 15:43:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEagA-00005S-4E; Tue, 28 Oct 2003 15:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEafM-0008Q7-E9 for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 15:42:12 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24898; Tue, 28 Oct 2003 15:42:01 -0500 (EST) Message-Id: <200310282042.PAA24898@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-flow-label-08.txt Date: Tue, 28 Oct 2003 15:42:00 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Flow Label Specification Author(s) : J. Rajahalme, A. Conta, B. Carpenter, S. Deering Filename : draft-ietf-ipv6-flow-label-08.txt Pages : 9 Date : 2003-10-28 This document specifies the IPv6 Flow Label field, the requirements for IPv6 source nodes labeling flows, the requirements for IPv6 nodes forwarding labeled packets, and the requirements for flow state establishment methods. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-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-ipv6-flow-label-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-ipv6-flow-label-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: <2003-10-28155519.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-flow-label-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-flow-label-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28155519.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 17:21:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01401 for ; Tue, 28 Oct 2003 17:21:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEcCq-00068c-TX for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 17:20:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SMKqxW023586 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 17:20:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEcCq-00068L-B4 for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 17:20:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01344 for ; Tue, 28 Oct 2003 17:20:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEcCo-0000z7-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 17:20:50 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEcCn-0000z1-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 17:20:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEcC5-0005vo-Mr; Tue, 28 Oct 2003 17:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEcBT-0005oN-Hg for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 17:19:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01235 for ; Tue, 28 Oct 2003 17:19:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEcBR-0000x9-00 for ipv6@ietf.org; Tue, 28 Oct 2003 17:19:25 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1AEcBQ-0000vh-00 for ipv6@ietf.org; Tue, 28 Oct 2003 17:19:24 -0500 Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 28 Oct 2003 14:18:54 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Tue, 28 Oct 2003 14:18:54 -0800 Received: from 157.54.6.150 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 28 Oct 2003 14:18:53 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 28 Oct 2003 14:18:53 -0800 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(6.0.3790.0); Tue, 28 Oct 2003 14:18:53 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 28 Oct 2003 14:18:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Router selection dead? Date: Tue, 28 Oct 2003 14:18:49 -0800 Message-ID: Thread-Topic: Router selection dead? thread-index: AcOdjMMocpb9bYRzRsyJ5pog/iDnMgAFFksg From: "Dave Thaler" To: , X-OriginalArrivalTime: 28 Oct 2003 22:18:52.0709 (UTC) FILETIME=[781EDD50:01C39DA1] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The draft will be refreshed. Rich has asked that I take over for him in editing the document. I didn't get it done by the I-D deadline but will post an issues list and a proposed -03 document shortly. -Dave > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Suresh > Krishnan > Sent: Tuesday, October 28, 2003 11:47 AM > To: ipv6@ietf.org > Subject: Router selection dead? >=20 > This draft has expired and I do not know what happened to it. I checked > the archives and could not find out where this is going. >=20 > draft-ietf-ipv6-router-selection-02.txt >=20 > Since this has implications on neighbor discovery it might make sense to > add this onto RFC2461bis. >=20 > Regards > Suresh >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 18:31:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07197 for ; Tue, 28 Oct 2003 18:31:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEdJB-0007uQ-Pj for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 18:31:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SNVTpv030396 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 18:31:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEdJB-0007uB-LF for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 18:31:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07170 for ; Tue, 28 Oct 2003 18:31:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEdJ8-0002d0-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 18:31:26 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEdJ8-0002cx-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 18:31:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEdIk-0007nR-Kq; Tue, 28 Oct 2003 18:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEdIh-0007m9-6r for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 18:30:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07150 for ; Tue, 28 Oct 2003 18:30:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEdIe-0002cj-00 for ipv6@ietf.org; Tue, 28 Oct 2003 18:30:56 -0500 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 1AEdId-0002cg-00 for ipv6@ietf.org; Tue, 28 Oct 2003 18:30:55 -0500 Received: from localhost ([130.194.13.84]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L2EB8WF4RU8ZOQ1W@vaxh.its.monash.edu.au> for ipv6@ietf.org; Wed, 29 Oct 2003 10:08:26 +1100 Received: from blammo.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 480F439C004; Wed, 29 Oct 2003 10:08:26 +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 36CB32DC005; Wed, 29 Oct 2003 10:08:26 +1100 (EST) Date: Wed, 29 Oct 2003 10:08:25 +1100 From: Greg Daley Subject: Re: "RFC 2461bis" issue: DNS configuration To: Tim Chown Cc: ipv6@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3F9EF6E9.9090406@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: <20031028184909.GD12272@login.ecs.soton.ac.uk> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Tim, Tim Chown wrote: > On Tue, Oct 28, 2003 at 09:59:20AM -0800, Christian Huitema wrote: > >>>It worked fine when we ran it at IETF51 in London. >> >>You do mean DHCPv6 for DNS configuration, right? Many platforms do not >>support address assignment via DHCPv6... > > > I think the idea is for DNS resolver discovery... but even less probably > support that? I get your point about current implementation support but think it's worth discussing some issues. I think that one of the big things about Router Discovery and Stateless address autoconfiguration is that people assume that further configuration mechanisms aren't needed, and that RA options are the correct place for additional config information. While the addressing and routing are handled in RA reception and subsequent SAA operations, there's an entire bit ('O' Flag) in the RA header which says consult your DHCP server for further configuration. This actually implies that implementations of stateful addressing and other configuration may be separate in some way. Principally, if M=0, the other configuration doesn't need to be handled statefully on a server (or may be cached on the relay/router). This means the implementation of DHC on routers doesn't need to be terribly sophisticated, and avoids lumping generic configuration into a service which is addressing and routing oriented (Router Advertisement). Greg Daley -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 19:27:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10815 for ; Tue, 28 Oct 2003 19:27:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEeB3-0006By-9n for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 19:27:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T0R9I9023796 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 19:27:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEeB3-0006Bj-39 for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 19:27:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10776 for ; Tue, 28 Oct 2003 19:26:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEeB1-0003qA-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 19:27:07 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEeB0-0003q7-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 19:27:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEeAv-00064l-PU; Tue, 28 Oct 2003 19:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEeA9-0005zK-NY for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 19:26:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10702 for ; Tue, 28 Oct 2003 19:26:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEeA7-0003oa-00 for ipv6@ietf.org; Tue, 28 Oct 2003 19:26:11 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AEeA7-0003nS-00 for ipv6@ietf.org; Tue, 28 Oct 2003 19:26:11 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RD4RH>; Tue, 28 Oct 2003 19:25:32 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E36@ftmail.lab.flarion.com> From: Soliman Hesham To: "" Subject: MTU handling and 2461bis Date: Tue, 28 Oct 2003 19:25:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Folks, I've been following this discussion and trying to understand where people want to solve it. I'm writing my personal conclusion here and please let me know if you disagree. First there is the question of: is this worth solving? and if it is, can it be entirely solved here or do we need to involved IEEE? There seems to be different opinions here. Without getting into the technical issues, which are discussed in detail, and assuming that people think it's worth solving, we have two choices in terms of moving forward: 1. Add the MTU negotiation between two nodes in 2461 bis 2. Another spec can define those options The impression I'm getting is that people are in favour of (2) above. I'm personally in favour of (2) as well. This work seems significant enough to have its own spec. Also, it seems like it will take some time to work out the details of this optimisation and get concensus on the details. So can we move forward based on this conclusion and not put this in 2461bis ? Thanks, Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 20:03:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13364 for ; Tue, 28 Oct 2003 20:03:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEek6-00024Z-Uo for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 20:03:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T13MDZ007961 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 20:03:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEek6-00024K-QD for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 20:03:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13330 for ; Tue, 28 Oct 2003 20:03:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEek4-0004n2-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 20:03:20 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEek4-0004mz-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 20:03:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEejm-0001wd-0C; Tue, 28 Oct 2003 20:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEeje-0001vH-B4 for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 20:02:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13290 for ; Tue, 28 Oct 2003 20:02:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEeja-0004mB-00 for ipv6@ietf.org; Tue, 28 Oct 2003 20:02:50 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AEeja-0004lc-00 for ipv6@ietf.org; Tue, 28 Oct 2003 20:02:50 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9T12Fp13536; Tue, 28 Oct 2003 17:02:15 -0800 X-mProtect: <200310290102> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCsfDIS; Tue, 28 Oct 2003 17:02:13 PST Message-ID: <3F9F12D2.4070501@iprg.nokia.com> Date: Tue, 28 Oct 2003 17:07:30 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: "" Subject: Re: MTU handling and 2461bis References: <748C6D0A58C0F94CA63C198B6674697A01922E36@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Those interested should perhaps have a look at: http://www.ietf.org/internet-drafts/draft-iesg-vendor-extensions-01.txt before responding to Hesham's question. I am seeing in that document some language that may place the bar for acceptance quite high indeed if we were to adopt Hesham's choice # 2. Thanks - Fred ftemplin@iprg.nokia.com Soliman Hesham wrote: >Folks, > >I've been following this discussion and trying to understand >where people want to solve it. I'm writing my personal >conclusion here and please let me know if you disagree. > >First there is the question of: is this worth solving? >and if it is, can it be entirely solved here or do we >need to involved IEEE? > >There seems to be different opinions here. > >Without getting into the technical issues, which are >discussed in detail, and assuming that people think it's >worth solving, we have two choices in terms of >moving forward: > >1. Add the MTU negotiation between two nodes in 2461 bis >2. Another spec can define those options > >The impression I'm getting is that people are in favour >of (2) above. I'm personally in favour of (2) as well. >This work seems significant enough to have its own spec. >Also, it seems like it will take some time to work out >the details of this optimisation and get concensus >on the details. > >So can we move forward based on this conclusion >and not put this in 2461bis ? > >Thanks, >Hesham > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 20:31:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14966 for ; Tue, 28 Oct 2003 20:31:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEfBK-0005mL-K1 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 20:31:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T1VU0A022202 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 20:31:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEfBK-0005m1-CS for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 20:31:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14886 for ; Tue, 28 Oct 2003 20:31:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEfBI-0005NX-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 20:31:28 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEfBH-0005NU-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 20:31:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEfAt-0005bT-8f; Tue, 28 Oct 2003 20:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEfAI-0005ZK-ID for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 20:30:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14792 for ; Tue, 28 Oct 2003 20:30:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEfAG-0005Lg-00 for ipv6@ietf.org; Tue, 28 Oct 2003 20:30:24 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AEfAF-0005Kg-00 for ipv6@ietf.org; Tue, 28 Oct 2003 20:30:23 -0500 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h9T1TrV02246; Tue, 28 Oct 2003 17:29:53 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h9T1WdtX003934 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 28 Oct 2003 17:32:42 -0800 Message-ID: <3F9F17B0.5010808@innovationslab.net> Date: Tue, 28 Oct 2003 20:28:16 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Templin CC: Soliman Hesham , "" Subject: Re: MTU handling and 2461bis References: <748C6D0A58C0F94CA63C198B6674697A01922E36@ftmail.lab.flarion.com> <3F9F12D2.4070501@iprg.nokia.com> In-Reply-To: <3F9F12D2.4070501@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Adding MTU negotiations to 2461bis is a non-starter IMHO. The purpose of 2461bis is to clarify issues in the existing 2461, not add new features. Regards, Brian Fred Templin wrote: > Those interested should perhaps have a look at: > > http://www.ietf.org/internet-drafts/draft-iesg-vendor-extensions-01.txt > > before responding to Hesham's question. I am seeing in that > document some language that may place the bar for acceptance > quite high indeed if we were to adopt Hesham's choice # 2. > > Thanks - Fred > ftemplin@iprg.nokia.com > > Soliman Hesham wrote: > >> Folks, >> I've been following this discussion and trying to understand >> where people want to solve it. I'm writing my personal >> conclusion here and please let me know if you disagree. >> >> First there is the question of: is this worth solving? >> and if it is, can it be entirely solved here or do we need to involved >> IEEE? >> There seems to be different opinions here. >> Without getting into the technical issues, which are discussed in >> detail, and assuming that people think it's >> worth solving, we have two choices in terms of moving forward: >> >> 1. Add the MTU negotiation between two nodes in 2461 bis >> 2. Another spec can define those options >> >> The impression I'm getting is that people are in favour of (2) above. >> I'm personally in favour of (2) as well. >> This work seems significant enough to have its own spec. Also, it >> seems like it will take some time to work out >> the details of this optimisation and get concensus >> on the details. >> So can we move forward based on this conclusion >> and not put this in 2461bis ? >> >> Thanks, Hesham >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 20:58:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16219 for ; Tue, 28 Oct 2003 20:58:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEfbC-0000J8-VT for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 20:58:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T1wErD001183 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 20:58:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEfbC-0000Iy-Jm for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 20:58:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16185 for ; Tue, 28 Oct 2003 20:58:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEfbA-0005qr-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 20:58:12 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEfb9-0005qo-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 20:58:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEfb0-00008v-CO; Tue, 28 Oct 2003 20:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEfag-00006w-Kt for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 20:57:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16153 for ; Tue, 28 Oct 2003 20:57:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEfad-0005qH-00 for ipv6@ietf.org; Tue, 28 Oct 2003 20:57:39 -0500 Received: from coconut.itojun.org ([219.101.47.130]) by ietf-mx with esmtp (Exim 4.12) id 1AEfad-0005qE-00 for ipv6@ietf.org; Tue, 28 Oct 2003 20:57:39 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id 7F44589; Wed, 29 Oct 2003 10:57:37 +0900 (JST) To: pekkas@netcore.fi Cc: v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: Your message of "Tue, 28 Oct 2003 14:30:05 +0200 (EET)" References: X-Mailer: Cue version 0.6 (031002-0709/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031029015737.7F44589@coconut.itojun.org> Date: Wed, 29 Oct 2003 10:57:37 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > So, I'll conclude by a few questions to give food for thought: > > - does this seem like a problem, that is, should getaddrinfo() + > AI_ADDRCONFIG perform AAAA DNS queries etc. if > the node only has v6 link-local/loopback addresses? > > - is getaddrinfo() + link-local addresses something we should support? > > - should this be fixed by e.g.: > a) recommending that the implementations filter out link-locals as well > when doing AI_ADDRCONFIG (a BCP/Info document) > b) specifying additional semantics for AI_ADDRCONFIG > c) specifying a new hint which would perform this d) obsolete AI_ADDRCONFIG. AI_ADDRCONFIG semantics is too vague, and way too difficult to specify (for instance, if you have IPv6 global unicast address and no route, is it configured?). also, even without AI_ADDRCONFIG programs work just fine (socket(2) or connect(2) will issue the right error). itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 21:48:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17302 for ; Tue, 28 Oct 2003 21:48:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEgNl-0005c7-1a for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 21:48:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T2mOin021567 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 21:48:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEgNk-0005bm-SU for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 21:48:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17274 for ; Tue, 28 Oct 2003 21:48:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEgNh-0006Ms-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 21:48:22 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEgNh-0006Mp-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 21:48:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEgNN-0005To-K8; Tue, 28 Oct 2003 21:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEgMm-0005Qq-NZ for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 21:47:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17252 for ; Tue, 28 Oct 2003 21:47:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEgMj-0006MR-00 for ipv6@ietf.org; Tue, 28 Oct 2003 21:47:21 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AEgMj-0006Lq-00 for ipv6@ietf.org; Tue, 28 Oct 2003 21:47:21 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RD45X>; Tue, 28 Oct 2003 21:46:48 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E3A@ftmail.lab.flarion.com> From: Soliman Hesham To: "" Subject: Issue 3: on link assumption considered harmful Date: Tue, 28 Oct 2003 21:46:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Folks, This is a fairly straight forward issue. see: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-onlinkassumption-00.txt 2461 says in section 5.2 : Next-hop determination for a given unicast destination operates as follows. The sender performs a longest prefix match against the Prefix List to determine whether the packet's destination is on- or off-link. If the destination is on-link, the next-hop address is the same as the packet's destination address. Otherwise, the sender selects a router from the Default Router List (following the rules described in Section 6.3.6). If the Default Router List is empty, the sender assumes that the destination is on-link. According to the draft mentioned above, this statement was made to allow two links, previously configured with two different global prefixes, to be joined, without a router and allow hosts to communicate using their global prefixes. The problems of this assumption are discussed in section 3 of Alain's draft. The draft suggests that this assumption should be removed from ND specs. Here is the suggestion: The last sentence of the second paragraph of section 5.2 ("Conceptual Sending Algorithm") should be removed. This sentence is currently, "If the Default Router List is empty, the sender assumes that the destination is on-link. Bullet item 3) in section 6.3.6 ("Default Router Selection") should be removed. The item currently reads, "If the Default Router List is empty, assume that all destinations are on-link as specified in Section 5.2." To allow the scenario mentioned above to work, hosts would have to communicate using their link-local addresses. This seems like a reasonable suggestion, any objections? Thanks, Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 21:59:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17614 for ; Tue, 28 Oct 2003 21:59:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEgYF-000791-3F for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 21:59:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T2xFQ4027457 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 21:59:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEgYE-00078m-Tn for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 21:59:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17580 for ; Tue, 28 Oct 2003 21:59:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEgYB-0006Te-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 21:59:11 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEgYA-0006Tb-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 21:59:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEgY2-0006zs-HK; Tue, 28 Oct 2003 21:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEgXq-0006y2-VN for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 21:58:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17572 for ; Tue, 28 Oct 2003 21:58:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEgXn-0006TP-00 for ipv6@ietf.org; Tue, 28 Oct 2003 21:58:47 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AEgXn-0006TM-00 for ipv6@ietf.org; Tue, 28 Oct 2003 21:58:47 -0500 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 3004C140F8; Tue, 28 Oct 2003 21:58:48 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28967-08; Tue, 28 Oct 2003 21:58:47 -0500 (EST) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id EAAF7140A6; Tue, 28 Oct 2003 21:58:46 -0500 (EST) Date: Tue, 28 Oct 2003 21:54:18 -0500 From: Keith Moore To: Soliman Hesham Cc: moore@cs.utk.edu, ipv6@ietf.org Subject: Re: Issue 3: on link assumption considered harmful Message-Id: <20031028215418.7068311b.moore@cs.utk.edu> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922E3A@ftmail.lab.flarion.com> References: <748C6D0A58C0F94CA63C198B6674697A01922E3A@ftmail.lab.flarion.com> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 28 Oct 2003 21:46:44 -0500 Soliman Hesham wrote: > To allow the scenario mentioned above to work, hosts would > have to communicate using their link-local addresses. > > This seems like a reasonable suggestion, any objections? yes. I strenously object to any expectation that ordinary apps should be able to use link-local addresses. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 22:42:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21435 for ; Tue, 28 Oct 2003 22:42:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEhDs-0003Jo-RT for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 22:42:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T3gGtl012750 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 22:42:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEhDs-0003JZ-KF for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 22:42:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21396 for ; Tue, 28 Oct 2003 22:42:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEhDp-00009Q-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 22:42:13 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEhDo-00009N-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 22:42:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEhDe-00039p-NS; Tue, 28 Oct 2003 22:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEhCt-000379-QG for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 22:41:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21361 for ; Tue, 28 Oct 2003 22:41:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEhCq-00008H-00 for ipv6@ietf.org; Tue, 28 Oct 2003 22:41:12 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AEhCp-00007u-00 for ipv6@ietf.org; Tue, 28 Oct 2003 22:41:11 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h9T3eeUP016978; Tue, 28 Oct 2003 19:40:40 -0800 (PST) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9T3eebx020869; Tue, 28 Oct 2003 22:40:40 -0500 (EST) Received: from strat (localhost [127.0.0.1]) by strat.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h9T3edid011844; Tue, 28 Oct 2003 22:40:39 -0500 (EST) Message-Id: <200310290340.h9T3edid011844@strat.East.Sun.COM> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Keith Moore cc: Soliman Hesham , ipv6@ietf.org From: Sebastien Roy Subject: Re: Issue 3: on link assumption considered harmful In-Reply-To: Message from Keith Moore of "Tue, 28 Oct 2003 21:54:18 EST." <20031028215418.7068311b.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Oct 2003 22:40:39 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > > To allow the scenario mentioned above to work, hosts would > > have to communicate using their link-local addresses. > > > > This seems like a reasonable suggestion, any objections? > > yes. I strenously object to any expectation that ordinary apps should > be able to use link-local addresses. The alternative is to configure systems that reside on the same link to have the same prefixes. There's no expectation that apps communicate using link-local addresses. -Seb -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 22:47:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21639 for ; Tue, 28 Oct 2003 22:47:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEhIZ-00041M-TD for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 22:47:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T3l7hN015450 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 22:47:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEhIZ-000417-NN for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 22:47:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21598 for ; Tue, 28 Oct 2003 22:46:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEhIW-0000FC-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 22:47:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEhIV-0000F9-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 22:47:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEhIU-0003sN-Ub; Tue, 28 Oct 2003 22:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEhI3-0003qY-2X for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 22:46:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21572 for ; Tue, 28 Oct 2003 22:46:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEhHz-0000ET-00 for ipv6@ietf.org; Tue, 28 Oct 2003 22:46:31 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AEhHz-0000Dn-00 for ipv6@ietf.org; Tue, 28 Oct 2003 22:46:31 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RD49A>; Tue, 28 Oct 2003 22:50:39 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E3B@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Keith Moore'" Cc: ipv6@ietf.org Subject: RE: Issue 3: on link assumption considered harmful Date: Tue, 28 Oct 2003 22:50:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > > To allow the scenario mentioned above to work, hosts would > > have to communicate using their link-local addresses. > > > > This seems like a reasonable suggestion, any objections? > > yes. I strenously object to any expectation that ordinary > apps should > be able to use link-local addresses. > => I should clarify that this is the last resort, i.e. if no other addresses exist. So first the link should be configured with a single prefix, if it were not, there is nothing left but link-locals. Note that this is very much a corner case where hosts on the link are all manually configured with addresses and there is _no_ default router. Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 23:37:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23491 for ; Tue, 28 Oct 2003 23:37:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEi5E-0000IJ-Bl for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 23:37:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T4bOXh001117 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 23:37:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEi5D-0000Ho-Nc for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 23:37:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23465 for ; Tue, 28 Oct 2003 23:37:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEi5B-0000xX-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 23:37:21 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEi5B-0000xU-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 23:37:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEi4s-00008m-JK; Tue, 28 Oct 2003 23:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEi3x-0008H9-EK for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 23:36:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23369 for ; Tue, 28 Oct 2003 23:35:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEi3v-0000vq-00 for ipv6@ietf.org; Tue, 28 Oct 2003 23:36:03 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AEi3u-0000vn-00 for ipv6@ietf.org; Tue, 28 Oct 2003 23:36:02 -0500 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 0CB53142F9; Tue, 28 Oct 2003 23:36:03 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06081-09; Tue, 28 Oct 2003 23:36:02 -0500 (EST) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 8365E140F7; Tue, 28 Oct 2003 23:36:01 -0500 (EST) Date: Tue, 28 Oct 2003 23:31:32 -0500 From: Keith Moore To: Sebastien Roy Cc: moore@cs.utk.edu, H.Soliman@flarion.com, ipv6@ietf.org Subject: Re: Issue 3: on link assumption considered harmful Message-Id: <20031028233132.2fb12cb3.moore@cs.utk.edu> In-Reply-To: <200310290340.h9T3edid011844@strat.East.Sun.COM> References: <20031028215418.7068311b.moore@cs.utk.edu> <200310290340.h9T3edid011844@strat.East.Sun.COM> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > To allow the scenario mentioned above to work, hosts would > > > have to communicate using their link-local addresses. > > > > > > This seems like a reasonable suggestion, any objections? > > > > yes. I strenously object to any expectation that ordinary apps should > > be able to use link-local addresses. > > The alternative is to configure systems that reside on the same link > to have the same prefixes. there are lots of other ways to solve that problem. none of them can be adequately described in one sentence - there are too many cases to consider. > There's no expectation that apps > communicate using link-local addresses. so the scenario described above was one in which hosts communicate using link-local addresses for some other purpose than to support apps? (in case it isn't clear, this is a rhetorical question) Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 23:41:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23695 for ; Tue, 28 Oct 2003 23:41:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEi8x-0001K2-6B for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 23:41:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T4fF89005076 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 23:41:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEi8w-0001Jf-Un for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 23:41:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23634 for ; Tue, 28 Oct 2003 23:41:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEi8u-000115-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 23:41:12 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEi8u-000112-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 23:41:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEi8l-00015W-54; Tue, 28 Oct 2003 23:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEi81-00010l-Ph for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 23:40:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23592 for ; Tue, 28 Oct 2003 23:40:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEi7z-00010Y-00 for ipv6@ietf.org; Tue, 28 Oct 2003 23:40:15 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AEi7z-00010V-00 for ipv6@ietf.org; Tue, 28 Oct 2003 23:40:15 -0500 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 506AE143A9; Tue, 28 Oct 2003 23:40:16 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07376-02; Tue, 28 Oct 2003 23:40:15 -0500 (EST) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 0064C142EB; Tue, 28 Oct 2003 23:40:15 -0500 (EST) Date: Tue, 28 Oct 2003 23:35:46 -0500 From: Keith Moore To: Soliman Hesham Cc: moore@cs.utk.edu, ipv6@ietf.org Subject: Re: Issue 3: on link assumption considered harmful Message-Id: <20031028233546.305e08ec.moore@cs.utk.edu> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922E3B@ftmail.lab.flarion.com> References: <748C6D0A58C0F94CA63C198B6674697A01922E3B@ftmail.lab.flarion.com> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > To allow the scenario mentioned above to work, hosts would > > > have to communicate using their link-local addresses. > > > > > > This seems like a reasonable suggestion, any objections? > > > > yes. I strenously object to any expectation that ordinary > > apps should be able to use link-local addresses. > > > > => I should clarify that this is the last resort, > i.e. if no other addresses exist. So first the link > should be configured with a single prefix, if it were not, > there is nothing left but link-locals. it would be far better to have the hosts on the link elect a PUPI as a prefix to use on that link than to expect apps to use link-locals, because the transitions between global prefixes and PUPIs are far less disruptive than the transitions between globals and link-locals. in general the transitions between configured and unconfigured networks, and between externally-connected and isolated networks, haven't been worked out yet. (or if they have, I've missed the document that describes this...) they're neither simple nor easy to solve, and we must not treat them as if they are simple. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 23:53:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24098 for ; Tue, 28 Oct 2003 23:53:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEiKU-0002NE-2z for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 23:53:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T4rA0I009118 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 23:53:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEiKT-0002Mz-Uw for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 23:53:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24072 for ; Tue, 28 Oct 2003 23:52:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEiKR-0001CH-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 23:53:07 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEiKR-0001CE-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 23:53:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEiKM-0002G3-89; Tue, 28 Oct 2003 23:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEiK6-0002F3-8K for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 23:52:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24062 for ; Tue, 28 Oct 2003 23:52:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEiK3-0001Bw-00 for ipv6@ietf.org; Tue, 28 Oct 2003 23:52:43 -0500 Received: from coconut.itojun.org ([219.101.47.130]) by ietf-mx with esmtp (Exim 4.12) id 1AEiK2-0001Bo-00 for ipv6@ietf.org; Tue, 28 Oct 2003 23:52:42 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id 8DA1493; Wed, 29 Oct 2003 13:52:41 +0900 (JST) To: H.Soliman@flarion.com Cc: ipv6@ietf.org Subject: Re: Issue 3: on link assumption considered harmful In-Reply-To: Your message of "Tue, 28 Oct 2003 21:46:44 -0500" <748C6D0A58C0F94CA63C198B6674697A01922E3A@ftmail.lab.flarion.com> References: <748C6D0A58C0F94CA63C198B6674697A01922E3A@ftmail.lab.flarion.com> X-Mailer: Cue version 0.6 (031002-0709/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031029045241.8DA1493@coconut.itojun.org> Date: Wed, 29 Oct 2003 13:52:41 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > This is a fairly straight forward issue. > > see: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-onlinkassumption-00.txt > > 2461 says in section 5.2 : > > Next-hop determination for a given unicast destination operates as > follows. The sender performs a longest prefix match against the > Prefix List to determine whether the packet's destination is on- or > off-link. If the destination is on-link, the next-hop address is the > same as the packet's destination address. Otherwise, the sender > selects a router from the Default Router List (following the rules > described in Section 6.3.6). If the Default Router List is empty, > the sender assumes that the destination is on-link. > > According to the draft mentioned above, this statement > was made to allow two links, previously configured with > two different global prefixes, to be joined, without a > router and allow hosts to communicate using their > global prefixes. > > The problems of this assumption are discussed in section 3 > of Alain's draft. The draft suggests that this assumption > should be removed from ND specs. Here is the suggestion: > > The last sentence of the second paragraph of section 5.2 > ("Conceptual Sending Algorithm") should be removed. This sentence > is currently, "If the Default Router List is empty, the sender > assumes that the destination is on-link. > > Bullet item 3) in section 6.3.6 ("Default Router Selection") > should be removed. The item currently reads, "If the Default > Router List is empty, assume that all destinations are on-link as > specified in Section 5.2." > > To allow the scenario mentioned above to work, hosts would > have to communicate using their link-local addresses. > > This seems like a reasonable suggestion, any objections? the "scenario" is not significantly attractive to me. on the other hand, the issue with the current conceptual sending algorithm (fallback to IPv4 gets deleyed severely) is severe, so i'm all for the suggested change. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Oct 28 23:58:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24281 for ; Tue, 28 Oct 2003 23:58:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEiPL-0002zK-D7 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 23:58:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T4wBlp011480 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 23:58:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEiPL-0002z5-8A for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 23:58:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24247 for ; Tue, 28 Oct 2003 23:57:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEiPI-0001HH-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 23:58:08 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEiPI-0001HE-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 23:58:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEiPB-0002qA-Vk; Tue, 28 Oct 2003 23:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEiOb-0002nf-Dn for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 23:57:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24216 for ; Tue, 28 Oct 2003 23:57:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEiOY-0001GS-00 for ipv6@ietf.org; Tue, 28 Oct 2003 23:57:22 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AEiOY-0001Fx-00 for ipv6@ietf.org; Tue, 28 Oct 2003 23:57:22 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RDVBP>; Tue, 28 Oct 2003 23:56:50 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E3C@ftmail.lab.flarion.com> From: Soliman Hesham To: "'itojun@itojun.org'" Cc: ipv6@ietf.org Subject: RE: Issue 3: on link assumption considered harmful Date: Tue, 28 Oct 2003 23:56:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > > the "scenario" is not significantly attractive to me. => Completely agree with you. > on the other > hand, the issue with the current conceptual sending > algorithm (fallback > to IPv4 gets deleyed severely) is severe, so i'm all > for the suggested > change. => Agreed. Hesham > > itojun > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 00:12:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24801 for ; Wed, 29 Oct 2003 00:12:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEicy-0005VV-Dz for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 00:12:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T5CGt3021163 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 00:12:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEicy-0005VG-8U for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 00:12:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24768 for ; Wed, 29 Oct 2003 00:12:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEicv-0001UL-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 00:12:13 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEicv-0001UH-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 00:12:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEicj-0005LZ-CO; Wed, 29 Oct 2003 00:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEicU-0005Jn-Ms for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 00:11:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24727 for ; Wed, 29 Oct 2003 00:11:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEicS-0001TX-00 for ipv6@ietf.org; Wed, 29 Oct 2003 00:11:44 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AEicR-0001TU-00 for ipv6@ietf.org; Wed, 29 Oct 2003 00:11:43 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 583F16A90B; Wed, 29 Oct 2003 07:11:43 +0200 (EET) Message-ID: <3F9F4B15.7090100@kolumbus.fi> Date: Wed, 29 Oct 2003 07:07:33 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Templin Cc: Erik Nordmark , ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: MTU handling References: <3F9E8AD5.3010703@kolumbus.fi> <3F9EC1AD.4010109@iprg.nokia.com> In-Reply-To: <3F9EC1AD.4010109@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Fred Templin wrote: >> Yes. But somehow I'm worried about this, particularly when >> the MTU size field in ND is 32 bits. Is there any danger that >> a false claim of a large MTU size will lead to something >> bad happening? Or are we relying on the sender's hardware >> to not accept overly large packets for transmission? > > False claims can be mitigated by employing mechanisms to > authenticate ND messages, e.g., SEND. SEND can assure that RAs come from an authorized router, and that NAs come from the owner of an address. SEND may not be able to assure that the sender of an NA is trusted. That is, we know it comes from the node in question, but we may not be able to trust all the parameters it sends. In conclusion if the MTU info comes from a router, SEND is sufficient, but if its host to host, SEND may not be sufficient. Anyway, I still think this danger is _mostly_ a non-issue -- your regular 10 Mbit/s ethernet hardware would hopefully decline to send a 2^32 byte probe packet and spend 3400 seconds sending it. However, there might be some special network technology where this might be an issue. Anyway, anything beyond 2^16 would require a jumbogram. >> Also, if the IP header is 40 bytes/packet, one exchange >> of two 9k packets > > > > It is not an exchange of two 9K packets; it is a 9K probe > packet followed by a much smaller acknowledgement > packet - on the order of the size of a NA message. The > MTU/MRU probing is unidirectional. > >> consumes as much bandwidth as >> the overhead from 225 packets -- a 337 K transmission >> at 1500 byte MTU. So perhaps you wouldn't like to do this >> every time. > > I didn't quite catch this - can you re-phrase? I'm assuming the reason for choosing a larger MTU is to save in header overhead and processing time. But the savings in header overhead must be balanced against the cost of negotiating a larger MTU, particularly if that negotiation involves sending large probe packets. So, one 9K probe is about the same size as the overhead from extra 225 IPv6 headers. Using the standard 1500 byte MTU you get to send about 337 K before spending this much in overhead. That is, a 9K probe packet does not make sense bandwidth-wise if you are communicating less than 337 K with your peer. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 00:13:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24877 for ; Wed, 29 Oct 2003 00:13:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEidp-00062W-0O for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 00:13:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T5D8ia022873 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 00:13:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEidj-0005n4-O8 for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 00:13:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24831 for ; Wed, 29 Oct 2003 00:12:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEidh-0001Vg-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 00:13:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEidg-0001Va-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 00:13:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEidi-0005fv-8i; Wed, 29 Oct 2003 00:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEico-0005N1-FH for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 00:12:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24750 for ; Wed, 29 Oct 2003 00:11:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEicl-0001U3-00 for ipv6@ietf.org; Wed, 29 Oct 2003 00:12:03 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AEicl-0001Tw-00 for ipv6@ietf.org; Wed, 29 Oct 2003 00:12:03 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 49CB615210; Wed, 29 Oct 2003 14:11:53 +0900 (JST) Date: Wed, 29 Oct 2003 14:11:53 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Soliman Hesham Cc: "" Subject: Re: MTU handling and 2461bis In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922E36@ftmail.lab.flarion.com> References: <748C6D0A58C0F94CA63C198B6674697A01922E36@ftmail.lab.flarion.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >>>>> On Tue, 28 Oct 2003 19:25:28 -0500, >>>>> Soliman Hesham said: > So can we move forward based on this conclusion > and not put this in 2461bis ? I, for one, agree. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 00:13:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24931 for ; Wed, 29 Oct 2003 00:13:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEieB-0006DL-3l for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 00:13:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T5DVEV023881 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 00:13:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEieA-0006D6-T1 for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 00:13:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24844 for ; Wed, 29 Oct 2003 00:13:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEie8-0001Vy-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 00:13:28 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEie7-0001Vu-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 00:13:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEidm-0005zb-QS; Wed, 29 Oct 2003 00:13:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEidY-0005eM-Ts for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 00:12:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24817 for ; Wed, 29 Oct 2003 00:12:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEidW-0001V7-00 for ipv6@ietf.org; Wed, 29 Oct 2003 00:12:50 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AEidV-0001V3-00 for ipv6@ietf.org; Wed, 29 Oct 2003 00:12:49 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9T5CkPh007035; Tue, 28 Oct 2003 22:12:47 -0700 (MST) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9T5CkIr009316; Wed, 29 Oct 2003 00:12:46 -0500 (EST) Received: from strat (localhost [127.0.0.1]) by strat.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h9T5Ckid012098; Wed, 29 Oct 2003 00:12:46 -0500 (EST) Message-Id: <200310290512.h9T5Ckid012098@strat.East.Sun.COM> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Keith Moore cc: H.Soliman@flarion.com, ipv6@ietf.org From: Sebastien Roy Subject: Re: Issue 3: on link assumption considered harmful In-Reply-To: Message from Keith Moore of "Tue, 28 Oct 2003 23:31:32 EST." <20031028233132.2fb12cb3.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Oct 2003 00:12:46 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > > > > The alternative is to configure systems that reside on the same link > > to have the same prefixes. > > there are lots of other ways to solve that problem. none of them can be > adequately described in one sentence - there are too many cases to consider. Point taken. There are other ways to solve the problem that the on-link assumption was originally trying to solve. Do you have suggestions on how the draft can better address other possible solutions (if at all)? > > There's no expectation that apps > > communicate using link-local addresses. > > so the scenario described above was one in which hosts communicate > using link-local addresses for some other purpose than to support apps? No, the scenario described in the draft doesn't necessitate using link-local addresses for any purpose. Even if the on-link assumption were taken out of the Neighbor Discovery sending algorithm, there would be no need for apps to communicate using link-local addresses given adequately configured hosts. -Seb -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 00:42:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25888 for ; Wed, 29 Oct 2003 00:42:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEj6E-0001ea-2L for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 00:42:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T5gT6Z006336 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 00:42:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEj6D-0001e4-RV for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 00:42:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25849 for ; Wed, 29 Oct 2003 00:42:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEj6A-0001u0-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 00:42:27 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEj6A-0001tt-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 00:42:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEj5m-0001RP-9q; Wed, 29 Oct 2003 00:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEj5N-0001Pd-WF for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 00:41:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25811 for ; Wed, 29 Oct 2003 00:41:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEj5L-0001t5-00 for ipv6@ietf.org; Wed, 29 Oct 2003 00:41:35 -0500 Received: from evrtwa1-ar8-4-40-179-032.evrtwa1.dsl-verizon.net ([4.40.179.32] helo=tndh.net) by ietf-mx with esmtp (Exim 4.12) id 1AEj5K-0001sw-00 for ipv6@ietf.org; Wed, 29 Oct 2003 00:41:34 -0500 Received: from eaglet (127.0.0.1:3318) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Tue, 28 Oct 2003 21:41:36 -0800 From: "Tony Hain" To: "Michel Py" Cc: Subject: RE: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Date: Tue, 28 Oct 2003 21:41:32 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Michel Py wrote: > Note that p2p is not that unfriendly as of now. I just had a look at one > of the pieces of p2p I use at home; there are some 230k users on the ^^^ > server I connect to, ^^^^^^ And the inconsistency with that statement is ??? > plus a load of other ones with 100k+ users. Some of > the files have 500+ simultaneous sources. These guys are not all network > geeks, and a fair number have broadband and are behind NATs or behind > some kind of a firewall (I ran a few probes). It means that the point > where Joe-six-pack that bought a $50 NAT box is able to type > "http://192.168.1.1", figure out that the password is "admin" and use > the web interface to open the one port that the p2p app needs open has > been reached. Out of the million something users I see right now on > _one_ p2p app, I'd be damned if there are not 100k Joes and Janes that > don't understand squat about networks but that spent the time to read > what they had to do in order to get free pr0n, warez or free mp3s. If it > has reached that kind of mass acceptance, it must be easy enough. > > Michel. > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 00:42:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25903 for ; Wed, 29 Oct 2003 00:42:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEj6E-0001eb-2k for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 00:42:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T5gUbC006350 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 00:42:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEj6D-0001e7-RM for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 00:42:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25847 for ; Wed, 29 Oct 2003 00:42:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEj6A-0001ty-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 00:42:27 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEj6A-0001tu-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 00:42:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEj5n-0001Rb-Gz; Wed, 29 Oct 2003 00:42:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEj5O-0001Pg-2k for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 00:41:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25813 for ; Wed, 29 Oct 2003 00:41:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEj5L-0001t6-00 for ipv6@ietf.org; Wed, 29 Oct 2003 00:41:35 -0500 Received: from evrtwa1-ar8-4-40-179-032.evrtwa1.dsl-verizon.net ([4.40.179.32] helo=tndh.net) by ietf-mx with esmtp (Exim 4.12) id 1AEj5K-0001sx-00 for ipv6@ietf.org; Wed, 29 Oct 2003 00:41:34 -0500 Received: from eaglet (127.0.0.1:3318) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Tue, 28 Oct 2003 21:41:36 -0800 From: "Tony Hain" To: "Pekka Savola" , Cc: Subject: RE: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Date: Tue, 28 Oct 2003 21:41:32 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola wrote: > ... > IMHO, using link-local addresses for anything except well-specified > purposes (e.g. routing protocols, RFC2461/2, etc.) is really, really > counter-productive in your limited world this is undoubtedly true, but there is a wider world out there. > -- as you'll have to make those apps be able to > distinguish the zone identifiers as well, and that's probably > something we > DON'T want to do. But your mileage may vary. > > So, I'll conclude by a few questions to give food for thought: > > - does this seem like a problem, that is, should getaddrinfo() + > AI_ADDRCONFIG perform AAAA DNS queries etc. if > the node only has v6 link-local/loopback addresses? It is not a problem if you follow addr selection rules and prefer matching scopes. This will cause IPv4 to be used if there is only a LL, trying to talk to a AAAA global. > > - is getaddrinfo() + link-local addresses something we should support? Absolutely in the standard. In your specific network, you can turn this off if it causes you to loose sleep at night. > > - should this be fixed by e.g.: > a) recommending that the implementations filter out > link-locals as well > when doing AI_ADDRCONFIG (a BCP/Info document) > b) specifying additional semantics for AI_ADDRCONFIG > c) specifying a new hint which would perform this > > Note: if we go select any of these (especially the latter two), it might > make sense to bring this discussion up in the relevant API forums like > POSIX as well, because the IETF API documents are just Informational RFCs. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 01:10:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26666 for ; Wed, 29 Oct 2003 01:10:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEjX3-0005l1-Qz for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 01:10:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T6ADV8022125 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 01:10:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEjX3-0005km-Ma for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 01:10:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26645 for ; Wed, 29 Oct 2003 01:10:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEjX0-0002DY-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 01:10:10 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEjX0-0002DV-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 01:10:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEjWu-0005gU-5R; Wed, 29 Oct 2003 01:10:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEjWK-0005dE-0d for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 01:09:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26614 for ; Wed, 29 Oct 2003 01:09:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEjWG-0002D4-00 for ipv6@ietf.org; Wed, 29 Oct 2003 01:09:24 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEjWF-0002Ce-00 for ipv6@ietf.org; Wed, 29 Oct 2003 01:09:24 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9T68dp19104; Wed, 29 Oct 2003 08:08:39 +0200 Date: Wed, 29 Oct 2003 08:08:39 +0200 (EET) From: Pekka Savola To: Tony Hain cc: v6ops@ops.ietf.org, Subject: RE: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, 28 Oct 2003, Tony Hain wrote: [...] > > So, I'll conclude by a few questions to give food for thought: > > > > - does this seem like a problem, that is, should getaddrinfo() + > > AI_ADDRCONFIG perform AAAA DNS queries etc. if > > the node only has v6 link-local/loopback addresses? > > It is not a problem if you follow addr selection rules and prefer > matching scopes. This will cause IPv4 to be used if there is only a LL, > trying to talk to a AAAA global. Uhh, I don't think Default Address Selection helps at all here. The question is NOT how you prefer the addresses after you've queried them, it's whether you query them *at all*. I.e., the point of the AI_ADDRCONFIG as it seems to me is to avoid an unnecessary query of IPv6 addresses in the first place. For example, the app wants to look up www.example.com. Prior to making that lookup, it must know which addresses are configured on the node if AI_ADDRCONFIG is used. It doesn't know about scopes of www.example.com at this point. If there are no IPv6 addresses (including link-locals) configured, it'll query only A records and then perform default address selection as you say, naturally ending up with IPv4 as there are no alternatives. If there are IPv6 addresses (including link-locals), it'll query both A and AAAA records and perform default address selection, probably also resulting in IPv4 if no global IPv6 addresses were configured. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 01:15:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26973 for ; Wed, 29 Oct 2003 01:15:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEjbx-000707-Qs for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 01:15:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T6FHEV026905 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 01:15:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEjbw-0006zf-8F for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 01:15:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26920 for ; Wed, 29 Oct 2003 01:15:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEjbs-0002Jt-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 01:15:13 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEjbs-0002Jq-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 01:15:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEjbi-0006h1-EP; Wed, 29 Oct 2003 01:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEjb5-0006b0-GE for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 01:14:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26861 for ; Wed, 29 Oct 2003 01:14:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEjb2-0002Ho-00 for ipv6@ietf.org; Wed, 29 Oct 2003 01:14:20 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEjb1-0002HM-00 for ipv6@ietf.org; Wed, 29 Oct 2003 01:14:19 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9T6DdG19184; Wed, 29 Oct 2003 08:13:40 +0200 Date: Wed, 29 Oct 2003 08:13:38 +0200 (EET) From: Pekka Savola To: Jun-ichiro itojun Hagino cc: v6ops@ops.ietf.org, Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <20031029015737.7F44589@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Wed, 29 Oct 2003, Jun-ichiro itojun Hagino wrote: > d) obsolete AI_ADDRCONFIG. AI_ADDRCONFIG semantics is too vague, and > way too difficult to specify (for instance, if you have IPv6 global > unicast address and no route, is it configured?). also, even without > AI_ADDRCONFIG programs work just fine (socket(2) or connect(2) will > issue the right error). Agreed, that might be one option. Without the on-link assumption, the default route case should be rather simple, though. You'd only have to look at the addresses. IMHO, without the on-link assumption, AI_ADDRCONFIG could help a lot in dual-stack deployments where IPv6 connectivity is not yet enabled. Of course, properly written apps would most probably also work there, but some apps are not properly written, but: - there are really misbehaving DNS servers out there, which jeopardize your IPv4 service if you query for AAAA's, and - if you have no IPv6 address, you'll waste a roundtrip or two in AAAA queries - maybe other considerations we haven't figured out / thought out yet. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 01:54:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28093 for ; Wed, 29 Oct 2003 01:54:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkDq-0003Xe-6G for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 01:54:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T6sQAx013608 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 01:54:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkDq-0003XP-0o for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 01:54:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28056 for ; Wed, 29 Oct 2003 01:54:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEkDm-0002kV-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 01:54:22 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEkDg-0002kK-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 01:54:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkDS-0003Q2-2H; Wed, 29 Oct 2003 01:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkDP-0003P3-EQ for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 01:53:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27993 for ; Wed, 29 Oct 2003 01:53:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEkDL-0002jW-00 for ipv6@ietf.org; Wed, 29 Oct 2003 01:53:55 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AEkDL-0002jD-00 for ipv6@ietf.org; Wed, 29 Oct 2003 01:53:55 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id h9T6rPpI003059; Wed, 29 Oct 2003 07:53:25 +0100 Received: from sverresborg.uninett.no (localhost.localdomain [127.0.0.1]) by sverresborg.uninett.no (8.12.8/8.12.9) with ESMTP id h9T6rPR7031934; Wed, 29 Oct 2003 07:53:25 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id h9T6rOAk031933; Wed, 29 Oct 2003 07:53:24 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 29 Oct 2003 07:53:24 +0100 From: Stig Venaas To: Pekka Savola Cc: Jun-ichiro itojun Hagino , v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-ID: <20031029065324.GA31918@sverresborg.uninett.no> References: <20031029015737.7F44589@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Wed, Oct 29, 2003 at 08:13:38AM +0200, Pekka Savola wrote: > - there are really misbehaving DNS servers out there, which jeopardize > your IPv4 service if you query for AAAA's, and > - if you have no IPv6 address, you'll waste a roundtrip or two in AAAA > queries > - maybe other considerations we haven't figured out / thought out yet. And I've seen cases where you never get a reply to the AAAA query, which means that the application will wait for quite some time. Probably too clever firewalls or broken DNS server software. So I've seen people turn off IPv6 in apps using getaddrinfo() looping through the addresses the normal way, due to this. I don't like the idea of changing getaddrinfo() because of this, one should rather attack the real problem. However that is much harder... Stig -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 02:09:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08048 for ; Wed, 29 Oct 2003 02:09:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkSB-0005f6-ID for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 02:09:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T79Fe9021765 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 02:09:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkSB-0005ey-3C for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 02:09:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07485 for ; Wed, 29 Oct 2003 02:09:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEkS7-0002vv-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 02:09:11 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEkS6-0002vs-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 02:09:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkRy-0005YJ-LX; Wed, 29 Oct 2003 02:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkRs-0005XZ-4d for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 02:08:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07167 for ; Wed, 29 Oct 2003 02:08:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEkRo-0002vZ-00 for ipv6@ietf.org; Wed, 29 Oct 2003 02:08:52 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEkRn-0002v1-00 for ipv6@ietf.org; Wed, 29 Oct 2003 02:08:51 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9T78GC19997; Wed, 29 Oct 2003 09:08:16 +0200 Date: Wed, 29 Oct 2003 09:08:15 +0200 (EET) From: Pekka Savola To: itojun@iijlab.net cc: v6ops@ops.ietf.org, Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <20031029065710.75FB096@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Two points to clarify.. On Wed, 29 Oct 2003 itojun@iijlab.net wrote: > >IMHO, without the on-link assumption, AI_ADDRCONFIG could help a lot in > >dual-stack deployments where IPv6 connectivity is not yet enabled. > > could you clarify what you meant by "dual-stack deployment"? [...] > if it means "dual-stack host in IPv4-only network", it can live fine > without AI_ADDRCONFIG. Yes, I mean the above. AI_ADDRCONFIG makes one avoid completely unnecessary AAAA DNS lookups in the case that the addresses are not useful in any case. > > - there are really misbehaving DNS servers out there, which jeopardize > >your IPv4 service if you query for AAAA's, and > > this is a separate problem (this is not what AI_ADDRCONFIG cares > about). Yes, this is a separate problem .. but one that AI_ADDRCONFIG works around for the vast majority of nodes which could be dual-stack, but without IPv6 connectivity. So, in that sense, IMHO AI_ADDRCONFIG helps the situation *a lot*, but of course we still have to fix the problem for those dual-stack nodes that do, in fact, have IPv6 connectivity. Remember, the most important thing we should care about is that dual-stack deployments can get more common without causing problems for *IPv4* or services in general. AI_ADDRCONFIG is one step in that direction. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 02:12:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10638 for ; Wed, 29 Oct 2003 02:12:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkUy-0006fk-Qr for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 02:12:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T7C8mn025633 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 02:12:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkUx-0006f5-HJ for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 02:12:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10264 for ; Wed, 29 Oct 2003 02:11:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEkUt-0002zo-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 02:12:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEkUt-0002zl-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 02:12:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkUs-0006Vk-TB; Wed, 29 Oct 2003 02:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkUF-0006O5-Dr for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 02:11:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09658 for ; Wed, 29 Oct 2003 02:11:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEkUB-0002zA-00 for ipv6@ietf.org; Wed, 29 Oct 2003 02:11:19 -0500 Received: from coconut.itojun.org ([219.101.47.130]) by ietf-mx with esmtp (Exim 4.12) id 1AEkUA-0002z2-00 for ipv6@ietf.org; Wed, 29 Oct 2003 02:11:19 -0500 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id EA85D13; Wed, 29 Oct 2003 16:11:17 +0900 (JST) To: Pekka Savola Cc: v6ops@ops.ietf.org, ipv6@ietf.org In-reply-to: pekkas's message of Wed, 29 Oct 2003 09:08:15 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG From: itojun@iijlab.net Date: Wed, 29 Oct 2003 16:11:17 +0900 Message-Id: <20031029071117.EA85D13@coconut.itojun.org> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >> > - there are really misbehaving DNS servers out there, which jeopardize >> >your IPv4 service if you query for AAAA's, and >> >> this is a separate problem (this is not what AI_ADDRCONFIG cares >> about). > >Yes, this is a separate problem .. but one that AI_ADDRCONFIG works around >for the vast majority of nodes which could be dual-stack, but without IPv6 >connectivity. So, in that sense, IMHO AI_ADDRCONFIG helps the situation >*a lot*, but of course we still have to fix the problem for those >dual-stack nodes that do, in fact, have IPv6 connectivity. > >Remember, the most important thing we should care about is that dual-stack >deployments can get more common without causing problems for *IPv4* or >services in general. AI_ADDRCONFIG is one step in that direction. for your story to be effective it has to be host-wide configuration knob, not a parameter to library function. (we cannot change every program we use to have AI_ADDRCONFIG) and we (*BSD groups) ship programs without AI_ADDRCONFIG, and they work just fine... itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 02:28:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23731 for ; Wed, 29 Oct 2003 02:28:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkkY-000111-54 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 02:28:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T7SEpK003895 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 02:28:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkkX-00010k-BW for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 02:28:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23293 for ; Wed, 29 Oct 2003 02:28:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEkkT-0003EH-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 02:28:09 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEkkT-0003EE-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 02:28:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkkN-0000ui-8p; Wed, 29 Oct 2003 02:28:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkjs-0000sF-Cy for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 02:27:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22833 for ; Wed, 29 Oct 2003 02:27:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEkjo-0003E1-00 for ipv6@ietf.org; Wed, 29 Oct 2003 02:27:28 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEkjn-0003Dr-00 for ipv6@ietf.org; Wed, 29 Oct 2003 02:27:27 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9T7Qo920283; Wed, 29 Oct 2003 09:26:50 +0200 Date: Wed, 29 Oct 2003 09:26:50 +0200 (EET) From: Pekka Savola To: itojun@iijlab.net cc: v6ops@ops.ietf.org, Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <20031029071117.EA85D13@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Wed, 29 Oct 2003 itojun@iijlab.net wrote: [...] > >Remember, the most important thing we should care about is that dual-stack > >deployments can get more common without causing problems for *IPv4* or > >services in general. AI_ADDRCONFIG is one step in that direction. > > for your story to be effective it has to be host-wide configuration > knob, not a parameter to library function. (we cannot change every > program we use to have AI_ADDRCONFIG) Yep, or the apps writing guidelines could recommend to turn it on. The basic API spec already defines "AI_DEFAULT" even though it doesn't (AFAIR) specify that it should be the default :-) > and we (*BSD groups) ship programs without AI_ADDRCONFIG, and they > work just fine... Yep, to the extent they're used. Stig already mentioned that some apps are moving to some custom address lookup hacks from getaddrinfo() due to these problems. The use of AI_ADDRCONFIG should help in the majority of cases, i.e., deploying v6-capable apps on nodes which don't have v6 connectivity yet. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 04:21:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29607 for ; Wed, 29 Oct 2003 04:21:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEmVK-0006mn-AQ for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 04:20:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T9KcUv026078 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 04:20:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEmVH-0006mM-IC for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 04:20:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29561 for ; Wed, 29 Oct 2003 04:20:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEmVE-0004qJ-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 04:20:32 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEmVD-0004qF-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 04:20:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEmUp-0006Y4-TU; Wed, 29 Oct 2003 04:20:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkGd-0003yV-Mx for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 01:57:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28193 for ; Wed, 29 Oct 2003 01:57:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEkGa-0002mU-00 for ipv6@ietf.org; Wed, 29 Oct 2003 01:57:16 -0500 Received: from coconut.itojun.org ([219.101.47.130]) by ietf-mx with esmtp (Exim 4.12) id 1AEkGZ-0002mR-00 for ipv6@ietf.org; Wed, 29 Oct 2003 01:57:15 -0500 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 75FB096; Wed, 29 Oct 2003 15:57:10 +0900 (JST) To: Pekka Savola Cc: v6ops@ops.ietf.org, ipv6@ietf.org In-reply-to: pekkas's message of Wed, 29 Oct 2003 08:13:38 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG From: itojun@iijlab.net Date: Wed, 29 Oct 2003 15:57:10 +0900 Message-Id: <20031029065710.75FB096@coconut.itojun.org> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >> d) obsolete AI_ADDRCONFIG. AI_ADDRCONFIG semantics is too vague, and >> way too difficult to specify (for instance, if you have IPv6 global >> unicast address and no route, is it configured?). also, even without >> AI_ADDRCONFIG programs work just fine (socket(2) or connect(2) will >> issue the right error). > >Agreed, that might be one option. > >Without the on-link assumption, the default route case should be rather >simple, though. You'd only have to look at the addresses. > >IMHO, without the on-link assumption, AI_ADDRCONFIG could help a lot in >dual-stack deployments where IPv6 connectivity is not yet enabled. could you clarify what you meant by "dual-stack deployment"? if it means "RA is sent by routers even though there's no glbal IPv6 connectivity", that is a misconfiguration (outside of the issue w/ AI_ADDRCONFIG). if it means "dual-stack host in IPv4-only network", it can live fine without AI_ADDRCONFIG. >Of course, properly written apps would most probably also work there, but >some apps are not properly written, but: > > - there are really misbehaving DNS servers out there, which jeopardize >your IPv4 service if you query for AAAA's, and this is a separate problem (this is not what AI_ADDRCONFIG cares about). > - if you have no IPv6 address, you'll waste a roundtrip or two in AAAA >queries this is a sane reason for keeping AI_ADDRCONFIG, but i doubt the roundtrip makes that much of difference. > - maybe other considerations we haven't figured out / thought out yet. :-) itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 04:21:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29609 for ; Wed, 29 Oct 2003 04:21:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEmVM-0006nA-EU for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 04:20:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T9Ke3r026102 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 04:20:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEmVH-0006mO-O6 for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 04:20:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29564 for ; Wed, 29 Oct 2003 04:20:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEmVE-0004qM-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 04:20:32 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEmVE-0004qG-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 04:20:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEmUn-0006Xe-Qn; Wed, 29 Oct 2003 04:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEgFX-0004ur-1T for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 21:39:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17168 for ; Tue, 28 Oct 2003 21:39:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEgFU-0006Ie-00 for ipv6@ietf.org; Tue, 28 Oct 2003 21:39:52 -0500 Received: from mentat.com ([192.88.122.129] helo=roll.mentat.com) by ietf-mx with esmtp (Exim 4.12) id 1AEgFT-0006IP-00 for ipv6@ietf.org; Tue, 28 Oct 2003 21:39:51 -0500 Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) with ESMTP id h9T2cqS17824; Tue, 28 Oct 2003 18:38:52 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) with ESMTP id h9T2RTI21114; Tue, 28 Oct 2003 18:27:29 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id SAA20376; Tue, 28 Oct 2003 18:31:29 -0800 (PST) Date: Tue, 28 Oct 2003 18:31:29 -0800 (PST) From: Tim Hartrick Message-Id: <200310290231.SAA20376@feller.mentat.com> To: ftemplin@iprg.nokia.com, brian@innovationslab.net Subject: Re: MTU handling and 2461bis Cc: H.Soliman@flarion.com, ipv6@ietf.org X-Sun-Charset: US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > > Adding MTU negotiations to 2461bis is a non-starter IMHO. The > purpose of 2461bis is to clarify issues in the existing 2461, not > add new features. > I agree. I don't see how brand new, complex features can be added to the specification without requiring it to recycle to proposed. You can't be draft standard without implementation reports for ALL the features. I don't believe that any new features should be added to this specification. No R bit, no peer-to-peer MTU negotiation. Nothing should be done to this specification except bug fixes. If we crack this thing open for new features our grand children will be working on it. Just my $.02 Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 08:10:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06129 for ; Wed, 29 Oct 2003 08:10:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEq5n-0001SK-GL for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 08:10:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TDAVGs005590 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 08:10:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEq5n-0001S5-BO for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 08:10:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06083 for ; Wed, 29 Oct 2003 08:10:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEq5m-0000M9-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 08:10:30 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEq5l-0000M5-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 08:10:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEq5K-0001JW-Rq; Wed, 29 Oct 2003 08:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEq5G-0001Ib-Oa for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 08:09:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06059 for ; Wed, 29 Oct 2003 08:09:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEq5F-0000LU-00 for ipv6@ietf.org; Wed, 29 Oct 2003 08:09:57 -0500 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx with esmtp (Exim 4.12) id 1AEq5F-0000LQ-00 for ipv6@ietf.org; Wed, 29 Oct 2003 08:09:57 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 227C7FCF5 for ; Wed, 29 Oct 2003 08:09:56 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 29 Oct 2003 08:09:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Review: draft-ietf-v6ops-onlinkassumption-00.txt Date: Wed, 29 Oct 2003 08:09:55 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05122290@tayexc13.americas.cpqcorp.net> Thread-Topic: Review: draft-ietf-v6ops-onlinkassumption-00.txt Thread-Index: AcOccca/X3qI8HRaT8yVY4dqjF7kIwBq2dSQ From: "Bound, Jim" To: "Erik Nordmark" Cc: X-OriginalArrivalTime: 29 Oct 2003 13:09:55.0917 (UTC) FILETIME=[F2ACFFD0:01C39E1D] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > This entire spec is predicated on statement in 2461 that are=20 > > conceptual and not required as compliance to ND RFC 2461. >=20 > Well, the behavior is actually used in section > 6.3.6 "Default Router Selection" where section 6 is "host=20 > specificatio", thus it isn't only a conceptual thing. =20 > 6.3.6 says: > 3) If the Default Router List is empty, assume that all > destinations are on-link as specified in Section 5.2. This is even worse good point. We have a requirement in 6.3.6 to a non-normative reference essentially because it is conceptual. I attach all of 6.3.6 below which is very clear as I implemented this too. And found it to be very friendly to me as implementor for my customers and I do not want any standard telling me how to deal with my route or link lookups in the first place. Not our expertise at all here in IPv6 WG and we cannot dictate implementation to implementors. >=20 > At a minimum the specification is unclear on the requirements=20 > in this space, but the way I read it (and wrote it :-) this=20 > is something that nodes are recommended to do. I agree some cleanup is in order. My view. When L bit set and onlink provided use that and if not use default route. If no default route and no link prefixes your call as implementor but not optimal to send the packet anyway. But as I said there are cases where they should be sent and implementations need to determine why and how and when to permit that configuration not the IPv6 WG. >=20 > Thus I think we need to change that recommendation and make=20 > the specification clearer in the process. I agree and that is editing. /jim 6.3.6. Default Router Selection The algorithm for selecting a router depends in part on whether or not a router is known to be reachable. The exact details of how a node keeps track of a neighbor's reachability state are covered in Section 7.3. The algorithm for selecting a default router is invoked during next-hop determination when no Destination Cache entry exists for an off-link destination or when communication through an existing router appears to be failing. Under normal conditions, a router would be selected the first time traffic is sent to a destination, with subsequent traffic for that destination using the same router as indicated in the Destination Cache modulo any changes to the Destination Cache caused by Redirect messages. The policy for selecting routers from the Default Router List is as follows: 1) Routers that are reachable or probably reachable (i.e., in any state other than INCOMPLETE) SHOULD be preferred over routers whose reachability is unknown or suspect (i.e., in the INCOMPLETE state, or for which no Neighbor Cache entry exists). An implementation may choose to always return the same router or cycle through the router list in a round-robin fashion as long as it always returns a reachable or a probably reachable router when one is available. 2) When no routers on the list are known to be reachable or probably reachable, routers SHOULD be selected in a round-robin fashion, so that subsequent requests for a default router do not return the same router until all other routers have been selected. Cycling through the router list in this case ensures that all available routers are actively probed by the Neighbor Unreachability Detection algorithm. A request for a default router is made in conjunction with the sending of a packet to a router, and the selected router will be probed for reachability as a side effect. 3) If the Default Router List is empty, assume that all destinations are on-link as specified in Section 5.2. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 08:11:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06208 for ; Wed, 29 Oct 2003 08:11:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEq6M-0001fy-6E for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 08:11:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TDB6lC006436 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 08:11:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEq6L-0001fj-Vu for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 08:11:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06146 for ; Wed, 29 Oct 2003 08:10:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEq6L-0000Mr-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 08:11:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEq6K-0000Mo-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 08:11:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEq6J-0001aW-HT; Wed, 29 Oct 2003 08:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEq69-0001YI-UU for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 08:10:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06094 for ; Wed, 29 Oct 2003 08:10:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEq68-0000MX-00 for ipv6@ietf.org; Wed, 29 Oct 2003 08:10:53 -0500 Received: from smtp01.uc3m.es ([163.117.136.121] helo=smtp.uc3m.es) by ietf-mx with esmtp (Exim 4.12) id 1AEq67-0000Lv-00 for ipv6@ietf.org; Wed, 29 Oct 2003 08:10:51 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id D221D432CB; Wed, 29 Oct 2003 14:10:18 +0100 (CET) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp01.uc3m.es (Postfix) with ESMTP id 36F8699F1E; Wed, 29 Oct 2003 14:10:17 +0100 (CET) From: Juan Rodriguez Hervella Organization: UC3M To: Pekka Savola , itojun@iijlab.net Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Date: Wed, 29 Oct 2003 14:10:31 +0100 User-Agent: KMail/1.5.4 Cc: v6ops@ops.ietf.org, References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310291410.32485.jrh@it.uc3m.es> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wednesday 29 October 2003 08:26, Pekka Savola wrote: > On Wed, 29 Oct 2003 itojun@iijlab.net wrote: > [...] > > > >Remember, the most important thing we should care about is that > > > dual-stack deployments can get more common without causing problems for > > > *IPv4* or services in general. AI_ADDRCONFIG is one step in that > > > direction. > > > > for your story to be effective it has to be host-wide configuration > > knob, not a parameter to library function. (we cannot change every > > program we use to have AI_ADDRCONFIG) > > Yep, or the apps writing guidelines could recommend to turn it on. The > basic API spec already defines "AI_DEFAULT" even though it doesn't (AFAIR) > specify that it should be the default :-) > > > and we (*BSD groups) ship programs without AI_ADDRCONFIG, and they > > work just fine... > > Yep, to the extent they're used. Stig already mentioned that some apps > are moving to some custom address lookup hacks from getaddrinfo() due to > these problems. The use of AI_ADDRCONFIG should help in the majority of > cases, i.e., deploying v6-capable apps on nodes which don't have v6 > connectivity yet. I agree with Pekka because it might help to new deployed/ported applications to improve their response times of DNS queries. On the other hand, I think that applications which query the DNS shouldn't be real-time applications, so I see this feature is not very useful. If I understood Stig well, he said that people was turning off IPv6 because of delaying issues. Doing that is not an option if you want to allow your app. to run over "IPv6 AND IPv4". If you can not cope with such delays, maybe you shouldn't be using the DNS at all. The problem here is that most of the times this feature will fail back to the worst case, which is the normal getaddrinfo behaviour, because it's not as easy as checking for global IPv6 configured address, as Itojun has already said. We might come up with a lot of scenarios where this option might fail to improve the response time (e.g: only link-local addresses, global addresses but no default route, proper link local IPv6 configuration but some black-hole on outer routers.....). So...why do we bother ? Thinking about a feature that most of the times will do nothing special is not worthy be implemented. We (*BSD users) feel that applications work just fine without this. -- JFRH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 08:45:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07074 for ; Wed, 29 Oct 2003 08:45:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEqdS-0006Mr-CV for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 08:45:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TDjIJl024474 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 08:45:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEqdS-0006Mf-4b for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 08:45:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07037 for ; Wed, 29 Oct 2003 08:45:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEqdQ-0000nT-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 08:45:16 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEqdQ-0000nQ-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 08:45:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEqdC-0006Fo-G5; Wed, 29 Oct 2003 08:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEqcu-0006ED-SX for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 08:44:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07032 for ; Wed, 29 Oct 2003 08:44:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEqct-0000n4-00 for ipv6@ietf.org; Wed, 29 Oct 2003 08:44:43 -0500 Received: from smtp01.uc3m.es ([163.117.136.121] helo=smtp.uc3m.es) by ietf-mx with esmtp (Exim 4.12) id 1AEqct-0000ll-00 for ipv6@ietf.org; Wed, 29 Oct 2003 08:44:43 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 515B343323; Wed, 29 Oct 2003 14:44:12 +0100 (CET) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp01.uc3m.es (Postfix) with ESMTP id 00C9099F18; Wed, 29 Oct 2003 14:44:03 +0100 (CET) From: Juan Rodriguez Hervella Organization: UC3M To: itojun@itojun.org (Jun-ichiro itojun Hagino), H.Soliman@flarion.com Subject: Re: Issue 3: on link assumption considered harmful Date: Wed, 29 Oct 2003 14:44:18 +0100 User-Agent: KMail/1.5.4 Cc: ipv6@ietf.org References: <748C6D0A58C0F94CA63C198B6674697A01922E3A@ftmail.lab.flarion.com> <20031029045241.8DA1493@coconut.itojun.org> In-Reply-To: <20031029045241.8DA1493@coconut.itojun.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310291444.19413.jrh@it.uc3m.es> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, please read at the bottom: On Wednesday 29 October 2003 05:52, Jun-ichiro itojun Hagino wrote: > > This is a fairly straight forward issue. > > > > see: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-onlinkassumption-00. > >txt > > > > 2461 says in section 5.2 : > > > > Next-hop determination for a given unicast destination operates as > > follows. The sender performs a longest prefix match against the > > Prefix List to determine whether the packet's destination is on- or > > off-link. If the destination is on-link, the next-hop address is the > > same as the packet's destination address. Otherwise, the sender > > selects a router from the Default Router List (following the rules > > described in Section 6.3.6). If the Default Router List is empty, > > the sender assumes that the destination is on-link. > > > > According to the draft mentioned above, this statement > > was made to allow two links, previously configured with > > two different global prefixes, to be joined, without a > > router and allow hosts to communicate using their > > global prefixes. > > > > The problems of this assumption are discussed in section 3 > > of Alain's draft. The draft suggests that this assumption > > should be removed from ND specs. Here is the suggestion: > > > > The last sentence of the second paragraph of section 5.2 > > ("Conceptual Sending Algorithm") should be removed. This sentence > > is currently, "If the Default Router List is empty, the sender > > assumes that the destination is on-link. > > > > Bullet item 3) in section 6.3.6 ("Default Router Selection") > > should be removed. The item currently reads, "If the Default > > Router List is empty, assume that all destinations are on-link as > > specified in Section 5.2." > > > > To allow the scenario mentioned above to work, hosts would > > have to communicate using their link-local addresses. > > > > This seems like a reasonable suggestion, any objections? > > the "scenario" is not significantly attractive to me. on the other > hand, the issue with the current conceptual sending algorithm (fallback > to IPv4 gets deleyed severely) is severe, so i'm all for the suggested > change. I think this scenario is useful for IPv6 small-devices, so I don't quite agree with you all. I feel that we are undoing a lot of things and we will end up with no autoconfiguration features at all. This might be a good thing for sysadmins, though. If I understand the onlinkassumption draft well, the main drawback of sending packets on-link is that some malicious party would be able to grab those packets. I wonder...., if you've got a malicious party on your link, you're suck. Even if you send packets to your default router, the malicious guy could grab ethernet frames and stuff... -- JFRH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 08:51:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07331 for ; Wed, 29 Oct 2003 08:51:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEqj7-0007Lq-4y for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 08:51:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TDp9iF028254 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 08:51:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEqj6-0007Ld-Us for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 08:51:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07291 for ; Wed, 29 Oct 2003 08:50:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEqj5-0000u5-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 08:51:07 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEqj5-0000u2-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 08:51:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEqj0-0007C9-Hb; Wed, 29 Oct 2003 08:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEqiF-00076J-Uk for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 08:50:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07263 for ; Wed, 29 Oct 2003 08:50:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEqiE-0000tK-00 for ipv6@ietf.org; Wed, 29 Oct 2003 08:50:14 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AEqiE-0000t1-00 for ipv6@ietf.org; Wed, 29 Oct 2003 08:50:14 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RDV8N>; Wed, 29 Oct 2003 08:49:32 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E41@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Juan Rodriguez Hervella'" , itojun@itojun.org Cc: ipv6@ietf.org Subject: RE: Issue 3: on link assumption considered harmful Date: Wed, 29 Oct 2003 08:49:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > I think this scenario is useful for IPv6 small-devices, so I > don't quite agree > with you all. > > I feel that we are undoing a lot of things and we will end > up with no > autoconfiguration features at all. This might be a good thing > for sysadmins, though. => I don't think we're undoing any autoconfig here. This is a clarification to avoid other problems without eliminating autoconfig. > > If I understand the onlinkassumption draft well, the main drawback > of sending packets on-link is that some malicious party would > be able to grab those packets. => IMHO, that was not the main issue. I saw bigger issues in that draft. I thought the biggest two were: - impacts on address selection (section 3.1) - Address resolution delays (section 3.2) Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 09:08:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08274 for ; Wed, 29 Oct 2003 09:08:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEqzm-0001tO-3t for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 09:08:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TE8MBk007268 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 09:08:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEqzl-0001t9-V7 for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 09:08:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08198 for ; Wed, 29 Oct 2003 09:08:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEqzk-0001GE-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 09:08:20 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEqzk-0001GB-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 09:08:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEqzS-0001hy-98; Wed, 29 Oct 2003 09:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEqz0-0001Xv-1s for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 09:07:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08173 for ; Wed, 29 Oct 2003 09:07:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEqyy-0001FY-00 for ipv6@ietf.org; Wed, 29 Oct 2003 09:07:32 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AEqyx-0001FD-00 for ipv6@ietf.org; Wed, 29 Oct 2003 09:07:32 -0500 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id h9TE714S024755; Wed, 29 Oct 2003 08:07:01 -0600 (CST) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 29 Oct 2003 08:06:01 -0600 Received: from [142.133.72.18] (142.133.72.18 [142.133.72.18]) by eammlex033.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id VNTRXGTX; Wed, 29 Oct 2003 09:09:59 -0500 Date: Wed, 29 Oct 2003 09:05:06 -0500 (EST) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: Suresh Krishnan To: Fred Templin cc: Alain Durand , Subject: Re: RFC 2460 issue In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF830BD628F1@eammlex037.lmc.ericsson.se> Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830D70184F-100000@eammlex037.lmc.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi Fred, I agree that an ICMPv6 message should be sent by the router but I think it should be the Time Exceeded message (RFC 2463, section 3.3) rather than a parameter problem (section 3.4) message. Regards Suresh On Tue, 28 Oct 2003, Fred Templin wrote: >Don't know about the sending host, but perhaps the next forwarding >hop should send an ICMPv6 parameter problem message (RFC 2463, >section 3.4) if it gets a packet with Hop Count = 0? > >Trouble is, the original source of the IPv6 packet might be different >than the previous hop which made the mistake forwarding the packet >with Hop Count = 0. So, the ICMPv6 parameter problem message >might be of little value to the original source. > >Fred >ftemplin@iprg.nokia.com > > >Alain Durand wrote: > >> I had this question yesterday and I couldn't find an answer in RFC2460: >> >> Is it valid for a host to send a packet with Hop Count set to zero? >> >> - Alain. >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 10:00:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10089 for ; Wed, 29 Oct 2003 10:00:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEroG-0000R8-6L for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 10:00:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TF0WeS001672 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 10:00:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEroF-0000Qt-W5 for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 10:00:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10055 for ; Wed, 29 Oct 2003 10:00:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEroD-00020h-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 10:00:30 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEroD-00020e-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 10:00:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AErnp-0000Im-5V; Wed, 29 Oct 2003 10:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AErnT-0000FZ-5N for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 09:59:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10010 for ; Wed, 29 Oct 2003 09:59:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AErnQ-0001zu-00 for ipv6@ietf.org; Wed, 29 Oct 2003 09:59:41 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1AErnQ-0001yS-00 for ipv6@ietf.org; Wed, 29 Oct 2003 09:59:40 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 29 Oct 2003 15:58:24 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : RFC 2460 issue X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Wed, 29 Oct 2003 15:58:24 +0100 Message-ID: Thread-Topic: RFC 2460 issue Thread-Index: AcOdkS3BgX0B9IufQGO/kj3ndfkvZgAmw8hg From: "KASSI-LAHLOU Mohammed FTRD/DMI/CAE" To: "Markku Savela" , Cc: , , , X-OriginalArrivalTime: 29 Oct 2003 14:58:24.0882 (UTC) FILETIME=[1A523D20:01C39E2D] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, The RFC 2460 says: "Hop Limit 8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is decremented to zero." IMHO, this means: when the Hop Limit=3D0 the packet is discarded. Now, if the packet is sent with Hop Limit=3D0, the forwarding (in the = next hop) decrements the Hop Limit and the result of 0-1 is 255 thus the = packet is not dropped but forwarded. Kassi -----Message d'origine----- De : Markku Savela [mailto:msa@burp.tkv.asdf.org]=20 Envoy=E9 : mardi 28 octobre 2003 21:21 =C0 : suresh.krishnan@ericsson.ca Cc : john.loughney@nokia.com; jari.arkko@kolumbus.fi; = Alain.Durand@Sun.COM; ipv6@ietf.org Objet : Re: RFC 2460 issue > Off the top of my head I know that RFC3493 needs to be updated since=20 > the IPV6_UNICAST_HOPS socket option now accepts 0 as a valid hop=20 > count. I really do not understand what a hop count of 0 implies and=20 > why we should bother updating the RFCs. Heh, yes. I too wondered about what I should do if application sets TTL = =3D 0. There are two choices a) Packets go to /dev/null (perhaps some obscure testing feature?) b) Just let packets with TTL=3D0 go out. I chose (b), because - TTL is naturally checked only on fowarding, not when sending own packets out. Thus, any TTL just gets accepted and sent. If packet with TTL=3D0 is for this node, it is accepted (again, because = TTL test is only for forwarding). Forwarding decrements TTL and if result is 0 or < 0, packet dropped = (with appropriate ICMP if needed). I'm happy with above semantics. I don't see any need to worry about it = too much. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 10:40:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14401 for ; Wed, 29 Oct 2003 10:40:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEsQe-00074v-HD for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 10:40:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TFeB6f027195 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 10:40:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEsQa-00074L-Kw for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 10:40:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14349 for ; Wed, 29 Oct 2003 10:39:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEsQY-00037I-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 10:40:06 -0500 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AEsQX-00036q-01 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 10:40:05 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AEsMw-00085e-50 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 10:36:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEsMc-00065V-4p; Wed, 29 Oct 2003 10:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEsLm-0005zr-I9 for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 10:35:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14084 for ; Wed, 29 Oct 2003 10:34:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEsLk-00032D-00 for ipv6@ietf.org; Wed, 29 Oct 2003 10:35:08 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AEsLj-000328-00 for ipv6@ietf.org; Wed, 29 Oct 2003 10:35:07 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9TFZ45u017210; Wed, 29 Oct 2003 08:35:05 -0700 (MST) Received: from lillen (vpn-129-156-96-136.EMEA.Sun.COM [129.156.96.136]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9TFZ2S17806; Wed, 29 Oct 2003 16:35:03 +0100 (MET) Date: Wed, 29 Oct 2003 16:34:43 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: "RFC 2461bis" issue: MTU handling To: Jari Arkko Cc: Erik Nordmark , ipv6@ietf.org In-Reply-To: "Your message with ID" <3F9E8AD5.3010703@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > Yes. But somehow I'm worried about this, particularly when > the MTU size field in ND is 32 bits. Is there any danger that > a false claim of a large MTU size will lead to something > bad happening? Or are we relying on the sender's hardware > to not accept overly large packets for transmission? Presumably a stack that implements such a future capability would need to verify that the driver/NIC don't fail if they are fed a too large packet. > So, one 9K probe is about the same size as the overhead > from extra 225 IPv6 headers. Using the standard 1500 byte > MTU you get to send about 337 K before spending this much > in overhead. That is, a 9K probe packet does not make sense > bandwidth-wise if you are communicating less than 337 K > with your peer. That is in terms of bandwidth overhead. I think the strongest motivation for jumboframes is that it reduces software overhead in the hosts with as much as a factor of 6 (due to having to deal with one sixth as many packets to transfer the same amount of bulk data). Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 10:45:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14772 for ; Wed, 29 Oct 2003 10:45:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEsVG-0007YY-9W for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 10:44:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TFiweF029040 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 10:44:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEsVF-0007YJ-Kq for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 10:44:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14692 for ; Wed, 29 Oct 2003 10:44:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEsVD-0003Fw-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 10:44:55 -0500 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AEsQm-00036q-02 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 10:40:20 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AEsDc-0007q5-J0 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 10:26:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEsCz-0004Xt-4e; Wed, 29 Oct 2003 10:26:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEsCo-0004WA-M5 for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 10:25:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13359 for ; Wed, 29 Oct 2003 10:25:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEsCl-0002lR-00 for ipv6@ietf.org; Wed, 29 Oct 2003 10:25:51 -0500 Received: from [206.157.230.254] (helo=hatl0ms20.CORP.COX.COM) by ietf-mx with esmtp (Exim 4.12) id 1AEsCl-0002j8-00 for ipv6@ietf.org; Wed, 29 Oct 2003 10:25:51 -0500 Received: from CATL0MS81.corp.cox.com ([10.62.200.231]) by hatl0ms20.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 10:25:19 -0500 Received: from mail pickup service by CATL0MS81.corp.cox.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 10:25:19 -0500 Received: from hatl0ms22.CORP.COX.COM ([10.62.201.69]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 01:16:13 -0500 Received: from bastion.cox.com ([10.230.2.65]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 01:16:13 -0500 Received: from psg.com (psg.com [147.28.0.62]) by bastion.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9T6GDP01255 for ; Wed, 29 Oct 2003 01:16:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEjVh-000IWD-If for v6ops-data@psg.com; Wed, 29 Oct 2003 06:08:49 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEjVd-000IVc-0Y for v6ops@ops.ietf.org; Wed, 29 Oct 2003 06:08:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9T68dp19104; Wed, 29 Oct 2003 08:08:39 +0200 Date: Wed, 29 Oct 2003 08:08:39 +0200 (EET) From: Pekka Savola To: Tony Hain cc: v6ops@ops.ietf.org, Subject: RE: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Precedence: bulk X-OriginalArrivalTime: 29 Oct 2003 06:16:13.0974 (UTC) FILETIME=[27A51360:01C39DE4] Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, 28 Oct 2003, Tony Hain wrote: [...] > > So, I'll conclude by a few questions to give food for thought: > > > > - does this seem like a problem, that is, should getaddrinfo() + > > AI_ADDRCONFIG perform AAAA DNS queries etc. if > > the node only has v6 link-local/loopback addresses? > > It is not a problem if you follow addr selection rules and prefer > matching scopes. This will cause IPv4 to be used if there is only a LL, > trying to talk to a AAAA global. Uhh, I don't think Default Address Selection helps at all here. The question is NOT how you prefer the addresses after you've queried them, it's whether you query them *at all*. I.e., the point of the AI_ADDRCONFIG as it seems to me is to avoid an unnecessary query of IPv6 addresses in the first place. For example, the app wants to look up www.example.com. Prior to making that lookup, it must know which addresses are configured on the node if AI_ADDRCONFIG is used. It doesn't know about scopes of www.example.com at this point. If there are no IPv6 addresses (including link-locals) configured, it'll query only A records and then perform default address selection as you say, naturally ending up with IPv4 as there are no alternatives. If there are IPv6 addresses (including link-locals), it'll query both A and AAAA records and perform default address selection, probably also resulting in IPv4 if no global IPv6 addresses were configured. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 11:38:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17929 for ; Wed, 29 Oct 2003 11:38:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtL5-0005co-7r for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 11:38:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TGcV0w021616 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 11:38:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtL4-0005cZ-Vh for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 11:38:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17893 for ; Wed, 29 Oct 2003 11:38:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEtL3-0004Xc-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 11:38:30 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEtL3-0004XZ-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 11:38:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtKe-0005UC-4D; Wed, 29 Oct 2003 11:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AErir-00080i-3m for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 09:54:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09896 for ; Wed, 29 Oct 2003 09:54:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AErip-0001vx-00 for ipv6@ietf.org; Wed, 29 Oct 2003 09:54:55 -0500 Received: from woozle.fnal.gov ([131.225.9.22]) by ietf-mx with esmtp (Exim 4.12) id 1AErio-0001vu-00 for ipv6@ietf.org; Wed, 29 Oct 2003 09:54:54 -0500 Received: from conversion-daemon.woozle.fnal.gov by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) id <0HNI00E01XF08Z@woozle.fnal.gov> for ipv6@ietf.org; Wed, 29 Oct 2003 08:54:52 -0600 (CST) Received: from fnal.gov (CD-89599-252802-dp.dhcp.fnal.gov [131.225.82.88]) by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTPSA id <0HNI002JFXFGTX@woozle.fnal.gov> for ipv6@ietf.org; Wed, 29 Oct 2003 08:54:52 -0600 (CST) Date: Wed, 29 Oct 2003 08:54:46 -0600 From: Matt Crawford Subject: Re: I-D ACTION:draft-ietf-ipv6-flow-label-08.txt In-reply-to: <200310282042.PAA24898@ietf.org> To: ipv6@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-08.txt The host ought to wait distinctly more than 120 seconds before reusing a flow label, lest the last packet of the previous flow with that label be delayed by a second more than the first packet of the new flow and some router takes action based on the assumption that the two packets belong to the same flow. The amount by which the wait time should exceed 120 seconds should naturally be determined by the maximum packet lifetime, but IPv6 discarded that IPv4 notion. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 11:48:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18464 for ; Wed, 29 Oct 2003 11:48:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtUN-0006vh-MA for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 11:48:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TGm7oM026636 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 11:48:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtUM-0006tR-QO for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 11:48:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18420 for ; Wed, 29 Oct 2003 11:47:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEtUL-0004jo-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 11:48:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEtUL-0004jl-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 11:48:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtUI-0006lh-2F; Wed, 29 Oct 2003 11:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtTl-0006hc-8O for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 11:47:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18406 for ; Wed, 29 Oct 2003 11:47:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEtTj-0004jJ-00 for ipv6@ietf.org; Wed, 29 Oct 2003 11:47:27 -0500 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx with esmtp (Exim 4.12) id 1AEtTj-0004j1-00 for ipv6@ietf.org; Wed, 29 Oct 2003 11:47:27 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6F26836B; Wed, 29 Oct 2003 17:46:56 +0100 (CET) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp03.uc3m.es (Postfix) with ESMTP id 48D2E34D; Wed, 29 Oct 2003 17:46:56 +0100 (CET) From: Juan Rodriguez Hervella Organization: UC3M To: Soliman Hesham , itojun@itojun.org Subject: Re: Issue 3: on link assumption considered harmful Date: Wed, 29 Oct 2003 17:47:11 +0100 User-Agent: KMail/1.5.4 Cc: ipv6@ietf.org References: <748C6D0A58C0F94CA63C198B6674697A01922E41@ftmail.lab.flarion.com> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922E41@ftmail.lab.flarion.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200310291747.12539.jrh@it.uc3m.es> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wednesday 29 October 2003 14:49, Soliman Hesham wrote: > > I think this scenario is useful for IPv6 small-devices, so I > > don't quite agree > > with you all. > > > > I feel that we are undoing a lot of things and we will end > > up with no > > autoconfiguration features at all. This might be a good thing > > for sysadmins, though. > > => I don't think we're undoing any autoconfig here. This is > a clarification to avoid other problems without eliminating > autoconfig. I quote yourself on a previous mail on this thread: "The problems of this assumption are discussed in section 3 of Alain's draft. The draft suggests that this assumption should be removed from ND specs. Here is the suggestion: [snipped but it's read as..."remove" and "remove"...] This seems like a reasonable suggestion, any objections?" As I've already said, I think that on-link communications might be a useful thing to have. > > > If I understand the onlinkassumption draft well, the main drawback > > of sending packets on-link is that some malicious party would > > be able to grab those packets. > > => IMHO, that was not the main issue. I saw bigger > issues in that draft. I thought the biggest two were: > > - impacts on address selection (section 3.1) So let's go to fix address selection instead of removing a nice feature. > - Address resolution delays (section 3.2) > I think that this problem doesn't deserve removing automated on-link communications. I realise that this issue implies that we are penalizing the well-configured IPv4 network. This is better than forbiding IPv6 on-link communications and moreover you might have similar delay penalties even with an IPv6 default router, if there's some black-hole on the routing system... Cheers. -- JFRH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 11:56:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18879 for ; Wed, 29 Oct 2003 11:56:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtcB-0008AG-Dv for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 11:56:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TGuBx1031378 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 11:56:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtcB-0008A1-9p for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 11:56:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18812 for ; Wed, 29 Oct 2003 11:56:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEtcA-0004st-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 11:56:10 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEtc9-0004sq-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 11:56:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtc2-000840-T4; Wed, 29 Oct 2003 11:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtbs-00082k-2d for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 11:55:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18785 for ; Wed, 29 Oct 2003 11:55:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEtbq-0004sF-00 for ipv6@ietf.org; Wed, 29 Oct 2003 11:55:50 -0500 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1AEtbq-0004rZ-00 for ipv6@ietf.org; Wed, 29 Oct 2003 11:55:50 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9TGtGoS017192 for ; Wed, 29 Oct 2003 17:55:17 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9TGscMt266868 for ; Wed, 29 Oct 2003 17:54:38 +0100 Received: from zurich.ibm.com ([9.145.174.1]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA23250 for ; Wed, 29 Oct 2003 17:54:36 +0100 Message-ID: <3F9FF0AC.E475EC3E@zurich.ibm.com> Date: Wed, 29 Oct 2003 17:54:04 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" References: <5.1.0.14.2.20031023182433.00b4ec48@kahuna.telstra.net> <2147483647.1066997649@dhcp-074-101.cns.ohiou.edu> <6DFADCA0-07CE-11D8-95B0-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On 24 okt 2003, at 18:14, Hans Kruse wrote: > > > 2. Several folks stumbled over the wording (in section 1.0) that > > "applications may treat these address[sic] like global scoped > > addresses". How about: > > > "Applications may treat these addresses like global scoped addresses; > > such applications will function correctly within the reach of the > > local addresses. Sites using a mixture of Globally Routable and Local > > addresses may experience sub-optimal application behaviour, see > > sections 8.0-10.0 for further discussion". > > I think this will only confuse people who aren't aware of all the > details. But the problem is more fundamental than wording issues > anyway. The problem is that there are two types of uses for local > addresses: > > 1. To number systems/interfaces that are only accessible from withing > the local network. > > 2. To have stable addresses for systems/interfaces regardless of > intermittant external connectivity and renumbering. It's true that we *know* these addresses will be good for 1., and we don't know whether they will be useful for all aspects of 2. So the draft could indicate this. > > In the case of 1. the scope is site local, although the difinition of > "site" may be subject to change. Being able to route these addresses > throughout the internet would be more of a drawback than a usable > feature, as packets using these addresses may not enter or leave the > network. In the case of 2. having the addresses be globally routable > throughout the internet would be extremely desirable: having addresses > that are stable within the site is good, having addresses that are > stable throughout the net is even better. > > If we recognize that unique local addresses will be used in both > capacities and there is a significant chance that a locator/identifier > separation mechanism could make these addresses globally usable (if not > immediately routable), then it's obvious there are going to be > problems. For instance, coming up with relatively simple filters that > accommodate both uses of the addresses at the same time would be a big > challenge. Having to change the default filtering policies that come > with the OS for huge numbers of boxes would be another issue. Maybe, but it's what people operating Net 10 VPNs do today (assuming the boxes you mean are routers). > > I think that either it must be explicitly stated which type of > addresses we're talking about here. It would probably be best to only > specify type 1 and see what can be done for type 2 with > locator/identifier separation mechanisms. Let's exclude nothing. We don't need to be categorical about "type 2". Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 12:02:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19239 for ; Wed, 29 Oct 2003 12:02:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEths-00014U-M3 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 12:02:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TH24Ge004118 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 12:02:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEthr-00014H-Ti for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 12:02:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19165 for ; Wed, 29 Oct 2003 12:01:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEthq-00050E-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 12:02:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEthp-00050B-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 12:02:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEth3-0000me-8b; Wed, 29 Oct 2003 12:01:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtgh-0000WF-Hm for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 12:00:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19144 for ; Wed, 29 Oct 2003 12:00:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEtge-0004zh-00 for ipv6@ietf.org; Wed, 29 Oct 2003 12:00:49 -0500 Received: from lakehearnglobal.coxinc.com ([206.157.224.254] helo=hatl0ms21.CORP.COX.COM) by ietf-mx with esmtp (Exim 4.12) id 1AEtge-0004zQ-00 for ipv6@ietf.org; Wed, 29 Oct 2003 12:00:48 -0500 Received: from catl0ms23.corp.cox.com ([10.64.200.46]) by hatl0ms21.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 12:00:18 -0500 Received: from mail pickup service by catl0ms23.corp.cox.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 11:46:02 -0500 Received: from hatl0ms23.corp.cox.com ([10.64.200.56]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 00:49:46 -0500 Received: from bastion2.cox.com ([10.225.2.51]) by hatl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 00:49:46 -0500 Received: from psg.com (psg.com [147.28.0.62]) by bastion2.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9T5nio29430 for ; Wed, 29 Oct 2003 00:49:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEj5P-000GRS-Js for v6ops-data@psg.com; Wed, 29 Oct 2003 05:41:39 +0000 Received: from [4.40.179.32] (helo=tndh.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEj5M-000GR2-47 for v6ops@ops.ietf.org; Wed, 29 Oct 2003 05:41:36 +0000 Received: from eaglet (127.0.0.1:3318) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Tue, 28 Oct 2003 21:41:36 -0800 From: "Tony Hain" To: "Pekka Savola" , Cc: Subject: RE: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Date: Tue, 28 Oct 2003 21:41:32 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.3 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK autolearn=no version=2.60 Precedence: bulk X-OriginalArrivalTime: 29 Oct 2003 05:49:46.0634 (UTC) FILETIME=[758436A0:01C39DE0] Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola wrote: > ... > IMHO, using link-local addresses for anything except well-specified > purposes (e.g. routing protocols, RFC2461/2, etc.) is really, really > counter-productive in your limited world this is undoubtedly true, but there is a wider world out there. > -- as you'll have to make those apps be able to > distinguish the zone identifiers as well, and that's probably > something we > DON'T want to do. But your mileage may vary. > > So, I'll conclude by a few questions to give food for thought: > > - does this seem like a problem, that is, should getaddrinfo() + > AI_ADDRCONFIG perform AAAA DNS queries etc. if > the node only has v6 link-local/loopback addresses? It is not a problem if you follow addr selection rules and prefer matching scopes. This will cause IPv4 to be used if there is only a LL, trying to talk to a AAAA global. > > - is getaddrinfo() + link-local addresses something we should support? Absolutely in the standard. In your specific network, you can turn this off if it causes you to loose sleep at night. > > - should this be fixed by e.g.: > a) recommending that the implementations filter out > link-locals as well > when doing AI_ADDRCONFIG (a BCP/Info document) > b) specifying additional semantics for AI_ADDRCONFIG > c) specifying a new hint which would perform this > > Note: if we go select any of these (especially the latter two), it might > make sense to bring this discussion up in the relevant API forums like > POSIX as well, because the IETF API documents are just Informational RFCs. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 12:24:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21563 for ; Wed, 29 Oct 2003 12:24:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEu3R-00040C-7S for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 12:24:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9THOLx7015381 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 12:24:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEu3Q-000400-TI for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 12:24:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21509 for ; Wed, 29 Oct 2003 12:24:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEu3P-0005tB-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 12:24:19 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEu3O-0005t7-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 12:24:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEu38-0003qW-A5; Wed, 29 Oct 2003 12:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEu2q-0003pI-7a for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 12:23:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21445 for ; Wed, 29 Oct 2003 12:23:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEu2o-0005rU-00 for ipv6@ietf.org; Wed, 29 Oct 2003 12:23:42 -0500 Received: from [206.157.230.254] (helo=hatl0ms22.CORP.COX.COM) by ietf-mx with esmtp (Exim 4.12) id 1AEu2o-0005qR-00 for ipv6@ietf.org; Wed, 29 Oct 2003 12:23:42 -0500 Received: from catl0ms22.corp.cox.com ([10.62.200.101]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 12:23:12 -0500 Received: from mail pickup service by catl0ms22.corp.cox.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 12:17:12 -0500 Received: from hatl0ms23.corp.cox.com ([10.64.200.56]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 01:19:05 -0500 Received: from bastion2.cox.com ([10.225.2.51]) by hatl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 01:18:59 -0500 Received: from psg.com (psg.com [147.28.0.62]) by bastion2.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9T6Iwo25726 for ; Wed, 29 Oct 2003 01:18:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEjaZ-000Itr-DW for v6ops-data@psg.com; Wed, 29 Oct 2003 06:13:51 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEjaW-000ItX-Rn for v6ops@ops.ietf.org; Wed, 29 Oct 2003 06:13:49 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9T6DdG19184; Wed, 29 Oct 2003 08:13:40 +0200 Date: Wed, 29 Oct 2003 08:13:38 +0200 (EET) From: Pekka Savola To: Jun-ichiro itojun Hagino cc: v6ops@ops.ietf.org, Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <20031029015737.7F44589@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Precedence: bulk X-OriginalArrivalTime: 29 Oct 2003 06:19:06.0008 (UTC) FILETIME=[8E2F6180:01C39DE4] Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Wed, 29 Oct 2003, Jun-ichiro itojun Hagino wrote: > d) obsolete AI_ADDRCONFIG. AI_ADDRCONFIG semantics is too vague, and > way too difficult to specify (for instance, if you have IPv6 global > unicast address and no route, is it configured?). also, even without > AI_ADDRCONFIG programs work just fine (socket(2) or connect(2) will > issue the right error). Agreed, that might be one option. Without the on-link assumption, the default route case should be rather simple, though. You'd only have to look at the addresses. IMHO, without the on-link assumption, AI_ADDRCONFIG could help a lot in dual-stack deployments where IPv6 connectivity is not yet enabled. Of course, properly written apps would most probably also work there, but some apps are not properly written, but: - there are really misbehaving DNS servers out there, which jeopardize your IPv4 service if you query for AAAA's, and - if you have no IPv6 address, you'll waste a roundtrip or two in AAAA queries - maybe other considerations we haven't figured out / thought out yet. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 12:30:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21968 for ; Wed, 29 Oct 2003 12:30:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEu8d-0004aa-Cz for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 12:29:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9THTh8M017634 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 12:29:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEu8d-0004aL-8l for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 12:29:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21885 for ; Wed, 29 Oct 2003 12:29:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEu8b-000620-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 12:29:41 -0500 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AEtxZ-0005bJ-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 12:18:17 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AEtps-0003Ke-8L for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 12:10:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtpb-0002JR-Hu; Wed, 29 Oct 2003 12:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtpA-0002HL-8n for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 12:09:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19588 for ; Wed, 29 Oct 2003 12:09:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEtp8-0005At-00 for ipv6@ietf.org; Wed, 29 Oct 2003 12:09:34 -0500 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1AEtp7-0005AJ-00 for ipv6@ietf.org; Wed, 29 Oct 2003 12:09:33 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9TH8ONb036348; Wed, 29 Oct 2003 18:08:24 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9TH8OMt257104; Wed, 29 Oct 2003 18:08:24 +0100 Received: from zurich.ibm.com ([9.145.174.1]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id SAA37494; Wed, 29 Oct 2003 18:08:22 +0100 Message-ID: <3F9FF3E6.E5EEDF62@zurich.ibm.com> Date: Wed, 29 Oct 2003 18:07:50 +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: Zefram CC: ipv6@ietf.org Subject: Re: I-D ACTION:draft-main-ipaddr-text-rep-01.txt References: <200310241444.KAA04152@ietf.org> <20031024163339.GC26187@fysh.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Formally, no, this could be processed as an independent submission. But I think review by this WG is desirable anyway. Could the chairs give it 5 minutes on the agenda? Having written the original faulty ABNF, I feel some responsibility here... Brian Zefram wrote: > > Internet-Drafts@ietf.org wrote: > > Title : Textual Representation of IPv4 and IPv6 Addresses > > Author(s) : A. Main > > Filename : draft-main-ipaddr-text-rep-01.txt > > Pages : 12 > > Date : 2003-10-23 > ... > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-main-ipaddr-text-rep-01.txt > > I've not been able to work on this for most of the last six months due > to personal problems, but I've finally got round to handling the comments > from the first draft and I'm in full working order again. > > It was pointed out that this ought to be standards-track, and I've > labelled this draft accordingly. Does this need to be adopted as a WG > draft in order to be published on the standards track? I'm not clear > on the procedure here. If there's any non-trivial decision to be made > about the relation between the WG and this draft then it could probably > be decided quickly in Minneapolis. (I won't be in Minneapolis, btw -- > I'm not going to the US under the present regime.) > > -zefram > -- > Andrew Main (Zefram) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 12:44:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22537 for ; Wed, 29 Oct 2003 12:44:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEuMu-0006GA-I1 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 12:44:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9THiSQW024056 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 12:44:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEuMu-0006Fv-Dd for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 12:44:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22460 for ; Wed, 29 Oct 2003 12:44:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEuMs-0006Im-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 12:44:26 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEuMs-0006Ij-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 12:44:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEuMT-000691-I3; Wed, 29 Oct 2003 12:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEuMG-00067X-HF for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 12:43:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22441 for ; Wed, 29 Oct 2003 12:43:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEuME-0006I5-00 for ipv6@ietf.org; Wed, 29 Oct 2003 12:43:46 -0500 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1AEuME-0006H4-00 for ipv6@ietf.org; Wed, 29 Oct 2003 12:43:46 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9THhDoS228222; Wed, 29 Oct 2003 18:43:13 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9THhDZp274708; Wed, 29 Oct 2003 18:43:13 +0100 Received: from zurich.ibm.com ([9.145.174.1]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id SAA43122; Wed, 29 Oct 2003 18:43:11 +0100 Message-ID: <3F9FFC0F.64F3E5B4@zurich.ibm.com> Date: Wed, 29 Oct 2003 18:42:39 +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: Matt Crawford CC: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-flow-label-08.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Matt, we went backwards and forwards many times on these timeouts in earlier versions. I agree with what you say as a common sense implementation heuristic, but I don't see how to cover it algorithmically in the spec. Since we are now at the stage of having resolved the IESG comments, do you really want another text update? Brian Matt Crawford wrote: > > > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-08.txt > > The host ought to wait distinctly more than 120 seconds before reusing > a flow label, lest the last packet of the previous flow with that label > be delayed by a second more than the first packet of the new flow and > some router takes action based on the assumption that the two packets > belong to the same flow. > > The amount by which the wait time should exceed 120 seconds should > naturally be determined by the maximum packet lifetime, but IPv6 > discarded that IPv4 notion. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 12:45:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22605 for ; Wed, 29 Oct 2003 12:45:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEuNX-0006Zv-0q for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 12:45:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9THj6Dl025274 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 12:45:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEuNV-0006YF-Ta for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 12:45:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22557 for ; Wed, 29 Oct 2003 12:44:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEuNU-0006Lp-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 12:45:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEuNT-0006Lm-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 12:45:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEuNU-0006Qh-7S; Wed, 29 Oct 2003 12:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEuMg-0006BC-O2 for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 12:44:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22450 for ; Wed, 29 Oct 2003 12:44:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEuMf-0006IW-00 for ipv6@ietf.org; Wed, 29 Oct 2003 12:44:13 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AEuMe-0006Hk-00 for ipv6@ietf.org; Wed, 29 Oct 2003 12:44:12 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9THhNL12702; Wed, 29 Oct 2003 09:43:23 -0800 X-mProtect: <200310291743> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFazi0l; Wed, 29 Oct 2003 09:43:22 PST Message-ID: <3F9FFD7B.2080804@iprg.nokia.com> Date: Wed, 29 Oct 2003 09:48:43 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko CC: Erik Nordmark , ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: MTU handling References: <3F9E8AD5.3010703@kolumbus.fi> <3F9EC1AD.4010109@iprg.nokia.com> <3F9F4B15.7090100@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jari Arkko wrote: > Fred Templin wrote: > >>> Yes. But somehow I'm worried about this, particularly when >>> the MTU size field in ND is 32 bits. Is there any danger that >>> a false claim of a large MTU size will lead to something >>> bad happening? Or are we relying on the sender's hardware >>> to not accept overly large packets for transmission? >> >> >> False claims can be mitigated by employing mechanisms to >> authenticate ND messages, e.g., SEND. > > > SEND can assure that RAs come from an authorized router, > and that NAs come from the owner of an address. SEND may > not be able to assure that the sender of an NA is trusted. > That is, we know it comes from the node in question, but > we may not be able to trust all the parameters it sends. > In conclusion if the MTU info comes from a router, SEND > is sufficient, but if its host to host, SEND may not be > sufficient. Well, maybe we should only accept MTU negotiations from routers then; at least that's better than nothing at all. > Anyway, I still think this danger is _mostly_ a non-issue -- > your regular 10 Mbit/s ethernet hardware would hopefully decline to > send a 2^32 byte probe packet and spend 3400 seconds sending > it. However, there might be some special network technology > where this might be an issue. Anyway, anything beyond 2^16 > would require a jumbogram. Agree in terms of the danger being _mostly_ a non-issue. We can use SEND to ensure that RAs indeed come from an authorized router (thanks for clarifying this) so we don't run the danger of sending too-large or too-small packets to final destinations for which the authorized router serves as next-hop. In the case of host-to-host, the worst that can happen when SEND is used is that the receiving host could misinform the sender of the MTU size. Whether the bad size is too small or too large, in the long run it is only the receiver itself (i.e., the sender of the bad MTU information) that will suffer. >>> Also, if the IP header is 40 bytes/packet, one exchange >>> of two 9k packets >> >> >> >> >> It is not an exchange of two 9K packets; it is a 9K probe >> packet followed by a much smaller acknowledgement >> packet - on the order of the size of a NA message. The >> MTU/MRU probing is unidirectional. >> >>> consumes as much bandwidth as >>> the overhead from 225 packets -- a 337 K transmission >>> at 1500 byte MTU. So perhaps you wouldn't like to do this >>> every time. >> >> >> I didn't quite catch this - can you re-phrase? > > > I'm assuming the reason for choosing a larger MTU is to > save in header overhead and processing time. But the savings > in header overhead must be balanced against the cost of > negotiating a larger MTU, particularly if that negotiation > involves sending large probe packets. > > So, one 9K probe is about the same size as the overhead > from extra 225 IPv6 headers. Using the standard 1500 byte > MTU you get to send about 337 K before spending this much > in overhead. That is, a 9K probe packet does not make sense > bandwidth-wise if you are communicating less than 337 K > with your peer. Sure; and it only gets worse for links with larger MTUs to probe. Well, that about wraps it for me - I guess we'll just go ahead and use the data packets themselves as probes then. Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 13:03:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23601 for ; Wed, 29 Oct 2003 13:03:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEuf8-0008Jy-Bc for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 13:03:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TI3IcM031980 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 13:03:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEuf8-0008Jj-5E for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 13:03:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23553 for ; Wed, 29 Oct 2003 13:03:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEuf6-0006qU-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 13:03:16 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEuf5-0006qR-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 13:03:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEuer-000899-9V; Wed, 29 Oct 2003 13:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEueD-00085b-5V for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 13:02:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23502 for ; Wed, 29 Oct 2003 13:02:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEueB-0006ow-00 for ipv6@ietf.org; Wed, 29 Oct 2003 13:02:19 -0500 Received: from [206.157.230.254] (helo=hatl0ms20.CORP.COX.COM) by ietf-mx with esmtp (Exim 4.12) id 1AEueA-0006o9-00 for ipv6@ietf.org; Wed, 29 Oct 2003 13:02:18 -0500 Received: from CATL0MS81.corp.cox.com ([10.62.200.231]) by hatl0ms20.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 13:01:48 -0500 Received: from mail pickup service by CATL0MS81.corp.cox.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 13:01:48 -0500 Received: from hatl0ms22.CORP.COX.COM ([10.62.201.69]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 02:02:32 -0500 Received: from bastion.cox.com ([10.230.2.65]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 02:02:32 -0500 Received: from psg.com (psg.com [147.28.0.62]) by bastion.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9T72VP19384 for ; Wed, 29 Oct 2003 02:02:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEkDZ-000MFv-GN for v6ops-data@psg.com; Wed, 29 Oct 2003 06:54:09 +0000 Received: from [2001:700:1:4:202:55ff:fe67:bc18] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEkDW-000MFU-Ee for v6ops@ops.ietf.org; Wed, 29 Oct 2003 06:54:06 +0000 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id h9T6rPpI003059; Wed, 29 Oct 2003 07:53:25 +0100 Received: from sverresborg.uninett.no (localhost.localdomain [127.0.0.1]) by sverresborg.uninett.no (8.12.8/8.12.9) with ESMTP id h9T6rPR7031934; Wed, 29 Oct 2003 07:53:25 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id h9T6rOAk031933; Wed, 29 Oct 2003 07:53:24 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 29 Oct 2003 07:53:24 +0100 From: Stig Venaas To: Pekka Savola Cc: Jun-ichiro itojun Hagino , v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-ID: <20031029065324.GA31918@sverresborg.uninett.no> References: <20031029015737.7F44589@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Precedence: bulk X-OriginalArrivalTime: 29 Oct 2003 07:02:32.0628 (UTC) FILETIME=[9FDA0740:01C39DEA] Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Wed, Oct 29, 2003 at 08:13:38AM +0200, Pekka Savola wrote: > - there are really misbehaving DNS servers out there, which jeopardize > your IPv4 service if you query for AAAA's, and > - if you have no IPv6 address, you'll waste a roundtrip or two in AAAA > queries > - maybe other considerations we haven't figured out / thought out yet. And I've seen cases where you never get a reply to the AAAA query, which means that the application will wait for quite some time. Probably too clever firewalls or broken DNS server software. So I've seen people turn off IPv6 in apps using getaddrinfo() looping through the addresses the normal way, due to this. I don't like the idea of changing getaddrinfo() because of this, one should rather attack the real problem. However that is much harder... Stig -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 13:14:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24348 for ; Wed, 29 Oct 2003 13:14:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEupn-0001hi-Qa for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 13:14:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TIEJVh006546 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 13:14:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEupn-0001hV-Hz for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 13:14:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24310 for ; Wed, 29 Oct 2003 13:14:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEupl-00077z-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 13:14:17 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEupl-00077w-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 13:14:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEupW-0001Ya-Ed; Wed, 29 Oct 2003 13:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEumZ-0001Cq-88 for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 13:10:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24241 for ; Wed, 29 Oct 2003 13:10:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEumX-00076a-00 for ipv6@ietf.org; Wed, 29 Oct 2003 13:10:57 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AEumW-00076X-00 for ipv6@ietf.org; Wed, 29 Oct 2003 13:10:56 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9TIAuPh017975 for ; Wed, 29 Oct 2003 11:10:56 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HNJ00MDR6I7HE@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Wed, 29 Oct 2003 11:10:56 -0700 (MST) Received: from [192.168.1.100] ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HNJ005EB6I36R@mail.sun.net> for ipv6@ietf.org; Wed, 29 Oct 2003 11:10:52 -0700 (MST) Date: Wed, 29 Oct 2003 10:13:35 -0800 From: Alain Durand Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-reply-to: To: Tony Hain Cc: Pekka Savola , ipv6@ietf.org, v6ops@ops.ietf.org Message-id: <9CC06662-0A3B-11D8-8D05-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.606) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT On Oct 28, 2003, at 9:41 PM, Tony Hain wrote: >> - does this seem like a problem, that is, should getaddrinfo() + >> AI_ADDRCONFIG perform AAAA DNS queries etc. if >> the node only has v6 link-local/loopback addresses? > > It is not a problem if you follow addr selection rules and prefer > matching > scopes. This will cause IPv4 to be used if there is only a LL, trying > to > talk to a AAAA global. Not always. read our 2 drafts, this is clearly explained. If you have a case where IPv6 src= LL, IPv6 dst = GL IPv4 src= SL (rfc1918), IPv4 DST = GL (This is a typical case of a host behind a NAT box) Default address selection will choose the impossible v6 path. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 13:17:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24478 for ; Wed, 29 Oct 2003 13:17:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEusi-0002Jb-8h for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 13:17:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TIHKIq008893 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 13:17:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEusi-0002JA-2p for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 13:17:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24443 for ; Wed, 29 Oct 2003 13:17:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEusd-0007CB-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 13:17:15 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEusd-0007C6-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 13:17:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEusR-00026K-D0; Wed, 29 Oct 2003 13:17:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEusI-000255-PF for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 13:16:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24426 for ; Wed, 29 Oct 2003 13:16:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEusG-0007Be-00 for ipv6@ietf.org; Wed, 29 Oct 2003 13:16:52 -0500 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1AEusG-0007B3-00 for ipv6@ietf.org; Wed, 29 Oct 2003 13:16:52 -0500 Content-class: urn:content-classes:message Subject: RE: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Oct 2003 10:16:20 -0800 Message-ID: x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Thread-Index: AcOd6YKYjiwplFomRr2HN6ZoEubopgAWXJEg From: "Michel Py" To: "Tony Hain" Cc: Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Tony, >> Michel Py wrote: >> Note that p2p is not that unfriendly as of now. I just had a >> look at one of the pieces of p2p I use at home; there are some >< ^^^=20 >> 230k users on the server I connect to,=20 >> ^^^^^^ > Tony Hain wrote: > And the inconsistency with that statement is??? There is not any. Most p2p software relies on some kind of (de)centralized infrastructure. Napster did, it was centralized, that's how they shut it down. Even threedegrees does; even if you remove the Teredo infrastructure there still is a centralized component: where is the list of rooms kept? P2p apps still need a mechanism to locate each other. This is even more important with IPv6 where random scans to find who is running the same app are doomed to fail because of the 64-bit IID. What has changed since the Napster days is that rendezvous points are now more distributed than they originally were. This has everything to do with legal issues and nothing to do with technology. Nevertheless, the best search results are still obtained when a few powerful machines that can handle a large search table are available. The notion of p2p is that _after_ two hosts found each other, they are able to talk directly to each other without relying on any kind of infrastructure; p2p does not mean "no infrastructure whatsoever". The infrastructure has nothing to do with traversing NAT; for that one app I still have to open the port in my router. For your curiosity here is a screen shot: http://arneill-py.sacramento.ca.us/emule.jpg P2p does not only mean files either. I consider SIP a p2p app. Well, even if in theory I could dial another SIP phone directly, I don't (partly because dialing the IP address and port is ugly, partly because the destination address might change). I use a centralized directory service (http://www.pulver.com/fwd/index.html) My point was, given the large numbers of people using such things, joe-six-pack is now able to configure his Linksys to open the p2p app port or the SIP port. The argument that NAT breaks things does not hold water when I see 1.45 million users using the same p2p app at the same time I am using it.=20 Oh, I have news for this WG too: out of these 1.45 million p2p users, 1.45 million do not give a rip to IPv6. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 14:08:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27906 for ; Wed, 29 Oct 2003 14:08:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEvfa-000788-C0 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 14:07:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TJ7oEi027402 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 14:07:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEvfZ-00077d-LR for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 14:07:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27846 for ; Wed, 29 Oct 2003 14:07:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEvfX-0000aC-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 14:07:47 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEvfW-0000a9-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 14:07:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEven-0006nd-OI; Wed, 29 Oct 2003 14:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEve5-0006k5-05 for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 14:06:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27664 for ; Wed, 29 Oct 2003 14:06:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEve2-0000Wc-00 for ipv6@ietf.org; Wed, 29 Oct 2003 14:06:14 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEve1-0000Tn-00 for ipv6@ietf.org; Wed, 29 Oct 2003 14:06:14 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9TJ5X200634; Wed, 29 Oct 2003 21:05:33 +0200 Date: Wed, 29 Oct 2003 21:05:32 +0200 (EET) From: Pekka Savola To: Juan Rodriguez Hervella cc: itojun@iijlab.net, , Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <200310291410.32485.jrh@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Wed, 29 Oct 2003, Juan Rodriguez Hervella wrote: > On the other hand, I think that applications which > query the DNS shouldn't be real-time applications, so I see this > feature is not very useful. How do you see people browsing the web get to the websites then, if not using DNS? That's enough realtime in my book -- the user waits while the request(s) is being processed. I really don't understand what you're trying to say.. > If I understood Stig well, he said that people was > turning off IPv6 because of delaying issues. Doing that is not an option if > you want to allow your app. to run over "IPv6 AND IPv4". If you can not cope > with such delays, maybe you shouldn't be using the DNS at all. Then what? Distributed hosts file? ;-) ? > The problem here is that most of the times this feature will fail back > to the worst case, which is the normal getaddrinfo behaviour, because > it's not as easy as checking for global IPv6 configured address, as Itojun > has already said. We might come up with a lot of scenarios where this > option might fail to improve the response time (e.g: only link-local > addresses, global addresses but no default route, proper link local IPv6 > configuration but some black-hole on outer routers.....). I fail to see the point here: - if only link local addresses: fixed AI_ADDRCONFIG would fix - if global but no default route: a) without the on-link assumption: automatic immediate no route message and fallback to the next address b) with (current) on-link assumption: problematic (which is why the assumption must be killed :-) - if global, default route, but blackhole somewhere: silently discarding packets is evil practice anyway and nothing can be done about that, whether in case of v4 or v6. - if global, default route, everything works, but some DNS server munges the AAAA queries: can't help with that, but because v6 would be used, that has to be fixed by fixing the servers anyway. .. so my perception is that this would fix all the problems related to partial IPv6 deployment I could think of w/ the elimination of the on-link assumption pretty well. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 14:31:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29811 for ; Wed, 29 Oct 2003 14:31:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEw2F-0000nA-7Q for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 14:31:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TJVFQp003038 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 14:31:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEw2F-0000mv-30 for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 14:31:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29759 for ; Wed, 29 Oct 2003 14:31:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEw2C-0001Lb-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 14:31:12 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEw2C-0001LX-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 14:31:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEw22-0000gC-MQ; Wed, 29 Oct 2003 14:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEw18-0000aR-LB for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 14:30:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29549 for ; Wed, 29 Oct 2003 14:29:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEw16-0001IA-00 for ipv6@ietf.org; Wed, 29 Oct 2003 14:30:04 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AEw15-0001I7-00 for ipv6@ietf.org; Wed, 29 Oct 2003 14:30:03 -0500 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id E5EE414186; Wed, 29 Oct 2003 14:30:03 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18816-01; Wed, 29 Oct 2003 14:30:03 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id E9BD0140A4; Wed, 29 Oct 2003 14:30:02 -0500 (EST) Date: Wed, 29 Oct 2003 14:28:03 -0500 From: Keith Moore To: Brian E Carpenter Cc: moore@cs.utk.edu, ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Message-Id: <20031029142803.3b02dda2.moore@cs.utk.edu> In-Reply-To: <3F9FF0AC.E475EC3E@zurich.ibm.com> References: <5.1.0.14.2.20031023182433.00b4ec48@kahuna.telstra.net> <2147483647.1066997649@dhcp-074-101.cns.ohiou.edu> <6DFADCA0-07CE-11D8-95B0-00039388672E@muada.com> <3F9FF0AC.E475EC3E@zurich.ibm.com> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > The problem is that there are two types of uses for local > > addresses: > > > > 1. To number systems/interfaces that are only accessible from withing > > the local network. > > > > 2. To have stable addresses for systems/interfaces regardless of > > intermittant external connectivity and renumbering. There is at least one other potential use: 3. to number systems/interfaces that are attached to networks that don't have connectivity to the public internet Note that this is not the same as #1, since such networks can still talk with other networks, and some of the other networks might have public internet connectivity. Whether my #3 is just a more accurate way of expressing the intent behind #1, I cannot tell. (#1 could be interpreted as "to number systems/interfaces that are only intended to be accessible from within the local network", but that might or might not be what was intended.) > It's true that we *know* these addresses will be good for 1., and we > don't know whether they will be useful for all aspects of 2. So the > draft could indicate this. Actually I'm not sure that it's even reasonable to say this, at least given the way #1 is worded. Before we can really say that it's reasonable to assign local addresses to hosts that are only accessible on a local network (while allowing the possibility that other hosts on that local network have external connectivity) we need to understand how applications that perform address referrals will work. If those apps need to treat local addresses differently than global addresses, it might not be appropriate to assign local addresses to hosts attached to networks that have external connectivity, even if those hosts aren't intended to communicate externally, since that would affect the ability of applications on those hosts to interoperate with other hosts on the same network that did have external connectivity. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 14:42:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00732 for ; Wed, 29 Oct 2003 14:42:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwCo-0002OF-2i for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 14:42:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TJgAtP009181 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 14:42:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwCn-0002Nz-T6 for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 14:42:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00666 for ; Wed, 29 Oct 2003 14:41:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEwCl-0001b9-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 14:42:07 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEwCk-0001b6-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 14:42:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwCg-0002Hp-Hj; Wed, 29 Oct 2003 14:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEw8u-0001sp-Bx for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 14:38:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00370 for ; Wed, 29 Oct 2003 14:37:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEw8r-0001XM-00 for ipv6@ietf.org; Wed, 29 Oct 2003 14:38:05 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AEw8q-0001XJ-00 for ipv6@ietf.org; Wed, 29 Oct 2003 14:38:05 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9TJc35u027525 for ; Wed, 29 Oct 2003 12:38:03 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HNJ008VVAJFZ1@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Wed, 29 Oct 2003 12:38:03 -0700 (MST) Received: from [192.168.1.100] ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HNJ00M9FAJEH7@mail.sun.net> for ipv6@ietf.org; Wed, 29 Oct 2003 12:38:02 -0700 (MST) Date: Wed, 29 Oct 2003 11:40:47 -0800 From: Alain Durand Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" In-reply-to: <3F96659F.4040702@innovationslab.net> To: Brian Haberman Cc: ipv6@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.606) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <3F96659F.4040702@innovationslab.net> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT I think that this effort is not ready for prime time. This document is creating a explosive cocktail made of: - policy: creation of a new authority to perform address assignment outside of the regular channels - economy: imposition of a fixed one time fee model, preventing competition and creating a swamp of untraceable registrations - politics: dangerous instructions to IANA, see Geofff Houston comments - technology: half baked ideas that do not analyze seriously their impact: - what about reverse DNS? - what about address selection rules? - what about address leakage? - how to debug those networks when they will leak? and it is impossible to map those prefixes back to their owner? All this is designed to address what is mostly a perception/social problem which justification only resides in a self serving companion document that fails to demonstrate that such local addresses are actually needed/required. In a rush to create something to replace the Site Local addresses, I'm afraid this document is playing the apprentice sorcerer and will create more long term damage than its author think. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 14:44:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00924 for ; Wed, 29 Oct 2003 14:44:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwEq-000363-Bo for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 14:44:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TJiGb0011897 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 14:44:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwEq-00035o-4G for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 14:44:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00874 for ; Wed, 29 Oct 2003 14:44:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEwEn-0001dw-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 14:44:13 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEwEn-0001dt-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 14:44:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwEb-0002p9-Ra; Wed, 29 Oct 2003 14:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwEA-0002lg-7b for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 14:43:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00820 for ; Wed, 29 Oct 2003 14:43:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEwE7-0001cg-00 for ipv6@ietf.org; Wed, 29 Oct 2003 14:43:31 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AEwE7-0001cd-00 for ipv6@ietf.org; Wed, 29 Oct 2003 14:43:31 -0500 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 77C0414261; Wed, 29 Oct 2003 14:43:31 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20552-03; Wed, 29 Oct 2003 14:43:30 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 60C2C14226; Wed, 29 Oct 2003 14:43:30 -0500 (EST) Date: Wed, 29 Oct 2003 14:41:31 -0500 From: Keith Moore To: "Tony Hain" Cc: moore@cs.utk.edu, pekkas@netcore.fi, v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-Id: <20031029144131.37110a1a.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Pekka Savola wrote: > > ... > > IMHO, using link-local addresses for anything except well-specified > > purposes (e.g. routing protocols, RFC2461/2, etc.) is really, really > > counter-productive > > in your limited world this is undoubtedly true, but there is a wider > world out there. Yes, there is a wider world out there. And in that wider world, what people do on their private networks - including inappropriate use of link-local addresses - really can harm the ability of the global Internet to support applications. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 15:20:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03898 for ; Wed, 29 Oct 2003 15:19:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwn2-0007M6-2K for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 15:19:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TKJa8q028274 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 15:19:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwn1-0007Lx-Pn for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 15:19:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03844 for ; Wed, 29 Oct 2003 15:19:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEwn0-0002QV-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 15:19:34 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEwn0-0002QQ-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 15:19:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwmU-00073g-2a; Wed, 29 Oct 2003 15:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwlk-000711-Kq for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 15:18:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03802 for ; Wed, 29 Oct 2003 15:18:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEwlj-0002PA-00 for ipv6@ietf.org; Wed, 29 Oct 2003 15:18:15 -0500 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx with esmtp (Exim 4.12) id 1AEwli-0002P3-00 for ipv6@ietf.org; Wed, 29 Oct 2003 15:18:14 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 8A373B826; Wed, 29 Oct 2003 15:18:09 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 29 Oct 2003 15:18:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC 2460 issue Date: Wed, 29 Oct 2003 15:18:08 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B051222D1@tayexc13.americas.cpqcorp.net> Thread-Topic: RFC 2460 issue Thread-Index: AcOdkT7RNbXGdLzuRZuAjwG/HeprfwAyHmgA From: "Bound, Jim" To: "Markku Savela" , Cc: , , , X-OriginalArrivalTime: 29 Oct 2003 20:18:08.0956 (UTC) FILETIME=[C4EB9FC0:01C39E59] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I believe same as Savela here. Pretty obvious to me. /jim > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On=20 > Behalf Of Markku Savela > Sent: Tuesday, October 28, 2003 3:21 PM > To: suresh.krishnan@ericsson.ca > Cc: john.loughney@nokia.com; jari.arkko@kolumbus.fi;=20 > Alain.Durand@Sun.COM; ipv6@ietf.org > Subject: Re: RFC 2460 issue >=20 >=20 >=20 > > Off the top of my head I know that RFC3493 needs to be=20 > updated since=20 > > the IPV6_UNICAST_HOPS socket option now accepts 0 as a valid hop=20 > > count. I really do not understand what a hop count of 0 implies and=20 > > why we should bother updating the RFCs. >=20 > Heh, yes. I too wondered about what I should do if=20 > application sets TTL =3D 0. There are two choices >=20 > a) Packets go to /dev/null (perhaps some obscure testing feature?) >=20 > b) Just let packets with TTL=3D0 go out. >=20 > I chose (b), because >=20 > - TTL is naturally checked only on fowarding, not when sending > own packets out. Thus, any TTL just gets accepted and sent. >=20 > If packet with TTL=3D0 is for this node, it is accepted (again,=20 > because TTL test is only for forwarding). >=20 > Forwarding decrements TTL and if result is 0 or < 0, packet=20 > dropped (with appropriate ICMP if needed). >=20 > I'm happy with above semantics. I don't see any need to worry=20 > about it too much. >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 15:38:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04899 for ; Wed, 29 Oct 2003 15:38:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEx55-0001c6-Kv for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 15:38:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TKcFrW006196 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 15:38:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEx55-0001bm-Bd for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 15:38:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04861 for ; Wed, 29 Oct 2003 15:38:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEx53-0002rg-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 15:38:13 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEx53-0002rc-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 15:38:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEx4t-0001QN-BW; Wed, 29 Oct 2003 15:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEx4B-0001Ek-MW for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 15:37:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04796 for ; Wed, 29 Oct 2003 15:37:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEx4A-0002qI-00 for ipv6@ietf.org; Wed, 29 Oct 2003 15:37:18 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEx49-0002pu-00 for ipv6@ietf.org; Wed, 29 Oct 2003 15:37:17 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9TKac302758; Wed, 29 Oct 2003 22:36:38 +0200 Date: Wed, 29 Oct 2003 22:36:38 +0200 (EET) From: Pekka Savola To: Juan Rodriguez Hervella cc: itojun@iijlab.net, , Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <200310292123.45458.jrh@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Wed, 29 Oct 2003, Juan Rodriguez Hervella wrote: > I just say that this option is not *very* useful, having > into account the problems that it has with link-local > addresses and so on... if you fix these problems, it's > a matter of choice, if you want to use it, just do it. Which problems are you referring to? I still don't understand :-( > > > If I understood Stig well, he said that people was > > > turning off IPv6 because of delaying issues. Doing that is not an option > > > if you want to allow your app. to run over "IPv6 AND IPv4". If you can > > > not cope with such delays, maybe you shouldn't be using the DNS at all. > > > > Then what? Distributed hosts file? ;-) ? > > ^--^ ...(after a while)... pouting (grrrr). > > Then what ? it's not my problem, Sorry for my remark, I just could not resist. What you seemed to suggest was, "don't use DNS" without giving any reasonable alternative. That isn't really productive either :-) > I haven't switched to IPv4 because > the IPv6 resolver took a couple of extra roundtrip times. The extra roundtrip times are just the tip of the iceberg. Consider broken DNS servers, load balancers etc. out there -- which may eat your AAAA query for e.g. 10 seconds, causing a lot more delay than a couple of roundtrips. > I see another way of fixing: > > If this option is problematic, don't use it. This has been proved to work, > as a lot of applications don't use it already. As for AI_ADDRCONFIG, it's maybe not used because it hasn't really been implemented that much, maybe because it has been specified in a rather useless way (and it requires a proprietary interface between the glibc and kernel to get the addresses, such as the getaddrinfo destination address ordering as well; dst addr ordering hasn't been implemented that much either).. > You will have to give me other arguments to kill the on-link assuption. Let's keep that subject to a separate thread, (the next message). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 16:05:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06257 for ; Wed, 29 Oct 2003 16:05:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AExVB-0003vx-C8 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 16:05:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TL5Dk4015114 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 16:05:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AExVB-0003vh-6E for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 16:05:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06207 for ; Wed, 29 Oct 2003 16:05:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AExV9-0003Os-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 16:05:11 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AExV9-0003Op-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 16:05:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AExV1-0003oY-EI; Wed, 29 Oct 2003 16:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AExUO-0003ls-80 for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 16:04:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06170 for ; Wed, 29 Oct 2003 16:04:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AExUM-0003OE-00 for ipv6@ietf.org; Wed, 29 Oct 2003 16:04:22 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AExUL-0003Nr-00 for ipv6@ietf.org; Wed, 29 Oct 2003 16:04:22 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9TL3cZ03124; Wed, 29 Oct 2003 23:03:39 +0200 Date: Wed, 29 Oct 2003 23:03:38 +0200 (EET) From: Pekka Savola To: Juan Rodriguez Hervella cc: Soliman Hesham , , , Subject: Re: Issue 3: on link assumption considered harmful In-Reply-To: <200310291747.12539.jrh@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi, Combining this, and the comment from the AI_ADDRCONFIG thread, and adding v6ops in the Cc:.. On Wed, 29 Oct 2003, Juan Rodriguez Hervella wrote: [...] > You will have to give me other arguments to kill the on-link assuption. You seem to have some scenarios in mind where you think these are useful. Please elaborate. Remember that the removing the on-link assumption mostly helps in deployments where there is no IPv6 connectivity at all.. i.e., you're probably not experiencing these personally :-). But those are very probably nasty for folks who might have dual-stack on by default, but without connectivity. More inline.. On Wed, 29 Oct 2003, Juan Rodriguez Hervella wrote: > "The problems of this assumption are discussed in section 3 > of Alain's draft. The draft suggests that this assumption > should be removed from ND specs. Here is the suggestion: > [snipped but it's read as..."remove" and "remove"...] > This seems like a reasonable suggestion, any objections?" > > As I've already said, I think that on-link communications might > be a useful thing to have. You realize, of course, that the document does not try to restrict on-link communications at all? It just recommends that if you don't have a default route, don't assume everybody in the Internet is reachable on-link. This seems rather reasonable in almost all cases, because you generally *can't* expect anything like that. You expect that the prefixes you have the addresses from are on-link (which continue to work without any problems), and that's it :-) > > - impacts on address selection (section 3.1) > > So let's go to fix address selection instead of removing > a nice feature. Again, do you have scenarios in mind where this feature would be useful? The document doesn't (yet :-) tease out the different problems as well as it could, but this isn't just a thing that can be fixed by a simple default address selection modification. For example, if your first-hop router crashes *), but you still have a global IPv6 address, and you perform a DNS lookup over IPv4, and get A and AAAA responses back from the DNS, the on-link assumption would make you try to perform a TCP connect() using the IPv6 address. Obviously, this will cause long timeouts until the router comes back up and replaces the default route. *) here are actually two cases: the default route is removed (e.g. it times out), which is a clear case of an on-link assumption problem, and when default route persists but the next-hop is considered unreachable by NUD (which also triggers the on-link assumption, AFAIR -- but not sure; also not sure how fast NUD will work on the default router's nexthop..). The more obvious problem you may not be seeing is when an implementation has enabled dual-stack but does not have IPv6 connectivity at all (i.e., only the link-local addresses). However, due to the onlink assumption, it tries to reach every IPv6 destination directly on its interfaces. I fail to see any justification for this. Such addresses need not come through default address selection. The clearer issue with default address selection (really, destination address selection, which isn't really implemented that much yet!) is when the the scopes are mismatching. The fix should probably be applied in both, the default address selection (by clarifying what "avoid unusable destinations" should entail) and RFC2461bis, but the latter is more timely and more important. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 16:48:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08752 for ; Wed, 29 Oct 2003 16:48:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEyB9-0008E0-OJ for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 16:48:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TLmZxW031613 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 16:48:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEyB9-0008Do-Jf for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 16:48:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08711 for ; Wed, 29 Oct 2003 16:48:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEyB7-0004Jf-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 16:48:33 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEyB7-0004Jc-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 16:48:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEyAc-00082f-NL; Wed, 29 Oct 2003 16:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEy9q-0007ys-HM for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 16:47:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08664 for ; Wed, 29 Oct 2003 16:47:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEy9o-0004Io-00 for ipv6@ietf.org; Wed, 29 Oct 2003 16:47:12 -0500 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by ietf-mx with esmtp (Exim 4.12) id 1AEy9n-0004IH-00 for ipv6@ietf.org; Wed, 29 Oct 2003 16:47:11 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9TLkefw071766 for ; Wed, 29 Oct 2003 22:46:40 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9TLkeZp269842 for ; Wed, 29 Oct 2003 22:46:40 +0100 Received: from zurich.ibm.com (sig-9-145-226-16.de.ibm.com [9.145.226.16]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id WAA36378 for ; Wed, 29 Oct 2003 22:46:38 +0100 Message-ID: <3FA0351E.37C3F0CA@zurich.ibm.com> Date: Wed, 29 Oct 2003 22:46:06 +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: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" References: <3F96659F.4040702@innovationslab.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alain, Do you think it is better to let the RIRs develop a policy for allocating PA space for local use, i.e. create a swamp like IPv4? In detail... Alain Durand wrote: > > I think that this effort is not ready for prime time. > > This document is creating a explosive cocktail made of: > > - policy: creation of a new authority to perform address assignment > outside of the regular channels That is a matter for IANA. I don't see why it is intrinsically dangerous, but IANA could perfectly well designate one of the existing RIRs, if that looked like a good idea. > - economy: imposition of a fixed one time fee model, preventing > competition Yes, that's a *good* thing. It also prevents commercial exploitation of this address space as a rental asset. That's a good thing too. > and creating a swamp of untraceable > registrations That is the reason for the escrow proposal. > - politics: dangerous instructions to IANA, see Geofff Houston comments I don't see where "dangerous" comes from, and I think the current draft responds to Geoff adequately. > - technology: half baked ideas that do not analyze seriously their > impact: > - what about reverse DNS? Suggestions? Is reverse DNS needed for these addresses? You're correct that this needs analysis. > - what about address selection rules? These addresses behave like global scope for that purpose. > - what about address leakage? These addresses are unique, so leakage is nothing like as harmful as with RFC 1918. They are also known to be unrouteable globally, so can be blackholed at domain boundaries. I thought that was discussed in the draft. > - how to debug those networks when they will leak? You don't need to. If you see one of these addresses out of its intended domain, you only need to drop it. I'm not saying this lightly - I really think this is not an issue. There is nothing to debug. You just don't care. > and it is impossible to map those prefixes back to their owner? Doesn't matter. You just drop them. > > All this is designed to address what is mostly a perception/social > problem which justification only resides in > a self serving companion document that fails to demonstrate that such > local addresses > are actually needed/required. I'm sorry, that is just wrong. It is far from a social problem and the Hain/Templin draft is far from self-serving. > In a rush to create something to replace the Site Local addresses, It isn't replacing site-local. It's filling a widely perceived need that has emerged (with our better understanding of the needs of enterprise and inter-enterprise networking) since site-local was invented. The rush, as I said at the top, is to prevent widespread misuse of PA prefixes and to give us a chance of preventing NAT6. If this doesn't get done soon, I think the emphasis will rapidly change to working with the RIRs to get a rough and ready policy in place for private use of PA space. > I'm afraid this document is playing the apprentice sorcerer and will > create more > long term damage than its author think. On the contrary, IMHO, *not* doing this will create long term damage. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 17:28:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11234 for ; Wed, 29 Oct 2003 17:28:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEynf-0003gl-DN for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 17:28:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TMSNF5014173 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 17:28:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEynf-0003gW-8B for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 17:28:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11137 for ; Wed, 29 Oct 2003 17:28:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEynd-0005MZ-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 17:28:21 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEync-0005MW-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 17:28:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEynK-0003Up-BT; Wed, 29 Oct 2003 17:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEymX-0003Sv-GP for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 17:27:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11068 for ; Wed, 29 Oct 2003 17:27:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEymV-0005Kj-00 for ipv6@ietf.org; Wed, 29 Oct 2003 17:27:11 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1AEymU-0005Jk-00 for ipv6@ietf.org; Wed, 29 Oct 2003 17:27:10 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 29 Oct 2003 14:26:40 -0800 Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 29 Oct 2003 14:26:40 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 29 Oct 2003 14:26:40 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 29 Oct 2003 14:27:32 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 29 Oct 2003 14:26:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Date: Wed, 29 Oct 2003 14:26:44 -0800 Message-ID: Thread-Topic: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] thread-index: AcOd6YKYjiwplFomRr2HN6ZoEubopgAWXJEgAAnSS8A= From: "Christian Huitema" To: "Michel Py" , "Tony Hain" Cc: X-OriginalArrivalTime: 29 Oct 2003 22:26:39.0123 (UTC) FILETIME=[B889BE30:01C39E6B] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > There is not any. Most p2p software relies on some kind of > (de)centralized infrastructure. Napster did, it was centralized, that's > how they shut it down. Even threedegrees does; even if you remove the > Teredo infrastructure there still is a centralized component: where is > the list of rooms kept? Threedegrees does not use a central service to maintain the list of user groups or musicmix sessions. The groups have unique names, basically large random numbers that are only known by the group members. The name space is managed by a distributed application, PNRP. You can get more information at www.microsoft.com/p2p. Threedegrees is however tied to MSN Messenger, which uses a central service to manage the presence application. > P2p apps still need a mechanism to locate each other. This is even more > important with IPv6 where random scans to find who is running the same > app are doomed to fail because of the 64-bit IID. In the case of PNRP, a node needs to find at least one member of the "cloud" in order to bootstrap. We use persistent caches and local multicast, which works in many cases, but we ultimately rely on a "seed server" to connect participants to the PNRP cloud. The seed server is used for initial contact, and does not hold actual data.=20 > What has changed since the Napster days is that rendezvous points are > now more distributed than they originally were. This has everything to > do with legal issues and nothing to do with technology. Nevertheless, > the best search results are still obtained when a few powerful machines > that can handle a large search table are available.=20 You are confusing discovery and naming. Doing discovery by trying a fuzzy search over a distributed system is quite hard. Doing a direct lookup, on the other hand, is relatively easy. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 18:15:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13887 for ; Wed, 29 Oct 2003 18:15:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEzX7-0007sK-QN for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 18:15:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TNFL2j030266 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 18:15:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEzX7-0007s5-Lj for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 18:15:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13822 for ; Wed, 29 Oct 2003 18:15:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEzX4-0006h4-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 18:15:18 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEzX4-0006h1-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 18:15:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEzWp-0007ls-Ux; Wed, 29 Oct 2003 18:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEzVu-0007j4-Ho for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 18:14:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13720 for ; Wed, 29 Oct 2003 18:13:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEzVr-0006dw-00 for ipv6@ietf.org; Wed, 29 Oct 2003 18:14:03 -0500 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1AEzVr-0006dD-00 for ipv6@ietf.org; Wed, 29 Oct 2003 18:14:03 -0500 Content-class: urn:content-classes:message Subject: RE: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Oct 2003 15:13:32 -0800 Message-ID: x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Thread-Index: AcOd6YKYjiwplFomRr2HN6ZoEubopgAWXJEgAAnSS8AAAUbyEA== From: "Michel Py" To: "Christian Huitema" Cc: Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Christian, > Christian Huitema wrote: > Threedegrees is however tied to MSN Messenger, > which uses a central service to manage the > presence application. For the sake of the argument, what would it take if you did not have MSN Messenger (short of re-creating a centralized service that pretty much implements the same functions)? I mean, the presence detection is somehow like a dynamic DNS mechanism: when the app comes up it registers with some kind of a centralized entity, even though that centralized entity might be distributed. > In the case of PNRP, a node needs to find at least one member > of the "cloud" in order to bootstrap. We use persistent caches > and local multicast, which works in many cases, but we > ultimately rely on a "seed server" to connect participants to > the PNRP cloud. The seed server is used for initial contact, > and does not hold actual data. So, the first time the app connects, or the apps that connects after being off-line for a while has reasonably good chances to need the seed server. > [snip] Thanks for the precisions. =20 Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 19:45:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17315 for ; Wed, 29 Oct 2003 19:45:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF0wL-0006xi-SQ for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 19:45:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9U0jTfq026756 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 19:45:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF0wL-0006xT-Mj for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 19:45:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17273 for ; Wed, 29 Oct 2003 19:45:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF0wJ-0001Ch-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 19:45:28 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AF0wJ-0001Cd-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 19:45:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF0vu-0006qw-Uz; Wed, 29 Oct 2003 19:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF0v5-0006ol-Ay for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 19:44:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17243 for ; Wed, 29 Oct 2003 19:44:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF0v3-00019A-00 for ipv6@ietf.org; Wed, 29 Oct 2003 19:44:09 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AF0v3-00018B-00 for ipv6@ietf.org; Wed, 29 Oct 2003 19:44:09 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RDYWJ>; Wed, 29 Oct 2003 19:43:25 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E44@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Juan Rodriguez Hervella'" Cc: ipv6@ietf.org Subject: RE: Issue 3: on link assumption considered harmful Date: Wed, 29 Oct 2003 19:43:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > > I quote yourself on a previous mail on this thread: > > "The problems of this assumption are discussed in section 3 > of Alain's draft. The draft suggests that this assumption > should be removed from ND specs. Here is the suggestion: > [snipped but it's read as..."remove" and "remove"...] > This seems like a reasonable suggestion, any objections?" > > As I've already said, I think that on-link communications might > be a useful thing to have. => Please specify a scenario that would not work if we remove this statement. The only one I know that wouuld not work is the one I mentioned earlier: one link, _no_ default router and different hosts are _manually_ configured with different prefixes. If you want that to work then configure the hosts with the same prefix. That way they all know that they're on the same link. If you know of something else that would break by removing this statement please describe it. Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 20:14:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18178 for ; Wed, 29 Oct 2003 20:14:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF1O9-0001MX-DL for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 20:14:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9U1EDFC005234 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 20:14:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF1O9-0001ML-7o for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 20:14:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18130 for ; Wed, 29 Oct 2003 20:14:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF1O7-0001oB-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 20:14:11 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AF1O6-0001o8-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 20:14:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF1Nx-0001FR-IQ; Wed, 29 Oct 2003 20:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF1NY-0001D3-Qn for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 20:13:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18088 for ; Wed, 29 Oct 2003 20:13:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF1NW-0001md-00 for ipv6@ietf.org; Wed, 29 Oct 2003 20:13:34 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AF1NS-0001ma-00 for ipv6@ietf.org; Wed, 29 Oct 2003 20:13:34 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9U1DUPh004736 for ; Wed, 29 Oct 2003 18:13:30 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HNJ00D2IQ2HUF@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Wed, 29 Oct 2003 18:13:30 -0700 (MST) Received: from sun.com ([129.146.11.181]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HNJ00JLNQ2HI4@mail.sun.net> for ipv6@ietf.org; Wed, 29 Oct 2003 18:13:29 -0700 (MST) Date: Wed, 29 Oct 2003 17:13:28 -0800 From: Alain Durand Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" To: Brian E Carpenter Cc: ipv6@ietf.org Message-id: <3FA065B8.3010003@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: <3F96659F.4040702@innovationslab.net> <3FA0351E.37C3F0CA@zurich.ibm.com> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Brian E Carpenter wrote: >Alain, > >Do you think it is better to let the RIRs develop a policy for >allocating PA space for local use, i.e. create a swamp like IPv4? > PA... Do you PI for Provider Independant? If it is the case, yes I think it would be less damaging to do that. See below. > >In detail.. > [Focusing on technology as I think that the other dicussions will simply not go anywhere in this forum] >>impact: >> - what about reverse DNS? >> >> > >Suggestions? Is reverse DNS needed for these addresses? You're correct that >this needs analysis. > A valid enough reason to get a -02 published. >> - what about address selection rules? >> >> > >These addresses behave like global scope for that purpose. > In terms of scope, you're right. Now take the multi-party communication example that was described by Erik earlier on, there is a problem. So you need to add an extra selection rule and an API to reverse that choice for the cases it does not make sense. Note: you cannot do that just by adding entries in the preference table, this table is global and you need a per-socket oprtion. >> - what about address leakage? >> >> > >These addresses are unique, so leakage is nothing like as harmful >as with RFC 1918. They are also known to be unrouteable globally, so >can be blackholed at domain boundaries. I thought that was discussed in >the draft. > > > >> - how to debug those networks when they will leak? >> >> > >You don't need to. If you see one of these addresses out of its intended >domain, you only need to drop it. I'm not saying this lightly - I really >think this is not an issue. There is nothing to debug. You just don't care. > > I disagree. You cannot say that. Examples: - you're under security attack from one of those addresses, you'd like to trace it back. Any tiny bit helps. - you're doing a complex merge of several local address spaces and things get ugly. You'd like to have a simple way (like whois) to know who those prefixes belongs to. >> and it is impossible to map those prefixes back to their owner? >> >> > >Doesn't matter. You just drop them. > No. see above. >>In a rush to create something to replace the Site Local addresses, >> >> > >It isn't replacing site-local. It's filling a widely perceived need that >has emerged (with our better understanding of the needs of enterprise and >inter-enterprise networking) since site-local was invented. > >The rush, as I >said at the top, is to prevent widespread misuse of PA prefixes and to give >us a chance of preventing NAT6. > >If this doesn't get done soon, I think the emphasis will rapidly change to >working with the RIRs to get a rough and ready policy in place for >private use of PA space. > The real requirement is to have addresses that are not bound to any provider, as this because renumbering will never be painless and multi-homing solution a la Multi6 will take years to be developped. So the question is what to do in the meantine. 3 alternatives: 1- Give a limited amount of PI to those who really want it and let them pay $$$ to get their ISP to route them 2- Create this 'local address' kludge that will stay for a long time 3- Speed up the work in Multi6. None of this comes for free, however my take is that the combination of 1 and 3 is much less expensive that 2. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 20:19:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18440 for ; Wed, 29 Oct 2003 20:19:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF1Sw-00027J-Rb for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 20:19:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9U1JAZJ008131 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 20:19:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF1Sw-000274-J2 for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 20:19:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18401 for ; Wed, 29 Oct 2003 20:19:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF1Su-0001vf-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 20:19:08 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AF1Su-0001vc-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 20:19:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF1Sn-0001xo-HF; Wed, 29 Oct 2003 20:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF1Rr-0001rE-Aj for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 20:18:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18359 for ; Wed, 29 Oct 2003 20:17:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF1Rp-0001tw-00 for ipv6@ietf.org; Wed, 29 Oct 2003 20:18:01 -0500 Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx with esmtp (Exim 4.12) id 1AF1Rn-0001tG-00 for ipv6@ietf.org; Wed, 29 Oct 2003 20:18:00 -0500 Received: from gih505.telstra.net (rsdhcp13.telstra.net [203.50.0.207]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h9U1HORc070733; Thu, 30 Oct 2003 12:17:29 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20031030113954.021cbf70@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 30 Oct 2003 12:17:12 +1100 To: Brian E Carpenter , ipv6@ietf.org From: Geoff Huston Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" In-Reply-To: <3FA0351E.37C3F0CA@zurich.ibm.com> References: <3F96659F.4040702@innovationslab.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Brian, In your note to Alain you pose the question: >Do you think it is better to let the RIRs develop a policy for >allocating PA space for local use, i.e. create a swamp like IPv4? It appears to me that you see this as being an either / or situation, where we accept the document as is or we defer to an RIR-lead process to undertake this form of address distribution. I do not agree with such an interpretation of the situation. My comments on the weakness of the document as being ready for prime time are based in part on over-specification of the proposed distribution function. The IPv6 working group wish to alter the IPv6 address architecture to define a unicast address block that is intended to be accessible for use in a particular context. For this purpose the document is an appropriate and necessary vehicle. The IPv6 working group wish to then set a price for consumers of this service and indicate that this price generates profits, and specify how such profits should be disbursed. My comments have been that this is not consistent with the role of the IETF, nor may it be possible for the IANA to implement, and I've suggested some modifications to the document that could address such concerns, based on removing such overly prescriptive sections of the draft. To answer you question posed to Alain, then, I'd offer the view that it is entirely possible that the RIRs are positioned to be able to fulfil the role of the central registry function within the base requirements of this particular draft, and to preclude such an option is imho, not an IETF role. You also note that "I think the current draft responds to Geoff adequately." I posted a note to this list (https://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg00456.html) indicating that I did not believe that this document was ready for Proposed Standard, and indicating where I saw deficiencies in the document, so I do not believe that this draft provides an adequate response to the concerns that I've raised, and my impressions of the document at this stage are largely similar to those of Alain. To attempt to be constructive here, I'd be happier with a document that was far less prescriptive about the precise nature of the distribution function, yet retained the description of the intended outcomes of the function, and instructed IANA to delegate this distribution function such that the intended outcomes are attained. regards, Geoff -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 20:39:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19315 for ; Wed, 29 Oct 2003 20:39:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF1mJ-0004zD-7H for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 20:39:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9U1dBW8019168 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 20:39:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF1mI-0004z5-On for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 20:39:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19282 for ; Wed, 29 Oct 2003 20:38:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF1mG-0002FV-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 20:39:08 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AF1mF-0002FS-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 20:39:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF1m9-0004tH-UZ; Wed, 29 Oct 2003 20:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF1m4-0004sL-Vo for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 20:38:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19267 for ; Wed, 29 Oct 2003 20:38:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF1m2-0002Et-00 for ipv6@ietf.org; Wed, 29 Oct 2003 20:38:54 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AF1m2-0002ET-00 for ipv6@ietf.org; Wed, 29 Oct 2003 20:38:54 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9U1cKQ07903; Wed, 29 Oct 2003 17:38:20 -0800 X-mProtect: <200310300138> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdSbqZw9; Wed, 29 Oct 2003 17:38:18 PST Message-ID: <3FA06CCD.40009@iprg.nokia.com> Date: Wed, 29 Oct 2003 17:43:41 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Templin CC: Jari Arkko , Erik Nordmark , ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: MTU handling References: <3F9E8AD5.3010703@kolumbus.fi> <3F9EC1AD.4010109@iprg.nokia.com> <3F9F4B15.7090100@kolumbus.fi> <3F9FFD7B.2080804@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I seem to have gotten my wires crossed and thought the I-D cutoff date was October 31st. No big deal; here are a couple of draft updates relating to this subject thread that I will be submitting when the I-D Registrar re-opens for business: http://www.geocities.com/osprey67/ndiscmtu-01.txt http://www.geocities.com/osprey67/tunnelmtu-02.txt Comments welcome, Fred Templin ftemplin@iprg.nokia.com Fred Templin wrote: > > > Jari Arkko wrote: > >> Fred Templin wrote: >> >>>> Yes. But somehow I'm worried about this, particularly when >>>> the MTU size field in ND is 32 bits. Is there any danger that >>>> a false claim of a large MTU size will lead to something >>>> bad happening? Or are we relying on the sender's hardware >>>> to not accept overly large packets for transmission? >>> >>> >>> >>> False claims can be mitigated by employing mechanisms to >>> authenticate ND messages, e.g., SEND. >> >> >> >> SEND can assure that RAs come from an authorized router, >> and that NAs come from the owner of an address. SEND may >> not be able to assure that the sender of an NA is trusted. >> That is, we know it comes from the node in question, but >> we may not be able to trust all the parameters it sends. >> In conclusion if the MTU info comes from a router, SEND >> is sufficient, but if its host to host, SEND may not be >> sufficient. > > > > Well, maybe we should only accept MTU negotiations from > routers then; at least that's better than nothing at all. > >> Anyway, I still think this danger is _mostly_ a non-issue -- >> your regular 10 Mbit/s ethernet hardware would hopefully decline to >> send a 2^32 byte probe packet and spend 3400 seconds sending >> it. However, there might be some special network technology >> where this might be an issue. Anyway, anything beyond 2^16 >> would require a jumbogram. > > > > Agree in terms of the danger being _mostly_ a non-issue. We can > use SEND to ensure that RAs indeed come from an authorized router > (thanks for clarifying this) so we don't run the danger of sending > too-large or too-small packets to final destinations for which the > authorized router serves as next-hop. > > In the case of host-to-host, the worst that can happen when SEND is > used is that the receiving host could misinform the sender of the MTU > size. Whether the bad size is too small or too large, in the long run it > is only the receiver itself (i.e., the sender of the bad MTU information) > that will suffer. > >>>> Also, if the IP header is 40 bytes/packet, one exchange >>>> of two 9k packets >>> >>> >>> >>> >>> >>> It is not an exchange of two 9K packets; it is a 9K probe >>> packet followed by a much smaller acknowledgement >>> packet - on the order of the size of a NA message. The >>> MTU/MRU probing is unidirectional. >>> >>>> consumes as much bandwidth as >>>> the overhead from 225 packets -- a 337 K transmission >>>> at 1500 byte MTU. So perhaps you wouldn't like to do this >>>> every time. >>> >>> >>> >>> I didn't quite catch this - can you re-phrase? >> >> >> >> I'm assuming the reason for choosing a larger MTU is to >> save in header overhead and processing time. But the savings >> in header overhead must be balanced against the cost of >> negotiating a larger MTU, particularly if that negotiation >> involves sending large probe packets. >> >> So, one 9K probe is about the same size as the overhead >> from extra 225 IPv6 headers. Using the standard 1500 byte >> MTU you get to send about 337 K before spending this much >> in overhead. That is, a 9K probe packet does not make sense >> bandwidth-wise if you are communicating less than 337 K >> with your peer. > > > > Sure; and it only gets worse for links with larger MTUs to probe. > > Well, that about wraps it for me - I guess we'll just go ahead and > use the data packets themselves as probes then. > > Fred > ftemplin@iprg.nokia.com > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Oct 29 21:33:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21152 for ; Wed, 29 Oct 2003 21:33:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF2ci-0001Qo-D9 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 21:33:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9U2XKdo005499 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 21:33:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF2ci-0001Qc-85 for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 21:33:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21113 for ; Wed, 29 Oct 2003 21:33:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF2cf-0002wO-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 21:33:17 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AF2cf-0002wL-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 21:33:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF2cQ-0001KH-6P; Wed, 29 Oct 2003 21:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF2bp-0001J5-Pc for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 21:32:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21084 for ; Wed, 29 Oct 2003 21:32:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF2bm-0002vg-00 for ipv6@ietf.org; Wed, 29 Oct 2003 21:32:23 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AF2bm-0002vN-00 for ipv6@ietf.org; Wed, 29 Oct 2003 21:32:22 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 29 Oct 2003 18:32:01 -0800 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 29 Oct 2003 18:31:52 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 29 Oct 2003 18:31:51 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 29 Oct 2003 18:31:36 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 29 Oct 2003 18:31:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Date: Wed, 29 Oct 2003 18:31:54 -0800 Message-ID: Thread-Topic: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] thread-index: AcOd6YKYjiwplFomRr2HN6ZoEubopgAWXJEgAAnSS8AAAUbyEAAHh+fQ From: "Christian Huitema" To: "Michel Py" Cc: X-OriginalArrivalTime: 30 Oct 2003 02:31:50.0694 (UTC) FILETIME=[F9515460:01C39E8D] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > For the sake of the argument, what would it take if you did not have MSN > Messenger (short of re-creating a centralized service that pretty much > implements the same functions)? I mean, the presence detection is > somehow like a dynamic DNS mechanism: when the app comes up it registers > with some kind of a centralized entity, even though that centralized > entity might be distributed. You can certainly do a distributed implementation of an IM+presence system. If I understand correctly, that is what more or less what Skype is doing. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 30 01:11:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27130 for ; Thu, 30 Oct 2003 01:11:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF61q-00078I-JU for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 01:11:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9U6BU3q027419 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 01:11:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF61q-00078A-9u for ipv6-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 01:11:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27097 for ; Thu, 30 Oct 2003 01:11:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF61n-0005ZI-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 01:11:27 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AF61m-0005ZF-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 01:11:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF61P-0006zL-DR; Thu, 30 Oct 2003 01:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF60R-0006rE-8a for ipv6@optimus.ietf.org; Thu, 30 Oct 2003 01:10:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27040 for ; Thu, 30 Oct 2003 01:09:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF60O-0005Y9-00 for ipv6@ietf.org; Thu, 30 Oct 2003 01:10:00 -0500 Received: from evrtwa1-ar8-4-40-179-036.evrtwa1.dsl-verizon.net ([4.40.179.36] helo=tndh.net) by ietf-mx with esmtp (Exim 4.12) id 1AF60N-0005Y4-00 for ipv6@ietf.org; Thu, 30 Oct 2003 01:09:59 -0500 Received: from eaglet (127.0.0.1:3054) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Wed, 29 Oct 2003 22:09:59 -0800 From: "Tony Hain" To: "Pekka Savola" Cc: , Subject: RE: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Date: Wed, 29 Oct 2003 22:09:54 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola wrote: > > It is not a problem if you follow addr selection rules and prefer > > matching scopes. This will cause IPv4 to be used if there is only a LL, > > trying to talk to a AAAA global. > > Uhh, I don't think Default Address Selection helps at all here. The > question is NOT how you prefer the addresses after you've queried them, > it's whether you query them *at all*. > > I.e., the point of the AI_ADDRCONFIG as it seems to me is to avoid an > unnecessary query of IPv6 addresses in the first place. > > For example, the app wants to look up www.example.com. Prior to making > that lookup, it must know which addresses are configured on the node if > AI_ADDRCONFIG is used. It doesn't know about scopes of www.example.com at > this point. > > If there are no IPv6 addresses (including link-locals) configured, it'll > query only A records and then perform default address selection as you > say, naturally ending up with IPv4 as there are no alternatives. > > If there are IPv6 addresses (including link-locals), it'll query both A > and AAAA records and perform default address selection, probably also > resulting in IPv4 if no global IPv6 addresses were configured. So you want to standardize an implementation & optimization issue ... This is an optimization that you may want to use in any implementation you do, but it is not an issue we need to standardize. In particular, it precludes use of IPv6 if a local network has a name service intelligent enough to provide LL information to the right place. Please stop assuming that the world will not evolve beyond where we are, and trying to prevent it from doing so. Yes we do not want LL addresses to show up in the global name space, and the current DNS is too lame to prevent that, but that is no reason to specify that nobody can ever use it. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 30 01:26:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27787 for ; Thu, 30 Oct 2003 01:26:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF6G4-0001Bh-CM for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 01:26:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9U6QCWm004565 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 01:26:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF6G4-0001BY-74 for ipv6-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 01:26:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27737 for ; Thu, 30 Oct 2003 01:26:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF6G1-0005pJ-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 01:26:09 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AF6G0-0005pG-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 01:26:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF6Fv-00015f-Be; Thu, 30 Oct 2003 01:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF6Fa-00013f-12 for ipv6@optimus.ietf.org; Thu, 30 Oct 2003 01:25:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27719 for ; Thu, 30 Oct 2003 01:25:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF6FW-0005or-00 for ipv6@ietf.org; Thu, 30 Oct 2003 01:25:38 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF6FW-0005o8-00 for ipv6@ietf.org; Thu, 30 Oct 2003 01:25:38 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9U6P2611169; Thu, 30 Oct 2003 08:25:02 +0200 Date: Thu, 30 Oct 2003 08:25:01 +0200 (EET) From: Pekka Savola To: Tony Hain cc: v6ops@ops.ietf.org, Subject: RE: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Wed, 29 Oct 2003, Tony Hain wrote: > So you want to standardize an implementation & optimization issue ... This > is an optimization that you may want to use in any implementation you do, > but it is not an issue we need to standardize. Did you notice that the APIs are Informational documents? :-) The key point here is raise the awareness of implementors by first discussiing, then writing a draft, and last publishing it. Whether it says "do this, ignore that" or "you might want to do this, but be aware of foo" is pretty irrelevant to me. > In particular, it precludes > use of IPv6 if a local network has a name service intelligent enough to > provide LL information to the right place. Right, there are tradeoffs here. Unless there is concensus about that this is a generally desirable thing, one way forward could be publishing a tradeoffs document which would just bring up both sides of the argument, why you would or would not want to do it, and let the implementor decide what they feel is more important for them. > Please stop assuming that the > world will not evolve beyond where we are, and trying to prevent it from > doing so. I'm not sure if I'd classify the widespread use of link-local addresses as "evolving".. > Yes we do not want LL addresses to show up in the global name > space, and the current DNS is too lame to prevent that, but that is no > reason to specify that nobody can ever use it. My personal point is that LL addresses are highly problematic for apps, because they'll have to then (at least) parse the zone identifier as well, because e.g. if you are a host and have one physical interface and one tunnel interface, you cannot use link local addresses without additional disambiguation. The only way to ensure that link-locals work seems to be restricting them to the special applications which know how to deal with them. But it's no use trying to debate this argument over here. If sufficiently many folks think link-locals are a good thing, then we'd probably need a tradeoffs document instead of a recommendation/specification document. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 30 05:21:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16120 for ; Thu, 30 Oct 2003 05:21:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF9vn-00019q-8y for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 05:21:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UALVfl004446 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 05:21:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF9vm-00019b-Fx for ipv6-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 05:21:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16080 for ; Thu, 30 Oct 2003 05:21:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF9vj-0000mr-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 05:21:27 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AF9vi-0000mo-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 05:21:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF9vL-00011s-NY; Thu, 30 Oct 2003 05:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF9uU-0000uD-TF for ipv6@optimus.ietf.org; Thu, 30 Oct 2003 05:20:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16056 for ; Thu, 30 Oct 2003 05:19:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF9uR-0000mD-00 for ipv6@ietf.org; Thu, 30 Oct 2003 05:20:07 -0500 Received: from smtp02.uc3m.es ([163.117.136.122] helo=smtp.uc3m.es) by ietf-mx with esmtp (Exim 4.12) id 1AF9uQ-0000lv-00 for ipv6@ietf.org; Thu, 30 Oct 2003 05:20:06 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 3C19A431F0; Thu, 30 Oct 2003 11:19:37 +0100 (CET) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp02.uc3m.es (Postfix) with ESMTP id 262349A02A; Thu, 30 Oct 2003 11:19:36 +0100 (CET) From: Juan Rodriguez Hervella Organization: UC3M To: Pekka Savola Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Date: Thu, 30 Oct 2003 11:19:33 +0100 User-Agent: KMail/1.5.4 Cc: itojun@iijlab.net, , References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310301119.34023.jrh@it.uc3m.es> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wednesday 29 October 2003 21:36, Pekka Savola wrote: > On Wed, 29 Oct 2003, Juan Rodriguez Hervella wrote: > > I just say that this option is not *very* useful, having > > into account the problems that it has with link-local > > addresses and so on... if you fix these problems, it's > > a matter of choice, if you want to use it, just do it. > > Which problems are you referring to? I still don't understand :-( I'm talking about the problems you've found out. 1. The problem that this option is not useful if we allow to make AAAA queries using link-local addresses. 2. The problem with the on-link assuption. 3. The problem that we are defining something that applications don't really need to have. Although I accept that it might be useulf sometimes, so this isn't a drawback. 4. The problem that if we keep the option as a flag, already deployed applications won't use it. If we fix those, I will be happy with this option. If we can not fix them, this options shouldn't be defined. > > > > If I understood Stig well, he said that people was > > > > turning off IPv6 because of delaying issues. Doing that is not an > > > > option if you want to allow your app. to run over "IPv6 AND IPv4". If > > > > you can not cope with such delays, maybe you shouldn't be using the > > > > DNS at all. > > > > > > Then what? Distributed hosts file? ;-) ? > > > > ^--^ ...(after a while)... pouting (grrrr). > > > > Then what ? it's not my problem, > > Sorry for my remark, I just could not resist. What you seemed to suggest > was, "don't use DNS" without giving any reasonable alternative. That > isn't really productive either :-) That wasn't my purpose. I wanted to show that the process of initiating a connection is not as fast as turning on the telly. We have to have in mind that this flag only minimize the worst case of this process, that's all in my opinion. > > I haven't switched to IPv4 because > > the IPv6 resolver took a couple of extra roundtrip times. > > The extra roundtrip times are just the tip of the iceberg. Consider > broken DNS servers, load balancers etc. out there -- which may eat your > AAAA query for e.g. 10 seconds, causing a lot more delay than a couple of > roundtrips. That's ok, my concern is that you want to fix the issues this flag has killing the on-link assuption. That's not very constructive either. > > I see another way of fixing: > > > > If this option is problematic, don't use it. This has been proved to > > work, as a lot of applications don't use it already. > > As for AI_ADDRCONFIG, it's maybe not used because it hasn't really been > implemented that much, maybe because it has been specified in a rather > useless way (and it requires a proprietary interface between the glibc and > kernel to get the addresses, such as the getaddrinfo destination address > ordering as well; dst addr ordering hasn't been implemented that much > either).. > > > You will have to give me other arguments to kill the on-link assuption. > > Let's keep that subject to a separate thread, (the next message). Good idea. ^--^ -- JFRH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 30 06:05:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17571 for ; Thu, 30 Oct 2003 06:05:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFAc6-0005xq-GQ for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 06:05:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UB5Eot022920 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 06:05:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFAc6-0005xX-Aq for ipv6-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 06:05:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17544 for ; Thu, 30 Oct 2003 06:05:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFAc2-0001QK-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 06:05:10 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFAc1-0001Q9-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 06:05:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFAbv-0005rc-GR; Thu, 30 Oct 2003 06:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFAbp-0005qt-3S for ipv6@optimus.ietf.org; Thu, 30 Oct 2003 06:04:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17537 for ; Thu, 30 Oct 2003 06:04:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFAbl-0001Q6-00 for ipv6@ietf.org; Thu, 30 Oct 2003 06:04:53 -0500 Received: from smtp01.uc3m.es ([163.117.136.121] helo=smtp.uc3m.es) by ietf-mx with esmtp (Exim 4.12) id 1AFAbk-0001Pt-00 for ipv6@ietf.org; Thu, 30 Oct 2003 06:04:52 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id F21EB43270; Thu, 30 Oct 2003 12:04:23 +0100 (CET) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp01.uc3m.es (Postfix) with ESMTP id C1C8299F2F; Thu, 30 Oct 2003 12:04:17 +0100 (CET) From: Juan Rodriguez Hervella Organization: UC3M To: Pekka Savola Subject: Re: Issue 3: on link assumption considered harmful Date: Thu, 30 Oct 2003 12:04:14 +0100 User-Agent: KMail/1.5.4 Cc: Soliman Hesham , , , References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310301204.15655.jrh@it.uc3m.es> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wednesday 29 October 2003 22:03, Pekka Savola wrote: > Hi, > > Combining this, and the comment from the AI_ADDRCONFIG thread, and adding > v6ops in the Cc:.. > > On Wed, 29 Oct 2003, Juan Rodriguez Hervella wrote: > [...] > > > You will have to give me other arguments to kill the on-link assuption. > > You seem to have some scenarios in mind where you think these are useful. > Please elaborate. > > Remember that the removing the on-link assumption mostly helps in > deployments where there is no IPv6 connectivity at all.. i.e., you're > probably not experiencing these personally :-). But those are very > probably nasty for folks who might have dual-stack on by default, but > without connectivity. Ok I understand that. > More inline.. > > On Wed, 29 Oct 2003, Juan Rodriguez Hervella wrote: > > "The problems of this assumption are discussed in section 3 > > of Alain's draft. The draft suggests that this assumption > > should be removed from ND specs. Here is the suggestion: > > [snipped but it's read as..."remove" and "remove"...] > > This seems like a reasonable suggestion, any objections?" > > > > As I've already said, I think that on-link communications might > > be a useful thing to have. > > You realize, of course, that the document does not try to restrict on-link > communications at all? Yes I do. > It just recommends that if you don't have a default route, don't assume > everybody in the Internet is reachable on-link. This seems rather > reasonable in almost all cases, because you generally *can't* expect > anything like that. You expect that the prefixes you have the addresses > from are on-link (which continue to work without any problems), and that's > it :-) > > > > - impacts on address selection (section 3.1) > > > > So let's go to fix address selection instead of removing > > a nice feature. > > Again, do you have scenarios in mind where this feature would be useful? Uhmmm let me think for a while, ok ? :-) > The document doesn't (yet :-) tease out the different problems as well as > it could, but this isn't just a thing that can be fixed by a simple > default address selection modification. > > For example, if your first-hop router crashes *), but you still have a > global IPv6 address, and you perform a DNS lookup over IPv4, and get A and > AAAA responses back from the DNS, the on-link assumption would make you > try to perform a TCP connect() using the IPv6 address. Obviously, this > will cause long timeouts until the router comes back up and replaces the > default route. For example, your fridge wants to talk with the scheduler to ask for more food. The oven, which is sending RAs, is turned off. This will cause no communication at all. I prefer 3 seconds of delay. I'm the auto-communication kind of man. I don't intend to make you laugh but I think I will have to get some information about the zero-conf WG's jobs before going on this discussion, because I thought that this feature was a GOOD THING. > The more obvious problem you may not be seeing is when an implementation > has enabled dual-stack but does not have IPv6 connectivity at all (i.e., > only the link-local addresses). This is the common case nowadays. When I connect to Internet at home with my dial up provider, I've got IPv4 and also a link-local address and I've never experienced any problem at all. > However, due to the onlink assumption, it > tries to reach every IPv6 destination directly on its interfaces. I fail > to see any justification for this. Such addresses need not come through > default address selection. Absolutely agreed. > > The clearer issue with default address selection (really, destination > address selection, which isn't really implemented that much yet!) is when > the the scopes are mismatching. > > The fix should probably be applied in both, the default address selection > (by clarifying what "avoid unusable destinations" should entail) and > RFC2461bis, but the latter is more timely and more important. -- JFRH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 30 06:25:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17994 for ; Thu, 30 Oct 2003 06:25:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFAva-0007qz-69 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 06:25:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UBPMMv030188 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 06:25:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFAvZ-0007qp-V4 for ipv6-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 06:25:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17966 for ; Thu, 30 Oct 2003 06:25:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFAvV-0001cN-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 06:25:18 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFAvV-0001cI-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 06:25:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFAvH-0007du-B0; Thu, 30 Oct 2003 06:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFAua-0007cB-9l for ipv6@optimus.ietf.org; Thu, 30 Oct 2003 06:24:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17952 for ; Thu, 30 Oct 2003 06:24:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFAuW-0001bp-00 for ipv6@ietf.org; Thu, 30 Oct 2003 06:24:16 -0500 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx with esmtp (Exim 4.12) id 1AFAuV-0001bF-00 for ipv6@ietf.org; Thu, 30 Oct 2003 06:24:15 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5AEC2330; Thu, 30 Oct 2003 12:23:46 +0100 (CET) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp03.uc3m.es (Postfix) with ESMTP id 44D5B32F; Thu, 30 Oct 2003 12:23:46 +0100 (CET) From: Juan Rodriguez Hervella Organization: UC3M To: Pekka Savola Subject: Re: Issue 3: on link assumption considered harmful Date: Thu, 30 Oct 2003 12:23:43 +0100 User-Agent: KMail/1.5.4 Cc: Soliman Hesham , , , References: <200310301204.15655.jrh@it.uc3m.es> In-Reply-To: <200310301204.15655.jrh@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310301223.44112.jrh@it.uc3m.es> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday 30 October 2003 12:04, Juan Rodriguez Hervella wrote: > On Wednesday 29 October 2003 22:03, Pekka Savola wrote: > > For example, if your first-hop router crashes *), but you still have a > > global IPv6 address, and you perform a DNS lookup over IPv4, and get A > > and AAAA responses back from the DNS, the on-link assumption would make > > you try to perform a TCP connect() using the IPv6 address. Obviously, > > this will cause long timeouts until the router comes back up and replaces > > the default route. > > For example, your fridge wants to talk with the scheduler to ask for more > food. The oven, which is sending RAs, is turned off. > This will cause no communication at all. > I prefer 3 seconds of delay. I'm the auto-communication kind of man. Ooops, forget the oven :-), just think as if the fridge was shipped with an Ipv6 address prefix and the scheduler was shipped with another IPv6 prefix :) -- JFRH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 30 06:35:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18267 for ; Thu, 30 Oct 2003 06:35:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFB57-0000XR-IK for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 06:35:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UBZDtT002063 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 06:35:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFB57-0000XC-CT for ipv6-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 06:35:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18214 for ; Thu, 30 Oct 2003 06:35:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFB53-0001j5-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 06:35:09 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFB52-0001j2-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 06:35:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFB4y-0000OB-DA; Thu, 30 Oct 2003 06:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFB4J-0000M8-PQ for ipv6@optimus.ietf.org; Thu, 30 Oct 2003 06:34:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18205 for ; Thu, 30 Oct 2003 06:34:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFB4F-0001if-00 for ipv6@ietf.org; Thu, 30 Oct 2003 06:34:19 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AFB4E-0001iD-00 for ipv6@ietf.org; Thu, 30 Oct 2003 06:34:19 -0500 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h9UBXnV14272 for ; Thu, 30 Oct 2003 03:33:49 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h9UBahtX009943 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 30 Oct 2003 03:36:46 -0800 Message-ID: <3FA0F6DF.60806@innovationslab.net> Date: Thu, 30 Oct 2003 06:32:47 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Scribes Needed Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, This is a call for volunteer scribes. The chairs would like to have at least two independent minute takers for each of the IPv6 WG sessions in Minneapolis. If you are willing, please indicate to the chairs your willingness to help and which sessions you can help. Thanks, Brian & Bob IPv6 WG Chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 30 06:54:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18849 for ; Thu, 30 Oct 2003 06:54:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFBNT-0002hl-OE for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 06:54:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UBsB1L010395 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 06:54:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFBNT-0002hZ-Ew for ipv6-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 06:54:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18811 for ; Thu, 30 Oct 2003 06:53:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFBNP-0001wr-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 06:54:07 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFBNO-0001wo-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 06:54:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFBNJ-0002bh-UB; Thu, 30 Oct 2003 06:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFBNE-0002bN-2C for ipv6@optimus.ietf.org; Thu, 30 Oct 2003 06:53:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18803 for ; Thu, 30 Oct 2003 06:53:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFBN9-0001wf-00 for ipv6@ietf.org; Thu, 30 Oct 2003 06:53:51 -0500 Received: from smtp01.uc3m.es ([163.117.136.121] helo=smtp.uc3m.es) by ietf-mx with esmtp (Exim 4.12) id 1AFBN9-0001wI-00 for ipv6@ietf.org; Thu, 30 Oct 2003 06:53:51 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 3A9C043232; Thu, 30 Oct 2003 12:53:22 +0100 (CET) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp01.uc3m.es (Postfix) with ESMTP id 2237F99F28; Thu, 30 Oct 2003 12:53:22 +0100 (CET) From: Juan Rodriguez Hervella Organization: UC3M To: Soliman Hesham Subject: Re: Issue 3: on link assumption considered harmful Date: Thu, 30 Oct 2003 12:53:17 +0100 User-Agent: KMail/1.5.4 Cc: ipv6@ietf.org References: <748C6D0A58C0F94CA63C198B6674697A01922E44@ftmail.lab.flarion.com> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922E44@ftmail.lab.flarion.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310301253.19923.jrh@it.uc3m.es> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday 30 October 2003 01:43, Soliman Hesham wrote: > > I quote yourself on a previous mail on this thread: > > > > "The problems of this assumption are discussed in section 3 > > of Alain's draft. The draft suggests that this assumption > > should be removed from ND specs. Here is the suggestion: > > [snipped but it's read as..."remove" and "remove"...] > > This seems like a reasonable suggestion, any objections?" > > > > As I've already said, I think that on-link communications might > > be a useful thing to have. > > => Please specify a scenario that would not work > if we remove this statement. > > The only one I know that wouuld not work is the one > I mentioned earlier: one link, _no_ default router > and different hosts are _manually_ configured with different > prefixes. If you want that to work then configure > the hosts with the same prefix. That way they all > know that they're on the same link. If you know > of something else that would break by removing this > statement please describe it. AFAIK, nothing else would break (fortunately). I've already got an scenario, which is what you are trying to break. Isn't that enough ? Of course I can configure _manually_ the hosts , as well as configuring the IP address and the default route (oops...why do people use DHCP ?) IMO (and I'm not humble), I see that: "Impact on destination address selection" and "Address resolution delays." Are issues that could be fixed in other ways. I will write a draft about how to solve these 2 issues without killing the on-link assuption (somethig like "draft-....-counter-onlinkassumption-00.txt"), though I can not tell you when it will be ready. Besides, if you know more issues, I will be glad to hear about them. Regards. -- JFRH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 30 07:11:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19279 for ; Thu, 30 Oct 2003 07:11:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFBe9-0004cS-6W for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 07:11:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UCBPNP017750 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 07:11:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFBe8-0004cD-Tt for ipv6-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 07:11:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19230 for ; Thu, 30 Oct 2003 07:11:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFBe4-00029S-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 07:11:20 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFBe4-00029P-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 07:11:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFBdn-0004QY-FF; Thu, 30 Oct 2003 07:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFBdN-0004Is-33 for ipv6@optimus.ietf.org; Thu, 30 Oct 2003 07:10:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19202 for ; Thu, 30 Oct 2003 07:10:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFBdI-00028r-00 for ipv6@ietf.org; Thu, 30 Oct 2003 07:10:32 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AFBdI-00028S-00 for ipv6@ietf.org; Thu, 30 Oct 2003 07:10:32 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RDZXC>; Thu, 30 Oct 2003 07:10:02 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E47@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Juan Rodriguez Hervella'" Cc: ipv6@ietf.org Subject: RE: Issue 3: on link assumption considered harmful Date: Thu, 30 Oct 2003 07:09:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > AFAIK, nothing else would break (fortunately). > > I've already got an scenario, which is what you are > trying to break. Isn't that enough ? > > Of course I can configure _manually_ the hosts , > as well as configuring the IP address and the default route > (oops...why do people use DHCP ?) => I'm afraid you missed the point by a fair distance. If you use DHCP (when there is no default router) you could get the same prefix for the whole link and everything will work fine with normal next hop determination as is and after removing this assumption. The only issue is when you don't use the same prefix in all hosts on the link. This will NOT happen if: - you manually configure the same prefix on all hosts - you dynamically configure the same prefix on all hosts Given the above, I don't understand what you're objecting to... Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 30 07:54:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20370 for ; Thu, 30 Oct 2003 07:54:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFCJj-0000t2-KK for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 07:54:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UCsN63003402 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 07:54:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFCJj-0000sn-D1 for ipv6-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 07:54:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20334 for ; Thu, 30 Oct 2003 07:54:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFCJi-0002gB-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 07:54:22 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFCJi-0002g8-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 07:54:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFCJO-0000m2-FA; Thu, 30 Oct 2003 07:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFCId-0000iR-6s for ipv6@optimus.ietf.org; Thu, 30 Oct 2003 07:53:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20309 for ; Thu, 30 Oct 2003 07:53:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFCIc-0002fI-00 for ipv6@ietf.org; Thu, 30 Oct 2003 07:53:14 -0500 Received: from 177.cust14.nsw.dsl.ozemail.com.au ([203.102.109.177] helo=nosense.org) by ietf-mx with esmtp (Exim 4.12) id 1AFCIb-0002em-00 for ipv6@ietf.org; Thu, 30 Oct 2003 07:53:13 -0500 Received: from Dupy2.nosense.org (177.cust14.nsw.dsl.ozemail.com.au [203.102.109.177]) by nosense.org (Postfix) with SMTP id 586F93F017 for ; Thu, 30 Oct 2003 23:23:43 +1030 (CST) Date: Thu, 30 Oct 2003 23:23:42 +1030 From: Mark Smith To: ipv6@ietf.org Subject: Packetization Layer Path MTU Discovery (was Re: "RFC 2461bis" issue: MTU handling) Message-Id: <20031030232342.2490f458.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> In-Reply-To: References: <3F9E8AD5.3010703@kolumbus.fi> Organization: The No Sense Organisation X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi All, Came across this when looking at some other MTU related info. http://www.psc.edu/~mathis/MTU/#pmtud There is an ID at http://www.psc.edu/~mathis/MTU/draft-mathis-plpmtud-00.txt The BoF slides are at http://www.psc.edu/~mathis/papers/mtuBOF200303/index.html Hope this helps, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 30 11:28:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29402 for ; Thu, 30 Oct 2003 11:28:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFFeO-00005c-7Q for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 11:27:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UGRuF7000343 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 11:27:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFFeO-00005S-3g for ipv6-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 11:27:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29371 for ; Thu, 30 Oct 2003 11:27:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFFeN-0005vD-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 11:27:55 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFFeM-0005v9-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 11:27:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFFdV-0008Le-R3; Thu, 30 Oct 2003 11:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFFcm-0008I0-Fb for ipv6@optimus.ietf.org; Thu, 30 Oct 2003 11:26:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29325 for ; Thu, 30 Oct 2003 11:26:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFFcl-0005tw-00 for ipv6@ietf.org; Thu, 30 Oct 2003 11:26:15 -0500 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by ietf-mx with esmtp (Exim 4.12) id 1AFFck-0005ts-00 for ipv6@ietf.org; Thu, 30 Oct 2003 11:26:14 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 5998911212 for ; Thu, 30 Oct 2003 11:26:07 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 30 Oct 2003 11:26:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: INFO: FW: Implementation vs. the Standard Date: Thu, 30 Oct 2003 11:26:05 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05122358@tayexc13.americas.cpqcorp.net> Thread-Topic: INFO: FW: Implementation vs. the Standard Thread-Index: AcOersiV4+nm+4lvQYeqFbI6EhJlwwAUNIlwAACxTCA= From: "Bound, Jim" To: X-OriginalArrivalTime: 30 Oct 2003 16:26:06.0046 (UTC) FILETIME=[84A1E7E0:01C39F02] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable DO NOT RESPOND TO THIS MAIL OK. go-to-v6ops.c :--) /jim -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Bound, Jim Sent: Thursday, October 30, 2003 11:19 AM To: Pekka Savola; Tony Hain Cc: v6ops@ops.ietf.org Subject: Implementation vs. the Standard It is important for us to separate implementation choice vs. the standard. The onlink and v6bydefault discussions are mostly a focus on if you do this with IPv6 and don't think about this other aspect you can hurt yourself. A discussion of whether a standard is useful for networking is a different discussion. Then there is the importance that a standard does not create an interoperability problem. The API issues are not errors but could be operational issues. Also the Base API is Informational, and is standardized by the IEEE not the IETF as a note to all. At this point we don't even own that spec anymore. That spec is done and completed if we want additions it will have to go through IEEE process too not just IETF process. =20 There is nothing wrong with documenting issues for implementers in an RFC and that work should be encouraged. In that context I agree with Pekka S. But, for the IETF to tell vendors how they ship their products for customers is simply inappropriate and vendors will not listen to the IETF, hence this is not a good use of our precious mail time. In that sense I agree with Tony 100%. Discussion of operational issues with our standards and how they work with implementation is a good discussion. But should not be a priority over the standards work we need to deliver as a working group. So in addition to the recent and good request from Chairs and ADs to try to hold back on email and think about the response and hit reply for ones hot button (and at times it must be done for continuity and defense) I would also add that topics which are standards we are working on that are needed and on standards track receive priority mail discussion. The Standards Track discussions are the ones that may help improve time-to-market for the IETF to deliver their product/solutions which are networking standards and the point of this body and forum. This mail is not to tell anyone to do anything or stop doing anything but a note and my .50 cents. I also took IPv6 WG off this mail as I don't want to get mail twice again. I will send to IPv6 WG as courteous that I did this but I feel this is mostly a v6ops discussion at this point in time. Sincerely, /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 30 11:40:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29941 for ; Thu, 30 Oct 2003 11:40:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFFqM-0001mW-Oe for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 11:40:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UGeIMB006841 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 11:40:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFFqM-0001mG-5z for ipv6-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 11:40:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29901 for ; Thu, 30 Oct 2003 11:40:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFFqL-000666-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 11:40:17 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFFqK-000663-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 11:40:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFFq8-0001ev-Pn; Thu, 30 Oct 2003 11:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFFpa-0001cG-OW for ipv6@optimus.ietf.org; Thu, 30 Oct 2003 11:39:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29841 for ; Thu, 30 Oct 2003 11:39:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFFpZ-00065e-00 for ipv6@ietf.org; Thu, 30 Oct 2003 11:39:29 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AFFpY-00065b-00 for ipv6@ietf.org; Thu, 30 Oct 2003 11:39:29 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9UGdM5u021191; Thu, 30 Oct 2003 09:39:23 -0700 (MST) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9UGdLIr014829; Thu, 30 Oct 2003 11:39:21 -0500 (EST) Received: from strat (localhost [127.0.0.1]) by strat.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h9UGdLid020712; Thu, 30 Oct 2003 11:39:21 -0500 (EST) Message-Id: <200310301639.h9UGdLid020712@strat.East.Sun.COM> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Juan Rodriguez Hervella cc: Pekka Savola , Soliman Hesham , itojun@itojun.org, ipv6@ietf.org, v6ops@ops.ietf.org From: Sebastien Roy Subject: Re: Issue 3: on link assumption considered harmful In-Reply-To: Message from Juan Rodriguez Hervella of "Thu, 30 Oct 2003 12:04:14 +0100." <200310301204.15655.jrh@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Oct 2003 11:39:21 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , jrh@it.uc3m.es said: > For example, your fridge wants to talk with the scheduler to ask for > more food. The oven, which is sending RAs, is turned off. This will > cause no communication at all. I prefer 3 seconds of delay. I'm the > auto-communication kind of man. I don't see how you reached the conclusion that the removal of the on-link assumption would cause lack of communication in your example. If you're depending on a fall-back to IPv4 (and I assume you are since you mentioned a 3 second delay), then communication will occur more quickly without the on-link assumption... Can you explain your reasoning? Your example is not well defined. Are the fridge and the scheduler on the same link or not? Do they have manually configured IPv6 addresses or statelessly autoconfigured addresses? Do they have IPv4 addresses? Is the oven both the IPv6 and IPv4 router? > > I don't intend to make you laugh but I think I will have to get some > information about the zero-conf WG's jobs before going on this > discussion, because I thought that this feature was a GOOD THING. The zeroconf requirements don't include the on-link assumption. They also don't include nodes residing on the same link, but it's not clear if the example you gave depends on that or not. > > The more obvious problem you may not be seeing is when an implementation > > has enabled dual-stack but does not have IPv6 connectivity at all (i.e., > > only the link-local addresses). > > This is the common case nowadays. When I connect to Internet at home with > my dial up provider, I've got IPv4 and also a link-local address and I've > never experienced any problem at all. Your experience is anecdotal. There may be two reasons for your not experiencing problems. 1. In general, do you attempt to communicate with nodes whose names resolve to both IPv4 and IPv6 addresses? Maybe not. 2. Some OS's never implemented the on-link assumption to begin with, maybe yours is one of them. -Seb -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 30 12:17:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01330 for ; Thu, 30 Oct 2003 12:17:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGQH-0006QB-KA for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 12:17:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UHHPqA024677 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 12:17:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGQH-0006Pw-AQ for ipv6-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 12:17:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01305 for ; Thu, 30 Oct 2003 12:17:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFGQF-0006dx-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 12:17:24 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFGQF-0006du-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 12:17:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGPu-0006IB-1S; Thu, 30 Oct 2003 12:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGPg-0006DD-3u for ipv6@optimus.ietf.org; Thu, 30 Oct 2003 12:16:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01277 for ; Thu, 30 Oct 2003 12:16:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFGPe-0006da-00 for ipv6@ietf.org; Thu, 30 Oct 2003 12:16:46 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFGPd-0006dQ-00 for ipv6@ietf.org; Thu, 30 Oct 2003 12:16:45 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9UHFsq20758; Thu, 30 Oct 2003 19:15:54 +0200 Date: Thu, 30 Oct 2003 19:15:53 +0200 (EET) From: Pekka Savola To: Juan Rodriguez Hervella cc: Soliman Hesham , , , Subject: Re: Issue 3: on link assumption considered harmful In-Reply-To: <200310301223.44112.jrh@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Thu, 30 Oct 2003, Juan Rodriguez Hervella wrote: [...] > Ooops, forget the oven :-), just think as if the fridge was shipped > with an Ipv6 address prefix and the scheduler was shipped with > another IPv6 prefix :) The whole point of IPv6 (and also IP) is that machines aren't shipped with invented addresses, and you're supposed to make them automatically communicate. Or, in the case of IPv6, the invented address is their link-local address and they can autoconfigure another address. All of these are from the same prefix between all the nodes on a link. This is just so incredibly bad idea it doesn't even bear thinking about. But if one want to enable it manually, you can always point a default route in your Ethernet interface. More on the related subject from: Embedding Globally Routable Internet Addresses Considered Harmful draft-plonka-embed-addr-00 Abstract Vendors of consumer electronics and network gear have produced and sold hundreds of thousands of Internet hosts with globally routable Internet Protocol addresses embedded within their products' firmware. These products are now in operation world-wide and primarily include, but are not necessarily limited to, low-cost routers and middleboxes for personal or residential use. This "hard-coding" of globally routable IP addresses within the host's firmware presents significant problems to the operation of the Internet and to the management of its address space. This document means to clarify best current practices in the Internet community. It denouces the practice of embedding references to unique, globally routable IP addresses in Internet hosts, describes some of the resulting problems, and considers selected alternatives. It is also intended to remind the Internet community of the ephemeral nature of unique, globally routable IP addresses and that the assignment and use of such addresses is temporary and therefore should not be used in fixed configurations. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 30 12:36:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02098 for ; Thu, 30 Oct 2003 12:36:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGhw-0000GN-LZ for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 12:35:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UHZefv001005 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 12:35:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGhw-0000G8-Fq for ipv6-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 12:35:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02030 for ; Thu, 30 Oct 2003 12:35:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFGhu-0006uU-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 12:35:38 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFGhu-0006uR-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 12:35:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGhL-00006R-78; Thu, 30 Oct 2003 12:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGgr-0008Uz-7C for ipv6@optimus.ietf.org; Thu, 30 Oct 2003 12:34:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02013 for ; Thu, 30 Oct 2003 12:34:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFGgp-0006tw-00 for ipv6@ietf.org; Thu, 30 Oct 2003 12:34:31 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFGgo-0006tW-00 for ipv6@ietf.org; Thu, 30 Oct 2003 12:34:30 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9UHXox21044; Thu, 30 Oct 2003 19:33:50 +0200 Date: Thu, 30 Oct 2003 19:33:49 +0200 (EET) From: Pekka Savola To: Juan Rodriguez Hervella cc: itojun@iijlab.net, , Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <200310301119.34023.jrh@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Thu, 30 Oct 2003, Juan Rodriguez Hervella wrote: > > Which problems are you referring to? I still don't understand :-( > > I'm talking about the problems you've found out. I still don't understand what you're talking about, but I'll respond to two points below.. Perhaps it'd be useful to try to characterize these issues as problems without presupposing the solutions *). I'd encourage you to try if you want to find alternative solutions. *) for example: When a dual-stack node whose IPv6 stack has been enabled is deployed on a link where there is no IPv6 connectivity (no IPv6 router, no tunneling mechanism), trying to connect to a global IPv6 address, obtained either manually or from the DNS, results significant delays, due to the on-link assumption. How to fix this? When an application has been configured to try both IPv4 and IPv6 ("AF_UNSPEC") when performing a connection and DNS lookups, a number of useless lookups are made when an IPv4-only nodes query for IPv6 DNS records, or IPv6 nodes without connectivity (see above) similarly query for IPv6 records. How to best determine which records don't need to be queried? > 1. The problem that this option is not useful if we allow to > make AAAA queries using link-local addresses. Perhaps you miswrote, but that's very far from from the problem. The problem is that a node asks for AAAA and A records with an app configured "AF_UNSPEC" even if it has only IPv6 loopback and link-local addresses. The resulting AAAA records will be pretty much useless unless one assumes it's OK to return link-local addresses from the DNS (or similar other naming service), and the general purpose apps to use them. > 4. The problem that if we keep the option as a flag, already > deployed applications won't use it. So what? Applications are updated regularly. This would actually be a good reason to issue a minor update: a performance+ robustness enhancement for those which don't have full v6 connectivity. > That wasn't my purpose. I wanted to show that the process of > initiating a connection is not as fast as turning on the telly. We have to > have in mind that this flag only minimize the worst case of this process, > that's all in my opinion. I think the analogue is entirely different. The people expect the connections to form immediately, without waiting. On the other hand, turning on a telly takes a while (the screen is dark, but gets lighter, and is OK in 10-15 seconds; the same with monitors). We can do better than that. And as connections are established dozens, hundreds or thousands of times a day, the time savings are singificant. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 30 12:51:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02710 for ; Thu, 30 Oct 2003 12:51:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGxB-0002zE-4o for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 12:51:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UHpPUt011479 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 12:51:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGxA-0002z4-U4 for ipv6-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 12:51:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02669 for ; Thu, 30 Oct 2003 12:51:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFGx9-00078q-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 12:51:23 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFGx8-00078n-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 12:51:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGwp-0002mx-Ar; Thu, 30 Oct 2003 12:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGvz-0002g4-J7 for ipv6@optimus.ietf.org; Thu, 30 Oct 2003 12:50:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02623 for ; Thu, 30 Oct 2003 12:49:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFGvx-00077g-00 for ipv6@ietf.org; Thu, 30 Oct 2003 12:50:09 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AFGvw-00077M-00 for ipv6@ietf.org; Thu, 30 Oct 2003 12:50:09 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9UHnX216458; Thu, 30 Oct 2003 09:49:33 -0800 X-mProtect: <200310301749> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNfjhCr; Thu, 30 Oct 2003 09:49:32 PST Message-ID: <3FA15072.3040900@iprg.nokia.com> Date: Thu, 30 Oct 2003 09:54:58 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Smith CC: ipv6@ietf.org Subject: Re: Packetization Layer Path MTU Discovery (was Re: "RFC 2461bis" issue: MTU handling) References: <3F9E8AD5.3010703@kolumbus.fi> <20031030232342.2490f458.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mark, Many of us have known about this work for a long time now. If there are certain aspects of it you would like to call to our attention (e.g., if there is a way for the lower layers to know when the upper layers are doing PLPMTUD) please send specific details. In the meantime, I will be turning my attention to other topics. Thanks - Fred ftemplin@iprg.nokia.com P.S. The draft you cited is now obsoleted by 'draft-ietf-pmtud-method-00.txt'. Mark Smith wrote: >Hi All, > >Came across this when looking at some other MTU related info. > >http://www.psc.edu/~mathis/MTU/#pmtud > >There is an ID at > >http://www.psc.edu/~mathis/MTU/draft-mathis-plpmtud-00.txt > >The BoF slides are at > >http://www.psc.edu/~mathis/papers/mtuBOF200303/index.html > >Hope this helps, >Mark. > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 30 12:57:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02980 for ; Thu, 30 Oct 2003 12:57:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFH2i-00041x-IV for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 12:57:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UHv8Au015487 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 12:57:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFH2i-00041i-E0 for ipv6-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 12:57:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02946 for ; Thu, 30 Oct 2003 12:56:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFH2g-0007EK-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 12:57:06 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFH2g-0007EH-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 12:57:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFH2c-0003uz-5v; Thu, 30 Oct 2003 12:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFH1l-0003o5-Vi for ipv6@optimus.ietf.org; Thu, 30 Oct 2003 12:56:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02882 for ; Thu, 30 Oct 2003 12:55:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFH1k-0007DS-00 for ipv6@ietf.org; Thu, 30 Oct 2003 12:56:08 -0500 Received: from smtp02.uc3m.es ([163.117.136.122] helo=smtp.uc3m.es) by ietf-mx with esmtp (Exim 4.12) id 1AFH1j-0007Cn-00 for ipv6@ietf.org; Thu, 30 Oct 2003 12:56:07 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 3876843152; Thu, 30 Oct 2003 18:55:35 +0100 (CET) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp02.uc3m.es (Postfix) with ESMTP id 003569A029; Thu, 30 Oct 2003 18:55:34 +0100 (CET) From: Juan Rodriguez Hervella Organization: UC3M To: Soliman Hesham , , Subject: Re: Issue 3: on link assumption considered harmful Date: Thu, 30 Oct 2003 18:55:31 +0100 User-Agent: KMail/1.5.4 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310301855.32554.jrh@it.uc3m.es> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday 30 October 2003 18:15, Pekka Savola wrote: > On Thu, 30 Oct 2003, Juan Rodriguez Hervella wrote: > [...] > > > Ooops, forget the oven :-), just think as if the fridge was shipped > > with an Ipv6 address prefix and the scheduler was shipped with > > another IPv6 prefix :) > > The whole point of IPv6 (and also IP) is that machines aren't shipped with > invented addresses, and you're supposed to make them automatically > communicate. Or, in the case of IPv6, the invented address is their > link-local address and they can autoconfigure another address. All of > these are from the same prefix between all the nodes on a link. > > This is just so incredibly bad idea it doesn't even bear thinking about. > But if one want to enable it manually, you can always point a default > route in your Ethernet interface. Hello: Indeed this is a good point. I won't discuss on this subject any longer. Thanks for the discussion and the pointer! [snipped] -- JFRH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 30 14:42:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06825 for ; Thu, 30 Oct 2003 14:42:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFIg1-0002p8-Sy for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 14:41:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UJfnjV010845 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 14:41:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFIg1-0002og-Ge for ipv6-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 14:41:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06771 for ; Thu, 30 Oct 2003 14:41:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFIfy-0000qx-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 14:41:46 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFIfx-0000qP-02 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 14:41:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFIXV-0001V7-IR; Thu, 30 Oct 2003 14:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFIWv-0001SC-Ow for ipv6@optimus.ietf.org; Thu, 30 Oct 2003 14:32:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06206 for ; Thu, 30 Oct 2003 14:32:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFIWs-0000io-00 for ipv6@ietf.org; Thu, 30 Oct 2003 14:32:23 -0500 Received: from smtp02.uc3m.es ([163.117.136.122] helo=smtp.uc3m.es) by ietf-mx with esmtp (Exim 4.12) id 1AFIWs-0000il-00 for ipv6@ietf.org; Thu, 30 Oct 2003 14:32:22 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 67A144323D; Thu, 30 Oct 2003 20:31:51 +0100 (CET) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp02.uc3m.es (Postfix) with ESMTP id 411CB9A02D; Thu, 30 Oct 2003 20:31:51 +0100 (CET) From: Juan Rodriguez Hervella Organization: UC3M To: Pekka Savola Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Date: Thu, 30 Oct 2003 20:31:47 +0100 User-Agent: KMail/1.5.4 Cc: , References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310302031.48801.jrh@it.uc3m.es> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday 30 October 2003 18:33, Pekka Savola wrote: [snipped] > When a dual-stack node whose IPv6 stack has been enabled is deployed on a > link where there is no IPv6 connectivity (no IPv6 router, no tunneling > mechanism), trying to connect to a global IPv6 address, obtained either > manually or from the DNS, results significant delays, due to the on-link > assumption. How to fix this? (I wonder why onlink assumption was included in the spec, but that's another story....) Ok, so if we get rid of the onlink-assumption, there won't be such delay, is this right ?. > When an application has been configured to try both IPv4 and IPv6 > ("AF_UNSPEC") when performing a connection and DNS lookups, a number of > useless lookups are made when an IPv4-only nodes query for IPv6 DNS > records, or IPv6 nodes without connectivity (see above) similarly query > for IPv6 records. How to best determine which records don't need to be > queried? if the host answers with "no route to destination" or something like that, (we don't have onlink assuption any more, remember), this is fixed, the penalty for those extra IPv6 connection attempts will be as tiny as my wage. This is my major concern now, so I would be glad to hear your opinion about this. What follows in the rest of the email are little answers to your questions and an issue which is not related to the AI_ADDRCONFIG discussion but I think is good to have a glimse at. > > 1. The problem that this option is not useful if we allow to > > make AAAA queries using link-local addresses. > > Perhaps you miswrote, but that's very far from from the problem. The > problem is that a node asks for AAAA and A records with an app > configured "AF_UNSPEC" even if it has only IPv6 loopback and link-local > addresses. The resulting AAAA records will be pretty much useless unless > one assumes it's OK to return link-local addresses from the DNS (or > similar other naming service), and the general purpose apps to use them. No I didn't miswrite, I was thinking about the problem in the wrong way :) I see the point now. [final Pekka's explanations cut out, though I agree with him] To sum the thing up, I extract the following from your first email on this thread: Pekka gave us food for thought, like this: > [extracted] > > - does this seem like a problem, that is, should getaddrinfo() + > AI_ADDRCONFIG perform AAAA DNS queries etc. if > the node only has v6 link-local/loopback addresses? Provided we get rid of the onlink assumtion, as I've said above, there won't be any difference. > - is getaddrinfo() + link-local addresses something we should support? I don't think so. It's better to do things better :) > - should this be fixed by e.g.: > a) recommending that the implementations filter out link-locals as well > when doing AI_ADDRCONFIG (a BCP/Info document) > b) specifying additional semantics for AI_ADDRCONFIG > c) specifying a new hint which would perform this > I dunno. The following has nothing to do with AI_ADDRCONFIG: I've also experienced a problem which I think doesn't have a solution (at least a solution the host could implement). For example: I'm using the latest web browser, which it's already using this flag because the developers are really smart and they are use to trying more than one destination address (this still doesn't happen on my Konqueror 3.1.4). I try to connect to "www.6bone.net", I receive both AAAA and A. My network is IPv6/IPv4, so I have no connectivity problems, and my web tries to connect to IPv6 in the first place. "www.6bone.net" has just moved to IPv6, and its provider is having a lot of problems with that, so they don't have outer IPv6 connectivity. (www.6bone.net is just an example, haven't occured to me on this website) -- JFRH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 30 15:04:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07930 for ; Thu, 30 Oct 2003 15:04:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFJ1h-0004rl-OU for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 15:04:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UK4D0h018699 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 15:04:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFJ1h-0004rW-Jo for ipv6-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 15:04:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07842 for ; Thu, 30 Oct 2003 15:04:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFJ1e-0001Dv-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 15:04:10 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFJ1e-0001Ds-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 15:04:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFJ1V-0004mf-Hl; Thu, 30 Oct 2003 15:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFJ0a-0004bz-1n for ipv6@optimus.ietf.org; Thu, 30 Oct 2003 15:03:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07726 for ; Thu, 30 Oct 2003 15:02:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFJ0X-0001DB-00 for ipv6@ietf.org; Thu, 30 Oct 2003 15:03:01 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFJ0W-0001D7-00 for ipv6@ietf.org; Thu, 30 Oct 2003 15:03:00 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9UK2P723973; Thu, 30 Oct 2003 22:02:26 +0200 Date: Thu, 30 Oct 2003 22:02:25 +0200 (EET) From: Pekka Savola To: Juan Rodriguez Hervella cc: v6ops@ops.ietf.org, Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <200310302031.48801.jrh@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Note: at the end of the message, there is also a description of an another problem, partially described in draft-ietf-v6ops-v6onbydefault-00.txt. On Thu, 30 Oct 2003, Juan Rodriguez Hervella wrote: > On Thursday 30 October 2003 18:33, Pekka Savola wrote: > > When a dual-stack node whose IPv6 stack has been enabled is deployed on a > > link where there is no IPv6 connectivity (no IPv6 router, no tunneling > > mechanism), trying to connect to a global IPv6 address, obtained either > > manually or from the DNS, results significant delays, due to the on-link > > assumption. How to fix this? > > (I wonder why onlink assumption was included in the spec, but that's > another story....) > > Ok, so if we get rid of the onlink-assumption, there won't be such > delay, is this right ?. Yep, the delay is eliminated (as far as I can see). > > When an application has been configured to try both IPv4 and IPv6 > > ("AF_UNSPEC") when performing a connection and DNS lookups, a number of > > useless lookups are made when an IPv4-only nodes query for IPv6 DNS > > records, or IPv6 nodes without connectivity (see above) similarly query > > for IPv6 records. How to best determine which records don't need to be > > queried? > > if the host answers with "no route to destination" or something like that, > (we don't have onlink assuption any more, remember), > this is fixed, the penalty for those extra IPv6 connection attempts will be as > tiny as my wage. This is a separate problem. What I was worried in above is eliminating the unnecessary DNS lookups. Your problem may be something like: When an application has been configured to try both IPv4 and IPv6 ("AF_UNSPEC"), the results of the query are tried in some order, typically IPv6 first. When the destination is unreachable, an error should be returned. How to make falling back to the next address robust? .. straying to the solutions side, you may want to consider e.g.: a) avoiding such connection attempts in the first place, i.e., with minimal complexity there is only minimal chance of someone misbehaving and something getting broken! b) ensuring somehow that you always get the ICMP message and the connect() (or similar code) reacts to it, that is, you get a feedback signal back from the system when the attempt fails. This is actually a big potential problem. Consider firewalls which discard (instead of send ICMP unreachable) packets. This could trigger a TCP timeout.. (see more at the end) c) .... > This is my major concern now, so I would be glad to hear your opinion > about this. See above. This is also a major potential problem (it isn't now, because IPv6 is only deployed by mostly clueful folks, but if the masses do it and use e.g. firewalls w/ silent discard, we could end up in a loooooot of trouble..) [snip -- to a description of a different issue] > I've also experienced a problem which I think doesn't have a > solution (at least a solution the host could implement). For example: > > I'm using the latest web browser, which it's already using this flag > because the developers are really smart and they are use to > trying more than one destination address (this still doesn't happen > on my Konqueror 3.1.4). > > I try to connect to "www.6bone.net", I receive both AAAA and A. > > My network is IPv6/IPv4, so I have no connectivity problems, and > my web tries to connect to IPv6 in the first place. > > "www.6bone.net" has just moved to IPv6, and its provider is having > a lot of problems with that, so they don't have outer IPv6 connectivity. > > (www.6bone.net is just an example, haven't occured to me on this website) I'm not sure what you mean by "outer IPv6 connectivity". Do you mean that either: - the IPv6 connectivity doesn't exist (you get back ICMP destination unreachable), - the IPv6 connectivity exists, but the packets get blackholed somewhere (you get nothing back, results in TCP timeout) - something else? In the former case, have a look at draft-ietf-v6ops-v6onbydefault-00.txt section 2.3; this is discussed there. TCP connection should not abort from an ICMP soft error such as destination unreachable. However, some implementations do this, and it may make most sense for quick recovery. In the latter case, there is no real fix that I'm aware of. Could be worth thinking about a bit, or writing down as a potential problem. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 30 15:42:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10604 for ; Thu, 30 Oct 2003 15:42:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFJcZ-0000vf-EK for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 15:42:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UKgJLl003566 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 15:42:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFJcZ-0000vR-6u for ipv6-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 15:42:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10564 for ; Thu, 30 Oct 2003 15:42:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFJcX-0001qI-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 15:42:17 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFJcX-0001qF-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 15:42:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFJbL-0000fJ-Q7; Thu, 30 Oct 2003 15:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFJao-0000cC-Bq for ipv6@optimus.ietf.org; Thu, 30 Oct 2003 15:40:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10376 for ; Thu, 30 Oct 2003 15:40:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFJam-0001mR-00 for ipv6@ietf.org; Thu, 30 Oct 2003 15:40:28 -0500 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx with esmtp (Exim 4.12) id 1AFJal-0001lK-00 for ipv6@ietf.org; Thu, 30 Oct 2003 15:40:28 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 975D0354; Thu, 30 Oct 2003 21:39:53 +0100 (CET) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp03.uc3m.es (Postfix) with ESMTP id 7924E353; Thu, 30 Oct 2003 21:39:53 +0100 (CET) From: Juan Rodriguez Hervella Organization: UC3M To: Pekka Savola Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Date: Thu, 30 Oct 2003 21:39:50 +0100 User-Agent: KMail/1.5.4 Cc: v6ops@ops.ietf.org, References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310302139.50993.jrh@it.uc3m.es> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday 30 October 2003 21:02, Pekka Savola wrote: > Note: at the end of the message, there is also a description of an another > problem, partially described in draft-ietf-v6ops-v6onbydefault-00.txt. > > On Thu, 30 Oct 2003, Juan Rodriguez Hervella wrote: > > On Thursday 30 October 2003 18:33, Pekka Savola wrote: > > > When a dual-stack node whose IPv6 stack has been enabled is deployed on > > > a link where there is no IPv6 connectivity (no IPv6 router, no > > > tunneling mechanism), trying to connect to a global IPv6 address, > > > obtained either manually or from the DNS, results significant delays, > > > due to the on-link assumption. How to fix this? > > > > (I wonder why onlink assumption was included in the spec, but that's > > another story....) > > > > Ok, so if we get rid of the onlink-assumption, there won't be such > > delay, is this right ?. > > Yep, the delay is eliminated (as far as I can see). > > > > When an application has been configured to try both IPv4 and IPv6 > > > ("AF_UNSPEC") when performing a connection and DNS lookups, a number of > > > useless lookups are made when an IPv4-only nodes query for IPv6 DNS > > > records, or IPv6 nodes without connectivity (see above) similarly query > > > for IPv6 records. How to best determine which records don't need to be > > > queried? > > > > if the host answers with "no route to destination" or something like > > that, (we don't have onlink assuption any more, remember), > > this is fixed, the penalty for those extra IPv6 connection attempts will > > be as tiny as my wage. > > This is a separate problem. What I was worried in above is eliminating > the unnecessary DNS lookups. Sorry but I don't catch this point. Maybe we are talking either about different things or the same things, I'm not sure. I will try to set up an specific example, talking about the right behaviour we should expect of this stuff. If you make a getaddrinfo() call with AF_UNSPEC and AI_ADDRCONFIG on a machine with dual-stack support, full IPv4 connectivity and only IPv6 link local addresses, this should run as follows: 1. Interacting with the DNS over IPv4, but it will ask only for A r.records. 2. Connecting using IPv4, no problem. If you've got the same scenario, but you don't use AI_ADDRCONFIG: 1. Interacting with the DNS over IPv4, it will return AAAA and A records. 2. Trying to connect with an IPv6 global address. This should fail inmediately (we don't have the delay that onlink assuption causes...) with "no-route-to-host". 3. A well-programmed app. would try with the IPv4 address, end up with a conexion. Where are the "unnecesary DNS lookups" you are talking about ? I think that you receive both AAAA and A records on the same unique query, don't you ? > > Your problem may be something like: > > When an application has been configured to try both IPv4 and IPv6 > ("AF_UNSPEC"), the results of the query are tried in some order, typically > IPv6 first. When the destination is unreachable, an error should be > returned. How to make falling back to the next address robust? Ahhh that's exactly what I was trying to tell you on the "www.6bone.net" example. I sent the mail before finishing the example, sorry :) I was telling that in this case, you have to wait for the TCP timeout to be able to go on trying with the IPv4 destination addr. > .. straying to the solutions side, you may want to consider e.g.: > > a) avoiding such connection attempts in the first place, i.e., with > minimal complexity there is only minimal chance of someone misbehaving and > something getting broken! > b) ensuring somehow that you always get the ICMP message and the > connect() (or similar code) reacts to it, that is, you get a feedback > signal back from the system when the attempt fails. This is actually a > big potential problem. Consider firewalls which discard (instead of send > ICMP unreachable) packets. This could trigger a TCP timeout.. (see more > at the end) > c) .... > > > This is my major concern now, so I would be glad to hear your opinion > > about this. > > See above. This is also a major potential problem (it isn't now, because > IPv6 is only deployed by mostly clueful folks, but if the masses do it and > use e.g. firewalls w/ silent discard, we could end up in a loooooot of > trouble..) Yes it is a problem indeed. > [snip -- to a description of a different issue] > > > I've also experienced a problem which I think doesn't have a > > solution (at least a solution the host could implement). For example: > > > > I'm using the latest web browser, which it's already using this flag > > because the developers are really smart and they are use to > > trying more than one destination address (this still doesn't happen > > on my Konqueror 3.1.4). > > > > I try to connect to "www.6bone.net", I receive both AAAA and A. > > > > My network is IPv6/IPv4, so I have no connectivity problems, and > > my web tries to connect to IPv6 in the first place. > > > > "www.6bone.net" has just moved to IPv6, and its provider is having > > a lot of problems with that, so they don't have outer IPv6 connectivity. > > > > (www.6bone.net is just an example, haven't occured to me on this website) > > I'm not sure what you mean by "outer IPv6 connectivity". Do you mean that > either: > - the IPv6 connectivity doesn't exist (you get back ICMP destination > unreachable), > - the IPv6 connectivity exists, but the packets get blackholed somewhere > (you get nothing back, results in TCP timeout) > - something else? > > In the former case, have a look at draft-ietf-v6ops-v6onbydefault-00.txt > section 2.3; this is discussed there. TCP connection should not abort > from an ICMP soft error such as destination unreachable. However, some > implementations do this, and it may make most sense for quick recovery. > > In the latter case, there is no real fix that I'm aware of. Could be > worth thinking about a bit, or writing down as a potential problem. I was talking about the latter case. -- JFRH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 30 17:18:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16986 for ; Thu, 30 Oct 2003 17:18:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFL76-0002Ky-DE for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 17:17:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UMHuRN008978 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 17:17:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFL76-0002Kj-50 for ipv6-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 17:17:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16962 for ; Thu, 30 Oct 2003 17:17:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFL73-0003gl-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 17:17:53 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFL73-0003gi-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 17:17:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFL6D-0002Ag-Ba; Thu, 30 Oct 2003 17:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFL5J-00026y-40 for ipv6@optimus.ietf.org; Thu, 30 Oct 2003 17:16:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16914 for ; Thu, 30 Oct 2003 17:15:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFL5G-0003fI-00 for ipv6@ietf.org; Thu, 30 Oct 2003 17:16:02 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFL5F-0003ee-00 for ipv6@ietf.org; Thu, 30 Oct 2003 17:16:02 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9UMFRM26929; Fri, 31 Oct 2003 00:15:27 +0200 Date: Fri, 31 Oct 2003 00:15:27 +0200 (EET) From: Pekka Savola To: Juan Rodriguez Hervella cc: v6ops@ops.ietf.org, Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <200310302139.50993.jrh@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Thu, 30 Oct 2003, Juan Rodriguez Hervella wrote: [snip] > > Sorry but I don't catch this point. Maybe we are talking either > about different things or the same things, I'm not sure. > I will try to set up an specific example, talking about the right > behaviour we should expect of this stuff. > > If you make a getaddrinfo() call with AF_UNSPEC and AI_ADDRCONFIG on a > machine with dual-stack support, full IPv4 connectivity and only IPv6 link > local addresses, this should run as follows: > > 1. Interacting with the DNS over IPv4, but it will ask only for A r.records. > 2. Connecting using IPv4, no problem. > > If you've got the same scenario, but you don't use AI_ADDRCONFIG: > > 1. Interacting with the DNS over IPv4, it will return AAAA and A records. > 2. Trying to connect with an IPv6 global address. This should fail > inmediately (we don't have the delay that onlink assuption causes...) > with "no-route-to-host". > 3. A well-programmed app. would try with the IPv4 address, end up with > a conexion. > > Where are the "unnecesary DNS lookups" you are talking about ? > I think that you receive both AAAA and A records on the same unique query, > don't you ? Look at the details of item "1." in each case. There are multiple when queries multiple records are asked/responded. (On the other hand, with properly augmented AI_ADDRCONFIG, you could omit everything relating to AAAA records, causing optimization.) For example, this roughly what happens when you do try look up "psg.com" with getaddrinfo using PF_UNSPEC: 23:48:31.909344 80.186.150.55.1836 > 193.229.0.40.53: [udp sum ok] 1651+ AAAA? psg.com. (25) (ttl 64, id 27243, len 53) 23:48:31.920410 193.229.0.40.53 > 80.186.150.55.1836: [udp sum ok] 1651 q: AAAA? psg.com. 1/0/0 psg.com. AAAA 2001:418:1::62 (53) (DF) (ttl 251, id 17061, len 81) 23:48:31.920892 80.186.150.55.1837 > 193.229.0.40.53: [udp sum ok] 1652+ A? psg.com. (25) (ttl 64, id 27244, len 53) 23:48:31.930985 193.229.0.40.53 > 80.186.150.55.1837: [udp sum ok] 1652 q: A? psg.com. 1/0/0 psg.com. A 147.28.0.62 (41) (DF) (ttl 251, id 46142, len 69) Two roundtrips. Three if you do A6 as well :-), and even more if you have to look up the delegation paths as well. Note: I'm using a forwarding nameserver here -- in practice, the roundtrips would take much longer if nothing would be cached (the DNS server I'm pointing my resolver to already has everything about psg.com cached.). I did a test: tried to do a TCP connect to www.6bone.net. From the first DNS query packet sent out, it took 1.528 _seconds_ for the fist TCP packet to go out! The first AAAA record arrived after 0.915 seconds (a lot in itself). That gives a measure of how much (at least) it would be faster with IPv4-only. Over 50% additional delay, and it could be worse if the delegation path DNS servers have AAAA records which are not cached. Only after all the responses have been received, the TCP connection is established. After all, you have to run the default address selection on all the results. This feature of DNS lookups certainly should be spelled out if/when we add AI_ADDRCONFIG considerations to the v6onbydefault document, as it clearly isn't apparent.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 30 18:43:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20775 for ; Thu, 30 Oct 2003 18:43:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFMRi-0002bZ-5w for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 18:43:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UNhIds010007 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 18:43:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFMRh-0002bC-VD for ipv6-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 18:43:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20752 for ; Thu, 30 Oct 2003 18:43:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFMRe-0004p3-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 18:43:14 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFMRe-0004p0-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 18:43:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFMQU-0002TY-2T; Thu, 30 Oct 2003 18:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFMQ6-0002SK-GC for ipv6@optimus.ietf.org; Thu, 30 Oct 2003 18:41:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20725 for ; Thu, 30 Oct 2003 18:41:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFMQ3-0004oO-00 for ipv6@ietf.org; Thu, 30 Oct 2003 18:41:35 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFMQ2-0004n2-00 for ipv6@ietf.org; Thu, 30 Oct 2003 18:41:34 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9UNcfH28151; Fri, 31 Oct 2003 01:38:42 +0200 Date: Fri, 31 Oct 2003 01:38:41 +0200 (EET) From: Pekka Savola To: Soliman Hesham cc: ipv6@ietf.org Subject: Re: RFC 2461- issue list In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922E01@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Wed, 22 Oct 2003, Soliman Hesham wrote: > This is what I found initially. Please let us know if > there are any issues that should be added to the list. Oh, yes, I only now remembered one. There was some confusion regarding redirects and how you can configure the nexthops. See the thread I opened on "global/link-local nexthops and RFC2461" on 17 Jul 2003, also at: http://www.atm.tut.fi/list-archive/ipng/msg09986.html It may be that only a textual clarification is needed on the applicability of redirects in the presence of non-link-local nexthops, but if opted to do more, there could be some other work for to do as well (my gut feeling was that only the clarification was deemed necessary) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 30 19:57:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23117 for ; Thu, 30 Oct 2003 19:57:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFNai-0001vj-8j for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 19:56:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9V0ue5m007416 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 19:56:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFNah-0001vW-VK for ipv6-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 19:56:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23070 for ; Thu, 30 Oct 2003 19:56:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFNag-0005sK-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 19:56:38 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFNaf-0005sH-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 19:56:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFNa5-0001oD-Qa; Thu, 30 Oct 2003 19:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFNZH-0001ka-3N for ipv6@optimus.ietf.org; Thu, 30 Oct 2003 19:55:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22969 for ; Thu, 30 Oct 2003 19:55:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFNZF-0005pr-00 for ipv6@ietf.org; Thu, 30 Oct 2003 19:55:09 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AFNZE-0005pT-00 for ipv6@ietf.org; Thu, 30 Oct 2003 19:55:08 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RD7WG>; Thu, 30 Oct 2003 19:54:39 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E4B@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" Cc: ipv6@ietf.org Subject: RE: RFC 2461- issue list Date: Thu, 30 Oct 2003 19:54:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Thnx, it's added to the list. Looks like a text clarification will do. Hesham > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Thursday, October 30, 2003 6:39 PM > To: Soliman Hesham > Cc: ipv6@ietf.org > Subject: Re: RFC 2461- issue list > > > On Wed, 22 Oct 2003, Soliman Hesham wrote: > > This is what I found initially. Please let us know if > > there are any issues that should be added to the list. > > Oh, yes, I only now remembered one. There was some > confusion regarding > redirects and how you can configure the nexthops. See the > thread I opened > on "global/link-local nexthops and RFC2461" on 17 Jul 2003, also at: > > http://www.atm.tut.fi/list-archive/ipng/msg09986.html > > It may be that only a textual clarification is needed on the > applicability > of redirects in the presence of non-link-local nexthops, but > if opted to > do more, there could be some other work for to do as well > (my gut feeling > was that only the clarification was deemed necessary) > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Oct 30 21:01:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24821 for ; Thu, 30 Oct 2003 21:01:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFObV-0006wR-R7 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 21:01:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9V21XjX026684 for ipv6-archive@odin.ietf.org; Thu, 30 Oct 2003 21:01:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFObV-0006wJ-KZ for ipv6-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 21:01:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24794 for ; Thu, 30 Oct 2003 21:01:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFObT-0006eU-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 21:01:31 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFObS-0006eR-00 for ipv6-web-archive@ietf.org; Thu, 30 Oct 2003 21:01:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFOa4-0006jm-BF; Thu, 30 Oct 2003 21:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFOZJ-0006gi-Nx for ipv6@optimus.ietf.org; Thu, 30 Oct 2003 20:59:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24735 for ; Thu, 30 Oct 2003 20:59:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFOZH-0006cK-00 for ipv6@ietf.org; Thu, 30 Oct 2003 20:59:15 -0500 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 1AFOZG-0006cH-00 for ipv6@ietf.org; Thu, 30 Oct 2003 20:59:14 -0500 Received: from localhost ([130.194.13.84]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L2H9JOMKD48WYK3E@vaxh.its.monash.edu.au> for ipv6@ietf.org; Fri, 31 Oct 2003 12:52:14 +1100 Received: from blammo.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 8AA9C39C003; Fri, 31 Oct 2003 12:52:14 +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 6E0CF2DC002; Fri, 31 Oct 2003 12:52:14 +1100 (EST) Date: Fri, 31 Oct 2003 12:52:14 +1100 From: Greg Daley Subject: Re: RFC 2461- issue list To: Soliman Hesham Cc: "'Pekka Savola'" , ipv6@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3FA1C04E.2010903@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: <748C6D0A58C0F94CA63C198B6674697A01922E4B@ftmail.lab.flarion.com> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Hesham and Pekka, I'm not sure if this is the same issue (looks somewhat related), but RFC2461 allows any source address for an RS message, and only link-local response (doesn't match scopes). The difficulty comes when an RS comes from a global source address which is not directly connected to a router. Based on RS processing rules, the host which sent the RS is within a hop of the router, but has asked for an RA from an address which doesn't exist locally. Does the router reply to a message which has a source address not believed to be on this link? Does it only reply with a multicast destination? What do current implementations do in this case? I guess that unicast responses aren't appropriate because I don't think it's valid to put ND entries into the cache unless they're from the right network/interface. Please tell me if I'm going over old ground here.. Greg Soliman Hesham wrote: > Thnx, it's added to the list. Looks like > a text clarification will do. > > Hesham > > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: Thursday, October 30, 2003 6:39 PM > > To: Soliman Hesham > > Cc: ipv6@ietf.org > > Subject: Re: RFC 2461- issue list > > > > > > On Wed, 22 Oct 2003, Soliman Hesham wrote: > > > This is what I found initially. Please let us know if > > > there are any issues that should be added to the list. > > > > Oh, yes, I only now remembered one. There was some > > confusion regarding > > redirects and how you can configure the nexthops. See the > > thread I opened > > on "global/link-local nexthops and RFC2461" on 17 Jul 2003, also at: > > > > http://www.atm.tut.fi/list-archive/ipng/msg09986.html > > > > It may be that only a textual clarification is needed on the > > applicability > > of redirects in the presence of non-link-local nexthops, but > > if opted to > > do more, there could be some other work for to do as well > > (my gut feeling > > was that only the clarification was deemed necessary) > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 31 11:08:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05186 for ; Fri, 31 Oct 2003 11:08:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbp7-0008Bw-DT for ipv6-archive@odin.ietf.org; Fri, 31 Oct 2003 11:08:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VG8Tv7031482 for ipv6-archive@odin.ietf.org; Fri, 31 Oct 2003 11:08:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbp7-0008Bh-6p for ipv6-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 11:08:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05155 for ; Fri, 31 Oct 2003 11:08:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFbp4-0002Lm-00 for ipv6-web-archive@ietf.org; Fri, 31 Oct 2003 11:08:26 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFbp3-0002Lj-00 for ipv6-web-archive@ietf.org; Fri, 31 Oct 2003 11:08:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbni-0007lD-C2; Fri, 31 Oct 2003 11:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbnE-0007ie-3N for ipv6@optimus.ietf.org; Fri, 31 Oct 2003 11:06:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05062 for ; Fri, 31 Oct 2003 11:06:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFbnB-0002Jv-00 for ipv6@ietf.org; Fri, 31 Oct 2003 11:06:29 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx with esmtp (Exim 4.12) id 1AFbnA-0002J4-00 for ipv6@ietf.org; Fri, 31 Oct 2003 11:06:28 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id h9VG5nCU041546 for ; Fri, 31 Oct 2003 16:05:49 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9VG5n6H237206 for ; Fri, 31 Oct 2003 17:05:49 +0100 Received: from zurich.ibm.com ([9.145.230.49]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA57354 for ; Fri, 31 Oct 2003 17:05:48 +0100 Message-ID: <3FA2883A.BA6A93CA@zurich.ibm.com> Date: Fri, 31 Oct 2003 17:05:14 +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: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" References: <3F96659F.4040702@innovationslab.net> <3FA0351E.37C3F0CA@zurich.ibm.com> <3FA065B8.3010003@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alain Durand wrote: > > Brian E Carpenter wrote: > > >Alain, > > > >Do you think it is better to let the RIRs develop a policy for > >allocating PA space for local use, i.e. create a swamp like IPv4? > > > PA... Do you PI for Provider Independant? > If it is the case, yes I think it would be less damaging to do that. > See below. I meant PA because that is all that is in the implementors and registries' hands today. Actually any form of PI would do (they are all equally unrouteable today). I regard the Hinden/Haberman addresses as an easy-to-create form of PI. > > > > >In detail.. > > > [Focusing on technology as I think that the other dicussions will > simply not go anywhere in this forum] > > >>impact: > >> - what about reverse DNS? > >> > >> > > > >Suggestions? Is reverse DNS needed for these addresses? You're correct that > >this needs analysis. > > > A valid enough reason to get a -02 published. Sure. That's why we do WG last calls... > > >> - what about address selection rules? > >> > >> > > > >These addresses behave like global scope for that purpose. > > > In terms of scope, you're right. Now take the multi-party > communication example that was described by Erik earlier on, > there is a problem. So you need to add an extra selection rule > and an API to reverse that choice for the cases it does not make > sense. Well, in a sense I think these problems are unsolvable - I think whatever scope semantics we try to impose on the address syntax, there will always be cases where reachability is an experimental question and any algorthmic selection rule will fail. > Note: you cannot do that just by adding entries in the preference > table, this table is global and you need a per-socket oprtion. It may even be worse. If A is trying to decide which address for B to refer to C, the correct choice may be a complicated function of both B and C, and A may have no way to determine which of B's addresses are accessible to C. And I believe we have that problem whatever we do (including doing nothing), so I don't see how the current draft makes it worse. > > >> - what about address leakage? > >> > >> > > > >These addresses are unique, so leakage is nothing like as harmful > >as with RFC 1918. They are also known to be unrouteable globally, so > >can be blackholed at domain boundaries. I thought that was discussed in > >the draft. > > > > > > > >> - how to debug those networks when they will leak? > >> > >> > > > >You don't need to. If you see one of these addresses out of its intended > >domain, you only need to drop it. I'm not saying this lightly - I really > >think this is not an issue. There is nothing to debug. You just don't care. > > > > > I disagree. You cannot say that. Examples: > - you're under security attack from one of those addresses, > you'd like to trace it back. Any tiny bit helps. This in theory of course should be prevented by ingress filtering. It's true (as for RFC 1918) that if they aren't dropped at ingress, tracing back will be very hard. > > - you're doing a complex merge of several local address spaces > and things get ugly. You'd like to have a simple way (like whois) > to know who those prefixes belongs to. I would think that in such a merger you would have that information. Certainly when you merge two networks today you generally know the address prefixes. > > >> and it is impossible to map those prefixes back to their owner? > >> > >> > > > >Doesn't matter. You just drop them. > > > No. see above. > > >>In a rush to create something to replace the Site Local addresses, > >> > >> > > > >It isn't replacing site-local. It's filling a widely perceived need that > >has emerged (with our better understanding of the needs of enterprise and > >inter-enterprise networking) since site-local was invented. > > > >The rush, as I > >said at the top, is to prevent widespread misuse of PA prefixes and to give > >us a chance of preventing NAT6. > > > >If this doesn't get done soon, I think the emphasis will rapidly change to > >working with the RIRs to get a rough and ready policy in place for > >private use of PA space. > > > The real requirement is to have addresses that are not bound to any > provider, > as this because renumbering will never be painless and multi-homing solution > a la Multi6 will take years to be developped. Yes. And don't these addresses have exactly that property? > > So the question is what to do in the meantine. 3 alternatives: > 1- Give a limited amount of PI to those who really want it and let > them pay $$$ to get their ISP to route them > 2- Create this 'local address' kludge that will stay for a long time I don't believe it's a kludge. I believe it's simply a straightforward version of PI. The $$$ argument applies, in fact. > 3- Speed up the work in Multi6. A bit optimistic. Multi6 is still very hard. > None of this comes for free, however my take is that the combination > of 1 and 3 is much less expensive that 2. I can't agree, since I think 2 is a form of 1. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 31 11:26:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05980 for ; Fri, 31 Oct 2003 11:26:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFc6C-0001Rh-CH for ipv6-archive@odin.ietf.org; Fri, 31 Oct 2003 11:26:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VGQ8B4005551 for ipv6-archive@odin.ietf.org; Fri, 31 Oct 2003 11:26:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFc6C-0001RS-49 for ipv6-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 11:26:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05932 for ; Fri, 31 Oct 2003 11:25:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFc6B-0002f6-00 for ipv6-web-archive@ietf.org; Fri, 31 Oct 2003 11:26:07 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFc6A-0002f3-00 for ipv6-web-archive@ietf.org; Fri, 31 Oct 2003 11:26:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFc66-0001Lu-6g; Fri, 31 Oct 2003 11:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFc5v-0001Kk-Tf for ipv6@optimus.ietf.org; Fri, 31 Oct 2003 11:25:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05924 for ; Fri, 31 Oct 2003 11:25:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFc5v-0002es-00 for ipv6@ietf.org; Fri, 31 Oct 2003 11:25:51 -0500 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx with esmtp (Exim 4.12) id 1AFc5u-0002du-00 for ipv6@ietf.org; Fri, 31 Oct 2003 11:25:50 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id h9VGPID8044594 for ; Fri, 31 Oct 2003 16:25:18 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9VGPIQf185594 for ; Fri, 31 Oct 2003 17:25:18 +0100 Received: from zurich.ibm.com ([9.145.230.49]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA41656 for ; Fri, 31 Oct 2003 17:25:17 +0100 Message-ID: <3FA28CCB.9EE03469@zurich.ibm.com> Date: Fri, 31 Oct 2003 17:24:43 +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: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 UnicastAddresses" References: <3F96659F.4040702@innovationslab.net> <5.1.0.14.2.20031030113954.021cbf70@kahuna.telstra.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Geoff, Geoff Huston wrote: > > Brian, > > In your note to Alain you pose the question: > > >Do you think it is better to let the RIRs develop a policy for > >allocating PA space for local use, i.e. create a swamp like IPv4? > > It appears to me that you see this as being an either / or situation, > where we accept the document as is or we defer to an RIR-lead > process to undertake this form of address distribution. > > I do not agree with such an interpretation of the situation. My comments > on the weakness of the document as being ready for prime time are > based in part on over-specification of the proposed distribution function. My concern is really to get this in place reasonably quickly, and I think that means setting relatively clear guidelines for IANA rather than leaving the field open for endless debate. > The IPv6 working group wish to alter the IPv6 address architecture > to define a unicast address block that is intended to be accessible > for use in a particular context. For this purpose the document is an > appropriate and necessary vehicle. > > The IPv6 working group wish to then set a price for consumers of this > service and indicate that this price generates profits, and specify how > such profits should be disbursed. My comments have been that this > is not consistent with the role of the IETF, nor may it be possible for the IANA > to implement, and I've suggested some modifications to the document > that could address such concerns, based on removing such overly > prescriptive sections of the draft. But if we leave too much unspecified, we risk this being perceived as another gold rush opportunity with all the negative consequences that we know. That's really the extent of my concern. > > To answer you question posed to Alain, then, I'd offer the view that > it is entirely possible that the RIRs are positioned to be able to fulfil the > role of the central registry function within the base requirements of this > particular draft, and to preclude such an option is imho, not an IETF > role. Correct. I don't think the draft does that. It just asks the IANA to give the job to an authority. There is a technical reason given in the draft why it has to be a single authority (but it could perfectly well be operated by the RIRs in collaboration; that's not the IETF's business.) > > You also note that > "I think the current draft responds to Geoff adequately." > > I posted a note to this list > (https://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg00456.html) > indicating that I did not believe that this document was ready for > Proposed Standard, and indicating where I saw deficiencies in the > document, so I do not believe that this draft provides an adequate > response to the concerns that I've raised, and my impressions of > the document at this stage are largely similar to those of Alain. You're fully entitled to that opinion... I was just saying that IMHO the draft *did* respond to the concerns you've expressed. > To attempt to be constructive here, I'd be happier with a document > that was far less prescriptive about the precise nature of the > distribution function, yet retained the description of the intended > outcomes of the function, and instructed IANA to delegate this > distribution function such that the intended outcomes are attained. It's kind of hard to write down "avoid a gold rush" as an intended outcome of an RFC, but in fact I agree with the direction of the suggested text changes in your message cited above, except that I don't see how to avoid a single authority and therefore a natural monopoly... which is definitely not an IETF issue. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 31 13:20:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11318 for ; Fri, 31 Oct 2003 13:20:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFdsq-00073r-II for ipv6-archive@odin.ietf.org; Fri, 31 Oct 2003 13:20:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VIKS81027143 for ipv6-archive@odin.ietf.org; Fri, 31 Oct 2003 13:20:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFdsq-00073i-CE for ipv6-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 13:20:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11299 for ; Fri, 31 Oct 2003 13:20:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFdso-0004WG-00 for ipv6-web-archive@ietf.org; Fri, 31 Oct 2003 13:20:26 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFdso-0004WC-00 for ipv6-web-archive@ietf.org; Fri, 31 Oct 2003 13:20:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFdsS-0006wH-NT; Fri, 31 Oct 2003 13:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFdrq-0006s7-Q6 for ipv6@optimus.ietf.org; Fri, 31 Oct 2003 13:19:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11283 for ; Fri, 31 Oct 2003 13:19:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFdrg-0004Vr-00 for ipv6@ietf.org; Fri, 31 Oct 2003 13:19:16 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 1AFdrf-0004Vn-00 for ipv6@ietf.org; Fri, 31 Oct 2003 13:19:15 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id h9VIJFcm024477 for ; Fri, 31 Oct 2003 11:19:15 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HNM003B9W81BB@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Fri, 31 Oct 2003 11:19:14 -0700 (MST) Received: from sun.com ([129.146.11.181]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HNM0039LW7Z7A@mail.sun.net> for ipv6@ietf.org; Fri, 31 Oct 2003 11:19:12 -0700 (MST) Date: Fri, 31 Oct 2003 10:19:11 -0800 From: Alain Durand Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" To: Brian E Carpenter Cc: ipv6@ietf.org Message-id: <3FA2A79F.4040203@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: <3F96659F.4040702@innovationslab.net> <3FA0351E.37C3F0CA@zurich.ibm.com> <3FA065B8.3010003@sun.com> <3FA2883A.BA6A93CA@zurich.ibm.com> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Brian E Carpenter wrote: >Alain Durand wrote: > > >>Brian E Carpenter wrote: >> >> >> >>>Alain, >>> >>>Do you think it is better to let the RIRs develop a policy for >>>allocating PA space for local use, i.e. create a swamp like IPv4? >>> >>> >>> >>PA... Do you PI for Provider Independant? >>If it is the case, yes I think it would be less damaging to do that. >>See below. >> >> > >I meant PA because that is all that is in the implementors and >registries' hands today. Actually any form of PI would do (they are >all equally unrouteable today). I regard the Hinden/Haberman addresses >as an easy-to-create form of PI. > > I meant traceable, potentially routable PI. Hinden/Haberman addresses are not traceable (in the sense that looking at the prefix I can tell who it belongs to), and this is a big difference. >>Note: you cannot do that just by adding entries in the preference >>table, this table is global and you need a per-socket oprtion. >> >> > >It may even be worse. If A is trying to decide which address for B >to refer to C, the correct choice may be a complicated function of both >B and C, and A may have no way to determine which of B's addresses >are accessible to C. And I believe we have that problem whatever we >do (including doing nothing), so I don't see how the current draft >makes it worse. > if the only thing out there was globally reachable addresses, this problem will go away. I understand that some of those addresses may not be reachable because of firewall, but this is a case of misconfiguration. So I argue that the hinden/haberman draft makes things more complex as it creates two family of addresses, those who are potentially unreachable by design and those who are potentially unreacable by configuration. >>>> - what about address leakage? >>>> >>>> >>>> >>>> >>>These addresses are unique, so leakage is nothing like as harmful >>>as with RFC 1918. >>> I disagree. They share many issues, like the one addressed by the AS112 project http://www.as112.net/ >>>> - how to debug those networks when they will leak? >>>> >>>> >>>> >>>> >>>You don't need to. If you see one of these addresses out of its intended >>>domain, you only need to drop it. I'm not saying this lightly - I really >>>think this is not an issue. There is nothing to debug. You just don't care. >>> >>> >>> >>> >>I disagree. You cannot say that. Examples: >>- you're under security attack from one of those addresses, >> you'd like to trace it back. Any tiny bit helps. >> >> > >This in theory of course should be prevented by ingress filtering. It's >true (as for RFC 1918) that if they aren't dropped at ingress, tracing >back will be very hard. > This is exactly my point: this proposal will make debugging the global Internet more difficult. >>- you're doing a complex merge of several local address spaces >> and things get ugly. You'd like to have a simple way (like whois) >> to know who those prefixes belongs to. >> >> > >I would think that in such a merger you would have that information. >Certainly when you merge two networks today you generally know the >address prefixes. > > 2 is easy. more than 2 gets difficult. Picture the situation: "oh, we have merged so many times, we now have tens of prefixes advertized and we do not know/remember which one is which..." All this because those addresses are untraceable. >>So the question is what to do in the meantine. 3 alternatives: >>1- Give a limited amount of PI to those who really want it and let >> them pay $$$ to get their ISP to route them >>2- Create this 'local address' kludge that will stay for a long time >> >> > >I don't believe it's a kludge. I believe it's simply a straightforward >version of PI. The $$$ argument applies, in fact. > Difference of opinion. IMHO, it is not that straightforward, there are many side effects. See above. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 31 13:30:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12149 for ; Fri, 31 Oct 2003 13:30:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFe2J-0008BT-1e for ipv6-archive@odin.ietf.org; Fri, 31 Oct 2003 13:30:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VIUEdW031453 for ipv6-archive@odin.ietf.org; Fri, 31 Oct 2003 13:30:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFe2I-0008BE-Nl for ipv6-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 13:30:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12056 for ; Fri, 31 Oct 2003 13:30:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFe2G-0004mz-00 for ipv6-web-archive@ietf.org; Fri, 31 Oct 2003 13:30:12 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFe2G-0004mw-00 for ipv6-web-archive@ietf.org; Fri, 31 Oct 2003 13:30:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFe28-00081U-H4; Fri, 31 Oct 2003 13:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFe1V-0007x0-2J for ipv6@optimus.ietf.org; Fri, 31 Oct 2003 13:29:25 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12032 for ; Fri, 31 Oct 2003 13:29:12 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AFduu-000234-N0; Fri, 31 Oct 2003 13:22:36 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: ipv6@ietf.org From: The IESG Subject: Last Call: 'Management Information Base for the Internet Protocol (IP)' to Proposed Standard Reply-to: iesg@ietf.org Message-Id: Date: Fri, 31 Oct 2003 13:22:36 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , The IESG has received a request from the IP Version 6 Working Group to consider the following document: - 'Management Information Base for the Internet Protocol (IP) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-11-14. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2011-update-04.txt -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 31 14:00:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13436 for ; Fri, 31 Oct 2003 14:00:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFeVe-0003ek-EJ for ipv6-archive@odin.ietf.org; Fri, 31 Oct 2003 14:00:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VJ0Yv2014048 for ipv6-archive@odin.ietf.org; Fri, 31 Oct 2003 14:00:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFeVe-0003eV-9t for ipv6-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 14:00:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13351 for ; Fri, 31 Oct 2003 14:00:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFeVc-0005Hy-00 for ipv6-web-archive@ietf.org; Fri, 31 Oct 2003 14:00:32 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFeVb-0005Hv-00 for ipv6-web-archive@ietf.org; Fri, 31 Oct 2003 14:00:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFeVB-0003Ry-RC; Fri, 31 Oct 2003 14:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFeUk-0003M5-5Y for ipv6@optimus.ietf.org; Fri, 31 Oct 2003 13:59:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13281 for ; Fri, 31 Oct 2003 13:59:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFeUh-0005FD-00 for ipv6@ietf.org; Fri, 31 Oct 2003 13:59:35 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AFeUg-0005Ey-00 for ipv6@ietf.org; Fri, 31 Oct 2003 13:59:35 -0500 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h9VIx2V25301 for ; Fri, 31 Oct 2003 10:59:02 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h9VJ21tX016033 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 31 Oct 2003 11:02:04 -0800 Message-ID: <3FA2B09D.9090901@innovationslab.net> Date: Fri, 31 Oct 2003 13:57:33 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF Mailing List Subject: Latest Agenda Content-Type: multipart/mixed; boundary="------------040603030300070503050301" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------040603030300070503050301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit All, Attached is the latest agenda for the IPv6 WG meetings at IETF 58. Please note that in order to accomodate some travel schedules, there will be discussion of local-use addresses in both sessions. Regards, Brian & Bob IPv6 WG Chairs --------------040603030300070503050301 Content-Type: text/plain; name="Agenda.txt" Content-Disposition: inline; filename="Agenda.txt" Content-Transfer-Encoding: 7bit Tuesday (11/11/03) 1700-1800 ------------------------------ 1. Intro & Agenda Bashing chairs 5 minutes 2. Milestone Review and Document Status chairs 10 minutes 3. Tunnel MIB Thaler 10 minutes - draft-thaler-inet-tunnel-mib-00.txt - Goal: overview of proposal, adopt as WG item? 4. Proxy RA Thaler 10 minutes - draft-thaler-ipv6-ndproxy-01.txt - Goal: status update, adopt as WG item? 5. ICMP Updates Hinden 10 minutes - draft-ietf-ipngwg-icmp-v3-02.txt - Goal: status update 6. Local Communications Goals Hain/Templin 15 minutes - draft-hain-templin-ipv6-localcomm-03.txt - Goal: discussion of open issues Wednesday (11/12/03) 1300-1500 ------------------------------ 1. Intro & Agenda Bashing chairs 5 minutes 2. Neighbor Discovery Updates Tatuya 20 minutes - draft-soliman-ipv6-2461-bis-00.txt - Goal: issue discussion 3. Stateless Autoconfiguration Updates Tatuya 20 minutes - draft-jinmei-ipv6-rfc2462bis-00.txt - Goal: issue discussion 4. Scoped Address Arch Document Tatuya 10 minutes - draft-ietf-ipv6-scoping-arch-00.txt - Goal: discussion of last call comments 5. SL Deprecation Document Carpenter 20 minutes - draft-ietf-ipv6-deprecate-site-local-01.txt - Goal: discussion of last call comments 6. ULA Document Hinden 15 minutes - draft-ietf-ipv6-unique-local-addr-01.txt - Goal: discussion of last call comments 7. Address Architecture Update Hinden 15 minutes - draft-ietf-ipv6-addr-arch-v4-00.txt - Goal: review changes and plan for moving forward 8. Identifier/Locator Separation Lindqvist 10 minutes --------------040603030300070503050301-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Oct 31 14:55:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16068 for ; Fri, 31 Oct 2003 14:55:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFfM3-0000rw-7L for ipv6-archive@odin.ietf.org; Fri, 31 Oct 2003 14:54:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VJshME003334 for ipv6-archive@odin.ietf.org; Fri, 31 Oct 2003 14:54:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFfM3-0000rh-2I for ipv6-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 14:54:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16035 for ; Fri, 31 Oct 2003 14:54:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFfM0-0006B1-00 for ipv6-web-archive@ietf.org; Fri, 31 Oct 2003 14:54:40 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFfLz-0006Ay-00 for ipv6-web-archive@ietf.org; Fri, 31 Oct 2003 14:54:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFfLN-0000iX-6h; Fri, 31 Oct 2003 14:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFfKk-0000fE-LF for ipv6@optimus.ietf.org; Fri, 31 Oct 2003 14:53:22 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16001 for ; Fri, 31 Oct 2003 14:53:09 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AFf3D-0005vu-At; Fri, 31 Oct 2003 14:35:15 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: ipv6@ietf.org From: The IESG Subject: Last Call: 'Management Information Base for the Transmission Control Protocol (TCP)' to Proposed Standard Reply-to: iesg@ietf.org Message-Id: Date: Fri, 31 Oct 2003 14:35:15 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , The IESG has received a request from the IP Version 6 Working Group to consider the following document: - 'Management Information Base for the Transmission Control Protocol (TCP)' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-11-14. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2012-update-04.txt -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------