From owner-v6ops@ops.ietf.org Wed Nov 02 00:35:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXBHq-00007Z-2C for v6ops-archive@megatron.ietf.org; Wed, 02 Nov 2005 00:35:50 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12120 for ; Wed, 2 Nov 2005 00:35:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXBDm-000L9Q-3J for v6ops-data@psg.com; Wed, 02 Nov 2005 05:31:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0 Received: from [129.254.114.50] (helo=pec.etri.re.kr) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXBDl-000L8w-1X for v6ops@ops.ietf.org; Wed, 02 Nov 2005 05:31:37 +0000 Received: from pec.etri.re.kr (bjmoon3.etri.re.kr [129.254.112.124]) by pec.etri.re.kr (8.12.10/8.12.10) with ESMTP id jA25theh021132 for ; Wed, 2 Nov 2005 14:55:43 +0900 (KST) Message-ID: <43684F30.3679C5A8@pec.etri.re.kr> Date: Wed, 02 Nov 2005 14:31:28 +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: v6ops@ops.ietf.org Subject: IEEE 802.16 access technology + IPv6 deployment Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Folks, I think v6ops is also interested in the draft - Scenarios and Considerations of IPv6 in IEEE 802.16 Networks http://www.ietf.org/internet-drafts/draft-shin-ipv6-ieee802.16-01.txt (The draft will be discussed in 16ng BoF (Tue.) at Vancouver.) IEEE 802.16 + IPv6 will be deployed as one of ISP Broadband Access Networks such as Cable/HFC, BB Ethernet, xDSL, WLAN, etc. So, I think IEEE 802.16 access technology should be also added for completeness into Any thoughts ? Thanks, Myung-Ki, From owner-v6ops@ops.ietf.org Thu Nov 03 19:57:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXpt9-0000vp-ON for v6ops-archive@megatron.ietf.org; Thu, 03 Nov 2005 19:57:03 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09808 for ; Thu, 3 Nov 2005 19:56:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXpot-0000i8-RE for v6ops-data@psg.com; Fri, 04 Nov 2005 00:52:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXpor-0000gk-4K for v6ops@ops.ietf.org; Fri, 04 Nov 2005 00:52:37 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 03 Nov 2005 16:52:37 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA40qYTH004996; Thu, 3 Nov 2005 16:52:34 -0800 (PST) Received: from [10.32.244.221] (stealth-10-32-244-221.cisco.com [10.32.244.221]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jA4120oU023602; Thu, 3 Nov 2005 17:02:00 -0800 Mime-Version: 1.0 (Apple Message framework v746.2) To: David Kessens Message-Id: <08A3A29C-322B-4592-BFA1-31122433F7E3@cisco.com> Content-Type: multipart/mixed; boundary=Apple-Mail-15-287013275 Cc: Bert Wijnen , v6ops@ops.ietf.org, iesg-secretary@ietf.org Subject: draft-ietf-v6ops-onlinkassumption-03.txt From: Fred Baker Date: Thu, 3 Nov 2005 16:52:32 -0800 X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=19102; t=1131066121; x=1131498321; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:draft-ietf-v6ops-onlinkassumption-03.txt| From:Fred=20Baker=20| Date:Thu,=203=20Nov=202005=2016=3A52=3A32=20-0800| Content-Type:multipart/mixed=3B=20boundary=3DApple-Mail-15-287013275; b=OtjrnaS7W936FVpySGpc2rFlnHfIzEsrPyDl2E5F8zJzoFAG6QIsijmPv5zKTA88XxYhTp3v /wVZmAQpLgysWIjDWjG2OAHo0tnwePD7FXDsdCAl40/8FIVMNLSEkv7pL6QqeUifHhpWwKHkhPm Btf9dYmHQHb0Rlfu8z9VwDQE= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( 29 extraneous bytes; message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk --Apple-Mail-15-287013275 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit David: It is my opinion that http://www.ietf.org/internet-drafts/draft-ietf-v6ops- onlinkassumption-03.txt "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", Sebastien Roy, 9-May-05 is ready for action by the IESG. The expected status of this document is INFORMATIONAL. My notes are attached. --Apple-Mail-15-287013275 Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-v6ops-onlinkassumption-03.txt" Content-Disposition: attachment; filename=draft-ietf-v6ops-onlinkassumption-03.txt Content-Transfer-Encoding: quoted-printable Network Working Group S. Roy Internet-Draft Sun Microsystems, Inc. Expires: October 3, 2005 A. Durand Comcast Corporation J. Paugh April 2005 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful draft-ietf-v6ops-onlinkassumption-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 October 3, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes the historical and background information behind the removal of the "on-link assumption" from the conceptual host sending algorithm defined in Neighbor Discovery for IP Version 6 (IPv6). According to the algorithm as originally described, when a host's default router list is empty, the host assumes that all destinations are on-link. This is particularly problematic with Roy, et al. Expires October 3, 2005 [Page 1] =0C Internet-Draft On-Link Assumption Harmful April 2005 IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router). This document describes how making this assumption causes problems, and describes how these problems outweigh the benefits of this part of the conceptual sending algorithm. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background on the On-link Assumption . . . . . . . . . . . . . 3 3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 First Rule of Destination Address Selection . . . . . . . 3 3.2 Delays Associated with Address Resolution . . . . . . . . 4 3.3 Multi-interface Ambiguity . . . . . . . . . . . . . . . . 5 3.4 Security Related Issues . . . . . . . . . . . . . . . . . 5 4. Changes to RFC2461 . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1 Normative References . . . . . . . . . . . . . . . . . . . 6 6.2 Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 B. Changes from draft-ietf-v6ops-onlinkassumption-02 . . . . . . 7 C. Changes from draft-ietf-v6ops-onlinkassumption-01 . . . . . . 8 D. Changes from draft-ietf-v6ops-onlinkassumption-00 . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 9 Roy, et al. Expires October 3, 2005 [Page 2] =0C Internet-Draft On-Link Assumption Harmful April 2005 1. Introduction Neighbor Discovery for IPv6 [I-D.ietf-ipv6-2461bis] defines a conceptual sending algorithm for hosts. The version of the algorithm described in [RFC2461] states that if a host's default router list is empty, then the host assumes that all destinations are on-link. This memo documents the removal of this assumption in the updated Neighbor Discovery specification [I-D.ietf-ipv6-2461bis], and describes the reasons why this assumption was removed. This assumption is problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity. This is typical when systems that have IPv6 enabled on their network interfaces (either on by default or administratively configured that way) are attached to networks that have no IPv6 services such as off-link routing. Such systems will resolve DNS names to AAAA and A records, and may attempt to connect to unreachable IPv6 off-link nodes. The on-link assumption creates problems for destination address selection as defined in [RFC3484], and adds connection delays associated with unnecessary address resolution and neighbor unreachability detection. The behavior associated with the assumption is undefined on multi-interface nodes, and has some subtle security implications. All of these issues are discussed in this document. 2. Background on the On-link Assumption This part of Neighbor Discovery's [RFC2461] conceptual sending algorithm was created to facilitate communication on a single link between systems manually configured with different global prefixes. For example, consider the case where two systems on separate links are manually configured with global addresses, and are then plugged in back-to-back. They can still communicate with each other via their global addresses because they'll correctly assume that each is on-link. Without the on-link assumption, the above scenario wouldn't work, and the systems would need to be configured to share a common prefix such as the link-local prefix. 3. Problems The on-link assumption causes the following problems. 3.1 First Rule of Destination Address Selection Default Address Selection for IPv6 [RFC3484] defines a destination Roy, et al. Expires October 3, 2005 [Page 3] =0C Internet-Draft On-Link Assumption Harmful April 2005 address selection algorithm that takes an unordered list of destination addresses as input, and produces a sorted list of destination addresses as output. The algorithm consists of destination address sorting rules, the first of which is "Avoid unusable destinations". The idea behind this rule is to place unreachable destinations at the end of the sorted list so that applications will be least likely to try to communicate with those addresses first. The on-link assumption could potentially cause false positives when attempting unreachability determination for this rule. On a network where there is no IPv6 router (all off-link IPv6 destinations are unreachable), the on-link assumption states that destinations are assumed to be on-link. An implementation could interpret that as, if the default router list is empty, then all destinations are reachable on-link. This may cause the rule to prefer an unreachable IPv6 destination over a reachable IPv4 destination. 3.2 Delays Associated with Address Resolution Users expect that applications quickly connect to a given destination regardless of the number of IP addresses assigned to that destination. If a destination name resolves to multiple addresses and the application attempts to communicate to each address until one succeeds, this process shouldn't take an unreasonable amount of time. It is therefore important that the system quickly determine if IPv6 destinations are unreachable so that the application can try other destinations when those IPv6 destinations are unreachable. For an IPv6 enabled host deployed on a network that has no IPv6 routers, the result of the on-link assumption is that link-layer address resolution must be performed on all IPv6 addresses to which the host sends packets. 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). This is greatly amplified by transport protocol delays. For example, [RFC1122] requires that TCP retransmit for at least 3 minutes before aborting the connection attempt. When the application has a large list of off-link unreachable IPv6 addresses followed by at least one reachable IPv4 address, the delay associated with Neighbor Unreachability Detection (NUD) of each IPv6 addresses before successful communication with the IPv4 address is unacceptable. Roy, et al. Expires October 3, 2005 [Page 4] =0C Internet-Draft On-Link Assumption Harmful April 2005 3.3 Multi-interface Ambiguity There is no defined way to implement this aspect of the sending algorithm on a node that is attached to multiple links. =46rom an implementor's point of view, there are three ways to handle sending an IPv6 packet to a destination in the face of the on-link assumption on a multi-interface node: 1. Attempt to resolve the destination on a single link. 2. Attempt to resolve the destination on every link. 3. Drop the packet. If the destination is indeed on-link, the first option might not succeed since the wrong link could be picked. The second option might succeed in reaching a destination (assuming that one is reachable) but is more complex to implement, and isn't guaranteed to pick the correct destination. For example, there is still ambiguity about which link to use if more than one node answers the solicitations on multiple links. Dropping the packet is equivalent to not making the on-link assumption at all. In other words, if there is no route to the destination, don't attempt to send the packet. 3.4 Security Related Issues The on-link assumption discussed here introduces a security vulnerability to the Neighbor Discovery protocol described in section 4.2.2 of IPv6 Neighbor Discovery Trust Models and Threats [RFC3756] titled "Default router is 'killed'". There is a threat that a host's router can be maliciously killed in order to cause the host to start sending all packets on-link. The attacker can then spoof off-link nodes by sending packets on the same link as the host. The vulnerability is discussed in detail in [RFC3756]. Another security related side-effect of the on-link assumption has to do with virtual private networks (VPN's). It has been observed that some commercially available VPN software solutions that don't support IPv6 send IPv6 packets to the local media in the clear (their security policy doesn't simply drop IPv6 packets). Consider a scenario where a system has a single Ethernet interface with VPN software that encrypts and encapsulates certain packets. The system attempts to send a packet to an IPv6 destination that it obtained by doing a DNS lookup, and the packet ends up going in the clear to the local media. A malicious third party could then spoof the destination on-link. Roy, et al. Expires October 3, 2005 [Page 5] =0C Internet-Draft On-Link Assumption Harmful April 2005 4. Changes to RFC2461 The following changes have been made to the Neighbor Discovery specification between [RFC2461] and [I-D.ietf-ipv6-2461bis]: The last sentence of the second paragraph of section 5.2 ("Conceptual Sending Algorithm") was removed. This sentence was, "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") was removed. The item read, "If the Default Router List is empty, assume that all destinations are on-link as specified in Section 5.2." APPENDIX A was modified to remove on-link assumption related text in bullet item 1) under the discussion on what happens when a multihomed host fails to receive Router Advertisements. The result of these changes is that destinations are considered unreachable when there is no routing information for that destination (through a default router or otherwise). Instead of attempting link- layer address resolution when sending to such a destination, a node should send an ICMPv6 Destination Unreachable message (code 0 - no route to destination) message up the stack. 5. Security Considerations The removal of the on-link assumption from Neighbor Discovery removes some security related vulnerabilities of the protocol as described in Section 3.4. 6. References 6.1 Normative References [I-D.ietf-ipv6-2461bis] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", draft-ietf-ipv6-2461bis-02 (work in progress), February 2005. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. Roy, et al. Expires October 3, 2005 [Page 6] =0C Internet-Draft On-Link Assumption Harmful April 2005 [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 6.2 Informative References [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. Authors' Addresses Sebastien Roy Sun Microsystems, Inc. 1 Network Drive UBUR02-212 Burlington, MA 01801 Email: sebastien.roy@sun.com Alain Durand Comcast Corporation 1500 Market St. Philadelphia, PA 09102 Email: alain_durand@cable.comcast.com James Paugh Email: jpaugh@speakeasy.net Appendix A. Acknowledgments The authors gratefully acknowledge the contributions of Jim Bound, Tony Hain, Mika Liljeberg, Erik Nordmark, Pekka Savola, and Ronald van der Pol. Appendix B. Changes from draft-ietf-v6ops-onlinkassumption-02 o Changed abstract to reflect the historical nature of this document. Roy, et al. Expires October 3, 2005 [Page 7] =0C Internet-Draft On-Link Assumption Harmful April 2005 o Changed the introduction to stress that this is historical information documenting the removal of the on-link assumption from the ND spec. o Added text to the introduction stating that the assumption is a problem for nodes with IPv6 on by default. o Added mention to RFC1122 in section 3.2. o Changed use of the term multi-homed nodes to "nodes that are attached to multiple links". o Changed section 4 from "Proposed Changes" to "Changes" and adjusted included text to reflect that the changes have been made. Appendix C. Changes from draft-ietf-v6ops-onlinkassumption-01 o Added text in the Introduction stating that rfc2461bis has removed the on-link assumption, and that this memo gives the historical reference and background for its removal. o Stated in Section 2 that users may not have sufficient privileges or knowledge to manually configure addresses or routers in order to work-around the lack of an on-link assumption. o Removed implementation details of the on-link assumption from Section 3.1. o Miscellaneous editorial changes. Appendix D. Changes from draft-ietf-v6ops-onlinkassumption-00 o Clarified in the abstract and introduction that the problem is with systems that are IPv6 enabled but have no off-link connectivity. o In Section 3.3, clarified that soliciting on all links could have ambiguous results. o The old Security Considerations section was moved to Section 3.4, and the new Security Considerations section refers to that new section. o Miscellaneous editorial changes. Roy, et al. Expires October 3, 2005 [Page 8] =0C Internet-Draft On-Link Assumption Harmful April 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Roy, et al. Expires October 3, 2005 [Page 9] =0C --Apple-Mail-15-287013275 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-15-287013275 Content-Type: text/plain; x-mac-type=54455854; x-unix-mode=0644; name="draft-ietf-v6ops-onlinkassumption-writeup.txt" Content-Disposition: attachment; filename=draft-ietf-v6ops-onlinkassumption-writeup.txt Content-Transfer-Encoding: 7bit 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? I, Fred Baker, have read the document and believe that it is ready for IESG review and action. 1.b) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Yes, it has, and has had cooperative discussion and as a result has changed some of the text of the update to RFC 2461. I believe that the discussion has been fruitful. 1.c) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No. 1.d) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. No, I do not. I believe that in its present form it conveys the information appropriate to future engineers who work on related topics. 1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The working group understands and agrees with the document. 1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. No. 1.g) Have the chairs verified that the document adheres to all of the ID nits? (see http://www.ietf.org/ID-Checklist.html). The web page reports: idnits 1.82 tmp/draft-ietf-v6ops-onlinkassumption-03.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: * The document seems to lack an IANA Considerations section. Checking conformance with RFC 3978/3979 boilerplate... the boilerplate looks good. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. Run idnits with the --verbose option for more detailed information. 1.h) Is the document split into normative and informative references? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) The document is indeed divided into normative and informative references. The one normative reference to an internet draft is to ietf-ipv6-2461bis, which is in the state "Publication requested". I believe that these two documents should be published together. 1.i) For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: This is an informational document, supportive of some of the changes in ietf-ipv6-2461bis and in changes that have resulted in other documents. It is being published for its historical value. The abstract reads: This document describes the historical and background information behind the removal of the "on-link assumption" from the conceptual host sending algorithm defined in Neighbor Discovery for IP Version 6 (IPv6). According to the algorithm as originally described, when a host's default router list is empty, the host assumes that all destinations are on-link. This is particularly problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router). This document describes how making this assumption causes problems, and describes how these problems outweigh the benefits of this part of the conceptual sending algorithm. The suggested change has been implemented, and therefore tested, in Solaris 10. --Apple-Mail-15-287013275 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit -------------------------------------------------------------- "Don't worry about the world coming to an end today. It's already tomorrow in Australia." (Charles Schulz ) --Apple-Mail-15-287013275-- From owner-v6ops@ops.ietf.org Thu Nov 03 19:57:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXptI-0000wi-Lh for v6ops-archive@megatron.ietf.org; Thu, 03 Nov 2005 19:57:13 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09829 for ; Thu, 3 Nov 2005 19:56:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXpp2-0000m9-5y for v6ops-data@psg.com; Fri, 04 Nov 2005 00:52:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXpos-0000gk-1o for v6ops@ops.ietf.org; Fri, 04 Nov 2005 00:52:38 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 03 Nov 2005 16:52:38 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA40qZVR001694; Thu, 3 Nov 2005 16:52:36 -0800 (PST) Received: from [10.32.244.221] (stealth-10-32-244-221.cisco.com [10.32.244.221]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jA4120oV023602; Thu, 3 Nov 2005 17:02:02 -0800 Mime-Version: 1.0 (Apple Message framework v746.2) To: David Kessens Message-Id: <1FBB8919-5F1B-4DBA-A63D-25904C36F057@cisco.com> Content-Type: multipart/mixed; boundary=Apple-Mail-16-287014711 Cc: Bert Wijnen , iesg-secretary@ietf.org, v6ops@ops.ietf.org Subject: draft-ietf-v6ops-vlan-usage-00.txt From: Fred Baker Date: Thu, 3 Nov 2005 16:52:33 -0800 X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=22941; t=1131066123; x=1131498323; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:draft-ietf-v6ops-vlan-usage-00.txt| From:Fred=20Baker=20| Date:Thu,=203=20Nov=202005=2016=3A52=3A33=20-0800| Content-Type:multipart/mixed=3B=20boundary=3DApple-Mail-16-287014711; b=BRclLEjVk9UhpUqJC0UkiYpT1k4XRasaeusObEinnMzHQsfvnzPBwrWHVKpTQ7qbh/HjGOSp L/tPtbha/LJpcMECrJhE95l+nnUlKXN25Fz5fB8vBTD0+XtnUlnJNx5nWvotj4Y0d+wmkQPlhYN yxpwp1cogdWt3eMfT8XpRljQ= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( 29 extraneous bytes; message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk --Apple-Mail-16-287014711 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit David: It is my opinion that http://www.ietf.org/internet-drafts/draft-ietf-v6ops-vlan- usage-00.txt "Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks", Tim Chown, 13-Jul-05 is ready for action by the IESG. The expected status of this document is INFORMATIONAL. My notes are attached. --Apple-Mail-16-287014711 Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-v6ops-vlan-usage-00.txt" Content-Disposition: attachment; filename=draft-ietf-v6ops-vlan-usage-00.txt Content-Transfer-Encoding: quoted-printable IPv6 Operations T. Chown Internet-Draft University of Southampton Expires: January 12, 2006 July 11, 2005 Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks draft-ietf-v6ops-vlan-usage-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 January 12, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Ethernet VLANs are quite commonly used in enterprise networks for the purposes of traffic segregation. This document describes how such VLANs can be readily used to deploy IPv6 networking in an enterprise, which focuses on the scenario of early deployment prior to availability of IPv6-capable switch-router equipment. In this method IPv6 may be routed in parallel with the existing IPv4 in the enterprise and delivered at Layer 2 via VLAN technology. The IPv6 connectivity to the enterprise may or may not enter the site via the same physical link. Chown Expires January 12, 2006 [Page 1] =0C Internet-Draft VLANs for IPv4-IPv6 Coexistence July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Enabling IPv6 per link . . . . . . . . . . . . . . . . . . . . 4 2.1 IPv6 routing over VLANs . . . . . . . . . . . . . . . . . 4 2.2 One VLAN per router interface . . . . . . . . . . . . . . 5 2.3 Collapsed VLANs on a single interface . . . . . . . . . . 5 2.4 Congruent IPv4 and IPv6 Subnets . . . . . . . . . . . . . 5 2.5 IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . 6 2.6 Final IPv6 Deployment . . . . . . . . . . . . . . . . . . 6 3. Example VLAN topology . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7. Informative References . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 A. Appendix: Configuration example . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 12 Chown Expires January 12, 2006 [Page 2] =0C Internet-Draft VLANs for IPv4-IPv6 Coexistence July 2005 1. Introduction Ethernet VLANs are quite commonly used in enterprise networks for the purposes of traffic segregation. This document describes how such VLANs can be readily used to deploy IPv6 networking in an enterprise, including the scenario of early deployment prior to availability of IPv6-capable switch-router equipment, where IPv6 may be routed in parallel with the existing IPv4 in the enterprise and delivered to the desired LANs via VLAN technology. It is expected that in the long run, sites migrating to dual-stack networking will either upgrade existing switch-router equipment to support IPv6 or procure new equipment that supports IPv6. If a site already has production routers deployed that support IPv6, the procedures described in this document are not required. In the interim however, a method is required for early IPv6 adopters that enables IPv6 to be deployed in a structured, managed way to some or all of an enterprise network which currently lacks IPv6 support in its core infrastructure. The IEEE 802.1Q VLAN standard allows separate LANs to be deployed over a single bridged LAN, by inserting "Virtual LAN" tagging or membership information into Ethernet frames. Hosts and switches that support VLANs effectively allow software-based reconfiguration of LANs through configuration of the tagging parameters. The software control means VLANs can be used to alter the LAN infrastructure without having to physically alter the wiring between the LAN segments and Layer 3 routers. Many IPv4 enterprise networks are utilising VLAN technology. Where a site does not have IPv6-capable Layer 2/3 switch-router equipment, but VLANs are supported, a simple yet effective method exists to gradually introduce IPv6 to some or all of that site's network, in advance of the site's core infrastructure having dual-stack capability. If such a site wishes to introduce IPv6, it may do so by deploying a parallel IPv6 routing infrastructure (which is likely to be a different platform to the site's main infrastructure equipment, i.e. one that supports IPv6 where the existing equipment does not), and then using VLAN technology to "overlay" IPv6 links onto existing IPv4 links. This can be achieved without needing any changes to the IPv4 configuration. The VLANs don't need to differentiate between IPv4 and IPv6; the deployment is just dual stack, as Ethernet is without VLANs. The IPv4 default route to the VLAN is provided by one (IPv4) router, while the IPv6 default route to the VLAN is provided a different Chown Expires January 12, 2006 [Page 3] =0C Internet-Draft VLANs for IPv4-IPv6 Coexistence July 2005 (IPv6) router. The IPv6 router can provide native IPv6 connectivity to the whole site with just a single physical interface, thanks to VLAN tagging and trunking, as described below. The IPv6 connectivity to the enterprise may or may not enter the site via the same physical link as the IPv4 traffic, and may be native or tunneled from the external provider to the IPv6 routing equipment. This VLAN usage is a solution adopted by a number of sites already, and is referenced in our Campus Network IPv6 Transition [2] text. It should be noted that a parallel infrastructure will require additional infrastructure and thus cost, and will often require a separate link into the site (from an IPv6 provider), quite possibly tunneled, that will require the site's security policy to be applied (e.g. firewalling, and intrusion detection). For sites who believe early adoption of IPv6 is important, that price is one they may be quite willing to pay. However, this document focuses on the technical issues of VLAN usage in such a scenario. 2. Enabling IPv6 per link The precise method by which IPv6 would be "injected" into the existing IPv4 network is deployment specific. For example, perhaps a site has an IPv4-only router, connected to an Ethernet switch that supports VLANs, and a number of hosts connected to that VLAN. Let's further assume the site has a dozen of these setups which it wishes to IPv6-enable immediately. This could be done by upgrading the twelve routers to support IPv6, and turning IPv6 on on those routers. However, this may not be practical for various reasons. The simplest approach would be to connect an IPv6 router with one interface to an ethernet switch, and connect that switch to other switches, and then use VLAN tags between the switches and the IPv6 router to "reach" all the IPv4-only subnets from the IPv6 router. Thus the general principle is that the IPv6 router device (e.g. performing IPv6 Router Advertisements [1] in the case of stateless autoconfiguration) is connected to the target link through the use of VLAN capable Layer 2 equipment. 2.1 IPv6 routing over VLANs In a typical scenario where connectivity is to be offered to a number of existing IPv6 internal subnets, one IPv6 router could be deployed, with both an external interface and one or more internal interfaces. The external interface connects to the wider IPv6 internet, and may be dual-stack if some tunnel mechanism is used for external connectivity, or IPv6-only if a native external connection is Chown Expires January 12, 2006 [Page 4] =0C Internet-Draft VLANs for IPv4-IPv6 Coexistence July 2005 available. The internal interface(s) can be connected directly to a VLAN-capable switch. It is then possible to write VLAN tags on the packets sent from the internal router interface based on the target IPv6 link prefix. The VLAN-tagged traffic is then transported across the internal VLAN-capable site infrastructure to the target IPv6 links (which may be dispersed widely across the site network). Where the IPv6 router is unable to VLAN-tag the packets, a protocol- based VLAN can be created on the VLAN-capable device connected to the IPv6 router, causing IPv6 traffic to be tagged and then redistributed on (congruent) IPv4 subnet links that lie in the same VLAN. 2.2 One VLAN per router interface The VLAN marking may be done in different ways. Some sites may prefer to use one router interface per VLAN, e.g. if there are three internal IPv6 links, a BSD-based IPv6 router with four Ethernet ports could be used, one for the external link and three for the internal links. In such a case one switch port would be needed per link, to receive the connectivity from each router port. In such a deployment, the IPv6 routing could be cascaded through lower tier internal IPv6-only routers. Here, the internal facing ports on the IPv6 edge router may feed other IPv6 routers over IPv6- only links which in turn inject the IPv6 connectivity (the /64 size links and associated Router Advertisements) into the VLANs. 2.3 Collapsed VLANs on a single interface Using multiple IPv6 routers and one port per IPv6 link (i.e. VLAN) may be unnecessary. Many devices now support VLAN tagging based on virtual interfaces such that multiple IPv6 VLANs could be assigned (trunked) from one physical router interface port. Thus it is possible to use just one router interface for "aggregated" VLAN trunking from a switch. This is a far more interesting case for a site planning the introduction of IPv6 to (part of) its site network. This approach is viable while IPv6 traffic load is light. As traffic volume grows, the single collapsed interface could be extended to utilise two or more physical ports, where the capacity of the IPv6 router device allows it. 2.4 Congruent IPv4 and IPv6 Subnets Such a VLAN-based technique can be used to deploy IPv6-only VLANs in an enterprise network. However most enterprises will be interested Chown Expires January 12, 2006 [Page 5] =0C Internet-Draft VLANs for IPv4-IPv6 Coexistence July 2005 in dual-stack IPv4-IPv6 networking. In such a case the IPv6 connectivity may be injected into the existing IPv4 VLANs, such that the IPv4 and IPv6 subnets are congruent (i.e. they coincide exactly when superimposed). Such a method may have desirable administrative properties, e.g. the devices in each IPv4 subnet will be in the same IPv6 subnets also. This is the method being used in our Campus Network IPv6 Transition [2] text. Further, IPv6-only devices may be gradually added into the subnet without any need to resize the IPv6 subnet (which may hold in effect an infinite number of hosts in a /64 in contrast to IPv4 where the subnet size is often relatively limited, or kept to a minimum possible due to address space usage concerns). The lack of requirement to periodically resize an IPv6 subnet is a useful administrative advantage for IPv6. 2.5 IPv6 Addressing One site using this VLAN technique has chosen to number its IPv6 links with the format [Site IPv6 prefix]:[VLAN ID]::/64. This is not a recommended addressing plan, but some sites may wish to consider its usage. 2.6 Final IPv6 Deployment The VLAN technique for IPv6 deployment offers a more structured alternative to opportunistic per-host intra-site tunnelling methods such as ISATAP [3]. It has the ability to offer a simple yet efficient method for early IPv6 deployment to an enterprise site. When the site acquires IPv6-capable switch-router equipment, the VLAN-based mathod can still be used for delivery of IPv6 links to physical switch interfaces, just as it is commonly today for IPv4 subnets, but with a common routing infrastructure. Chown Expires January 12, 2006 [Page 6] =0C Internet-Draft VLANs for IPv4-IPv6 Coexistence July 2005 3. Example VLAN topology The following figure shows how a VLAN topology may be used to introduce IPv6 in an enterprise network, using a parallel IPv6 routing infrastructure and VLAN tagging. External IPv6 Internet | | IPv6 Access Router | | Switch-router with VLAN support | | +--------------+----------------+ |Site enterprise infrastructure | | with support for VLANs | +----+--------------------+-----+ | | | | VLAN switch A VLAN switch B | | | | | | Subnet1 Subnet2 Subnet3 Figure 1: IPv6 deployment using VLANs (physical diagram) In this scenario, the IPv6 access router has one physical port facing towards the internal infrastructure. In this example it need only be IPv6-enabled, as its purpose is solely to handle IPv6 traffic for the enterprise. The access router has an additional interface facing towards the external infrastructure, which in this example could be dual-stack if the external IPv6 connectivity is via a tunnel to an IPv6 ISP. A number of VLANs are handled by the internal-facing IPv6 router port; in this case IPv6 links Subnet1, Subnet2, Subnet3. The VLANs are seen as logical subinterfaces of the physical interface on the IPv6 access router, which is using the "collapsed VLAN" method described above, tagging the inbound traffic with one of three VLAN IDs depending on the target IPv6 Subnet prefix. Chown Expires January 12, 2006 [Page 7] =0C Internet-Draft VLANs for IPv4-IPv6 Coexistence July 2005 The following figure shows how the IPv6 view of the deployment looks; all IPv6 subnets are on-link to the IPv6 access router, whether they share the same physical links over the VLAN infrastructure or not. External IPv6 Internet | | Site IPv6 Access Router | | | | | | Subnet1 Subnet2 Subnet3 Figure 2: IPv6 view of the deployment (logical view) In this example, the router acts as an IPv6 first-hop access router to the physical links, separately from the IPv4-first hop router. This technique allows a site to easily "inject" native IPv6 into all the links where a VLAN-capable infrastructure is available, enabling partial or full IPv6 deployment on the wire in a site. 4. IANA Considerations There are no considerations for IANA in this document. 5. Security Considerations There are no additional security considerations particular to this method of enabling IPv6 on a link. Where the IPv6 connectivity is delivered into the enterprise network by a different path from the IPv4 connectivity, care should be given that equivalent application of security policy (e.g. firewalling) is made to the IPv6 path. 6. Acknowledgements The author would like to thank colleagues on the 6NET project, where this technique for IPv4-IPv6 coexistence is widely deployed, in particular Pekka Savola (CSC/FUNET), but also including Janos Mohacsi (Hungarnet), Martin Dunmore and Chris Edwards (Lancaster University), Christian Strauf (JOIN Project, University of Muenster) and Stig Venaas (UNINETT). Chown Expires January 12, 2006 [Page 8] =0C Internet-Draft VLANs for IPv4-IPv6 Coexistence July 2005 7. Informative References [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [2] Chown, T., "IPv6 Campus Transition Scenario Description and Analysis", draft-chown-v6ops-campus-transition-01 (work in progress), October 2004. [3] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", draft-ietf-ngtrans-isatap-24 (work in progress), January 2005. Author's Address Tim Chown University of Southampton Southampton, Hampshire SO17 1BJ United Kingdom Email: tjc@ecs.soton.ac.uk Appendix A. Appendix: Configuration example In this section we describe a configuration example for BSD to deploy IPv6 networking across a number of IPv6 links on an enterprise (in this case, six links), for a scenario similar to the one described above. Here the precise configuration may of course vary depending on the existing site VLAN deployment. This section highlights that the VLAN configuration must be manually configured; the support is not "automatic". In this example, the configuration is for an IPv6 BSD router connected directly to a site's external IPv6 access router. The BSD router has one interface (dc0) towards the site IPv6access router, and three interfaces (dc1, dc2, dc3) over which the internal routing is performed (the number of interfaces can be varied, three are used here to distribute the traffic load). The IPv6 documentation prefix (2001:db8::/32) is used in the example. --- Example IPv6 VLAN configuration, FreeBSD --- # # To IPv6 enable a vlan # Chown Expires January 12, 2006 [Page 9] =0C Internet-Draft VLANs for IPv4-IPv6 Coexistence July 2005 # 1. Add a new vlan device to cloned_interfaces called vlanX # # 2. Add an ifconfig_vlanX line, the number is the vlan tag ID # # 3. Add vlanX to ipv6_network_interfaces # # 4. Add an ipv6_ifconfig_vlanX line, with a new unique prefix # # 5. Add vlanX to rtadvd_interface # # 6. Add vlanX to ipv6_router_flags ### Interfaces ### # Bring physical interfaces up ifconfig_dc0=3D"up" ifconfig_dc1=3D"up" ifconfig_dc2=3D"up" ifconfig_dc3=3D"up" # Create VLan interfaces cloned_interfaces=3D"vlan0 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6" # Upstream link to IPv6 Access Router ifconfig_vlan0=3D"vlan 37 vlandev dc0" # Downstream interfaces, load balance over interfaces dc1,dc2,dc3 ifconfig_vlan1=3D"vlan 11 vlandev dc1" # Subnet1 ifconfig_vlan2=3D"vlan 17 vlandev dc2" # Subnet2 ifconfig_vlan3=3D"vlan 24 vlandev dc3" # Subnet3 ifconfig_vlan4=3D"vlan 25 vlandev dc1" # Subnet4 ifconfig_vlan5=3D"vlan 34 vlandev dc2" # Subnet5 ifconfig_vlan6=3D"vlan 14 vlandev dc3" # Subnet6 ### IPv6 ### # Enable ipv6 ipv6_enable=3D"YES" # Forwarding ipv6_gateway_enable=3D"YES" # Define Interfaces ipv6_network_interfaces=3D"vlan0 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6" # Define addresses ipv6_ifconfig_vlan0=3D"2001:db8:d0:101::2 prefixlen 64" # Uplink ipv6_ifconfig_vlan1=3D"2001:db8:d0:111::1 prefixlen 64" # Subnet1 ipv6_ifconfig_vlan2=3D"2001:db8:d0:112::1 prefixlen 64" # Subnet2 Chown Expires January 12, 2006 [Page 10] =0C Internet-Draft VLANs for IPv4-IPv6 Coexistence July 2005 ipv6_ifconfig_vlan3=3D"2001:db8:d0:121::1 prefixlen 64" # Subnet3 ipv6_ifconfig_vlan4=3D"2001:db8:d0:113::1 prefixlen 64" # Subnet4 ipv6_ifconfig_vlan5=3D"2001:db8:d0:114::1 prefixlen 64" # Subnet5 ipv6_ifconfig_vlan6=3D"2001:db8:d0:115::1 prefixlen 64" # Subnet6 # Router advs rtadvd_enable=3D"YES" rtadvd_interfaces=3D"-s vlan0 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6" ### Routing ### # Multicast mroute6d_enable=3D"YES" mroute6d_program=3D"/sbin/pim6sd" # RIP-ng ipv6_router_enable=3D"YES" ipv6_router_flags=3D"-N = dc0,dc1,dc2,dc3,vlan1,vlan2,vlan3,vlan4,vlan5,vlan6" --- End of configuration --- Note that if there was only one internal facing interface, then again so long as the OS supported VLAN trunking, all the VLAN IDs could be associated to that interface (dc1, for example). The VLAN IDs need to be managed by the site administrator, but would probably already be assigned for existing IPv4 subnets (ones into which IPv6 is being introduced). For a large enterprise, a combination of internal tunnels and VLAN usage could be used; the whole site need not be enabled by VLAN tagging alone. This choice is one for the site administrator to make. Chown Expires January 12, 2006 [Page 11] =0C Internet-Draft VLANs for IPv4-IPv6 Coexistence July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Chown Expires January 12, 2006 [Page 12] =0C --Apple-Mail-16-287014711 Content-Type: text/plain; x-mac-type=54455854; x-unix-mode=0644; name="draft-ietf-v6ops-vlan-usage-writeup.txt" Content-Disposition: attachment; filename=draft-ietf-v6ops-vlan-usage-writeup.txt Content-Transfer-Encoding: 7bit 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? I, Fred Baker, have read the document, and feel that it is ready for IESG review and action. 1.b) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? I believe that it has. It grew out of research in the 6NET environment carried on by the author and a variety of others, and documents the experience of that team. So the team has been integral to the development of the document and to its review. Also, there has been opportunity to comment on the v6ops WG list, and others have seen the document as well. That said, there has not been excessive commentary other than that of Pekka Savola as chair, as the document is of high quality and has not needed a lot of polishing. 1.c) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No. 1.d) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. No. 1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There was a show of hands at IETF62 from which we decided to last call it indicating a high level of support. There were no last call comments. 1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. No. 1.g) Have the chairs verified that the document adheres to all of the ID nits? (see http://www.ietf.org/ID-Checklist.html). Yes. The current idnits tool reports an issue which the one extant when the draft was posted did not report, which is a matter of a line being too long. I believe that the RFC Editor is competent to handle that issue. idnits 1.82 tmp/draft-ietf-v6ops-vlan-usage-00.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... the boilerplate looks good. * There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. Run idnits with the --verbose option for more detailed information. 1.h) Is the document split into normative and informative references? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) All references are informative (though the RFC Editor could add a normative one for the VLAN specification if that was felt useful). 1.i) For Standards Track and BCP documents, the IESG approval announcement includes a write-up section... This is an informaitonal document. The abstract reads: Ethernet VLANs are quite commonly used in enterprise networks for the purposes of traffic segregation. This document describes how such VLANs can be readily used to deploy IPv6 networking in an enterprise, which focuses on the scenario of early deployment prior to availability of IPv6-capable switch-router equipment. In this method IPv6 may be routed in parallel with the existing IPv4 in the enterprise and delivered at Layer 2 via VLAN technology. The IPv6 connectivity to the enterprise may or may not enter the site via the same physical link. --Apple-Mail-16-287014711 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit -------------------------------------------------------------- "Don't worry about the world coming to an end today. It's already tomorrow in Australia." (Charles Schulz ) --Apple-Mail-16-287014711-- From owner-v6ops@ops.ietf.org Thu Nov 03 19:57:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXptU-0000xy-7z for v6ops-archive@megatron.ietf.org; Thu, 03 Nov 2005 19:57:25 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09855 for ; Thu, 3 Nov 2005 19:56:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXpoy-0000kF-Rx for v6ops-data@psg.com; Fri, 04 Nov 2005 00:52:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXpou-0000iC-S0 for v6ops@ops.ietf.org; Fri, 04 Nov 2005 00:52:41 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 03 Nov 2005 16:52:40 -0800 X-IronPort-AV: i="3.97,289,1125903600"; d="txt'?scan'208"; a="360607090:sNHT67386904" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA40qcVR001720; Thu, 3 Nov 2005 16:52:38 -0800 (PST) Received: from [10.32.244.221] (stealth-10-32-244-221.cisco.com [10.32.244.221]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jA4120oW023602; Thu, 3 Nov 2005 17:02:03 -0800 Mime-Version: 1.0 (Apple Message framework v746.2) To: David Kessens Message-Id: Content-Type: multipart/mixed; boundary=Apple-Mail-17-287016294 Cc: v6ops@ops.ietf.org, iesg-secretary@ietf.org, Bert Wijnen Subject: draft-ietf-v6ops-natpt-to-exprmntl-03.txt From: Fred Baker Date: Thu, 3 Nov 2005 16:52:35 -0800 X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=55811; t=1131066126; x=1131498326; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:draft-ietf-v6ops-natpt-to-exprmntl-03.txt| From:Fred=20Baker=20| Date:Thu,=203=20Nov=202005=2016=3A52=3A35=20-0800| Content-Type:multipart/mixed=3B=20boundary=3DApple-Mail-17-287016294; b=NtysblcLv97zxelToHVq9uBgsfHiAxpuTF8nqPmXVmcnFSZ3nYYTCdyMx2tjbnsef8E4gUcl TfDISDMLmym6FILDIR2Be8orrK+srLGZE9sGzv99DEG4bvyn0JwfWwnv5YUYHDS5826rdR5bXPr VgVUf64ZIxjEjv4qlnpDV+xM= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( 29 extraneous bytes; message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk --Apple-Mail-17-287016294 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit David: It is my opinion that http://www.ietf.org/internet-drafts/draft-ietf-v6ops-natpt-to- exprmntl-03.txt "Reasons to Move NAT-PT to Experimental", Cedric Aoun, Elwyn Davies, 21-Oct-05 is ready for action by the IESG. The expected status of this document is INFORMATIONAL; the expected resulting status of RFC 2766 is EXPERIMENTAL. My notes are attached. --Apple-Mail-17-287016294 Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-v6ops-natpt-to-exprmntl-03.txt" Content-Disposition: attachment; filename=draft-ietf-v6ops-natpt-to-exprmntl-03.txt Content-Transfer-Encoding: quoted-printable v6ops Working Group C. Aoun Internet-Draft ZTE/ENST Paris Updates: 2766 (if approved) E. Davies Expires: April 23, 2006 Consultant October 20, 2005 Reasons to Move NAT-PT to Experimental draft-ietf-v6ops-natpt-to-exprmntl-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 April 23, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document discusses issues with the specific form of IPv6-IPv4 protocol translation mechanism implemented by the Network Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766. These issues are sufficiently serious that recommending RFC 2766 as a general purpose transition mechanism is no longer desirable, and this document recommends that the IETF should reclassify RFC 2766 from Standards Track to Experimental status. Aoun & Davies Expires April 23, 2006 [Page 1] =0C Internet-Draft NAT-PT Issues Analysis October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Issues Unrelated to DNS-ALG . . . . . . . . . . . . . . . . . 6 2.1. Issues with Protocols Embedding IP Addresses . . . . . . . 6 2.2. NAPT-PT Redirection Issues . . . . . . . . . . . . . . . . 7 2.3. NAT-PT Binding State Decay . . . . . . . . . . . . . . . . 8 2.4. Loss of Information through Incompatible Semantics . . . . 8 2.5. NAT-PT and Fragmentation . . . . . . . . . . . . . . . . . 9 2.6. NAT-PT Interaction with SCTP and Multihoming . . . . . . . 10 2.7. NAT-PT as a Proxy Correspondent Node for MIPv6 . . . . . . 11 2.8. NAT-PT and Multicast . . . . . . . . . . . . . . . . . . . 12 3. Issues exacerbated by the Use of DNS-ALG . . . . . . . . . . . 12 3.1. Network Topology Constraints Implied by NAT-PT . . . . . . 12 3.2. Scalability and Single Point of Failure Concerns . . . . . 14 3.3. Issues with Lack of Address Persistence . . . . . . . . . 14 3.4. DoS Attacks on Memory and Address/Port Pools . . . . . . . 15 4. Issues Directly Related to Use of DNS-ALG . . . . . . . . . . 16 4.1. Address Selection Issues when Communicating with Dual-Stack End-Hosts . . . . . . . . . . . . . . . . . . . 16 4.2. Non-global Validity of Translated RR Records . . . . . . . 17 4.3. Inappropriate Translation of Responses to A Queries . . . 18 4.4. DNS-ALG and Multi-addressed Nodes . . . . . . . . . . . . 18 4.5. Limitations on Deployment of DNS Security Capabilities . . 18 5. Impact on IPv6 Application Development . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 25 Aoun & Davies Expires April 23, 2006 [Page 2] =0C Internet-Draft NAT-PT Issues Analysis October 2005 1. Introduction The Network Address Translator - Protocol Translator (NAT-PT) document [RFC2766] defines a set of network-layer translation mechanisms designed to allow nodes that only support IPv4 to communicate with nodes that only support IPv6 during the transition to the use of IPv6 in the Internet. [RFC2766] specifies the basic NAT-PT in which only addresses are translated and Network Address Port Translator - Protocol Translator (NAPT-PT), which also translates transport identifiers, allowing for greater economy of scarce IPv4 addresses. Protocol translation is performed using the Stateless IP/ICMP Translation Algorithm (SIIT) defined in [RFC2765]. In the following discussion, where the term "NAT-PT" is used unqualified, the discussion applies to both basic NAT-PT and NAPT-PT. "Basic NAT-PT" will be used if points apply to the basic address-only translator. A number of previous documents have raised issues with NAT-PT. This document will summarize these issues, note several other issues carried over from traditional IPv4 NATs, and identify some additional issues that have not been discussed elsewhere. Where solutions to the issues have been proposed, these are mentioned and any resulting need for changes to the specification is identified. Whereas NAT is seen as an ongoing capability that is needed to work around the limited availability of globally unique IPv4 addresses, NAT-PT has a different status as a transition mechanism for IPv6. As such, NAT-PT should not be allowed to constrain the development of IPv6 applications or impose limitations on future developments of IPv6. This document draws the conclusion that the technical and operational difficulties resulting from these issues, especially the possible future constraints on the development of IPv6 networks (see Section 5), make it undesirable to recommend NAT-PT as described in [RFC2766] as a general purpose transition mechanism for intercommunication between IPv6 networks and IPv4 networks. Although the [RFC2766] form of packet translation is not generally applicable, it is likely that in some circumstances a node that can only support IPv4 will need to communicate with a node that can only support IPv6; this needs a translation mechanism of some kind. Although this may be better carried out by an application-level proxy or transport-layer translator, there may still be scenarios in which a (possibly restricted) version of NAT-PT can be a suitable solution; accordingly, this document recommends that the IETF should reclassify RFC2766 from Standards Track to Experimental status. Aoun & Davies Expires April 23, 2006 [Page 3] =0C Internet-Draft NAT-PT Issues Analysis October 2005 The following documents relating directly to NAT-PT have been reviewed while drafting this document: o Network Address Translation - Protocol Translation (NAT-PT) [RFC2766] o Stateless IP/ICMP Translation Algorithm (SIIT) [RFC2765] o NAT-PT applicability statement [I-D.satapati-v6ops-natpt- applicability] o Issues with NAT-PT DNS ALG in RFC2766 [I-D.durand-natpt-dns-alg- issues] o NAT-PT DNS ALG solutions [I-D.hallin-natpt-dns-alg-solutions] o NAT-PT Security Considerations [I-D.okazaki-v6ops-natpt-security] o Issues when translating between IPv4 and IPv6 [I-D.vanderpol- v6ops-translation-issues] o IPv6-IPv4 Translation mechanism for SIP-based services in Third Generation Partnership Project (3GPP) Networks [I-D.elmalki- sipping-3gpp-translator] o Analysis on IPv6 Transition in 3GPP Networks [I-D.ietf-v6ops-3gpp- analysis] o Considerations for Mobile IP Support in NAT-PT [I-D.lee-v6ops- natpt-mobility] o An IPv6/IPv4 Multicast Translator based on Internet Group Management Protocol / Multicast Listener Discovery (IGMP/MLD) Proxying (mtp) [I-D.tsuchiya-mtp] o An IPv4 - IPv6 multicast gateway [I-D.venaas-mboned-v4v6mcastgw] o Scalable mNAT-PT Solution [I-D.park-scalable-multi-natpt] Because the majority of the documents containing discussions of the issues are Internet Drafts which are unlikely to become RFCs, the issues are summarized here to avoid the need for normative references. Some additional issues can be inferred from corresponding issues known to exist in 'traditional' IPv4 NATs. The following documents are relevant: o Protocol Complications with the IP Network Address Translator [RFC3027] o IP Network Address Translator (NAT) Terminology and Considerations [RFC2663] There is some ambiguity in [RFC2766] about whether the Application Layer Gateway (ALG) for DNS (referred to as DNS-ALG in this document) is an integral and mandatory part of the specification. The ambiguity arises mainly from the first section of the applicability section (Section 8), which appears to imply that 'simple' use of NAT-PT could avoid the use of the DNS-ALG. Aoun & Davies Expires April 23, 2006 [Page 4] =0C Internet-Draft NAT-PT Issues Analysis October 2005 This is important because a number of the major issues arise from the interactions between DNS and NAT-PT. However, detailed inspection of [RFC2766] shows that the 'simple' case has not been worked out and it is unclear how information about the address translation could be passed to the hosts in the absence of the DNS-ALG. Therefore, this document assumes that the DNS-ALG is an integral part of NAT-PT; accordingly, issues with the DNS-ALG must be considered as issues for the whole specification. Note that issues not specifically related to the use of the DNS-ALG will apply to any network-layer translation scheme, including any based on the SIIT algorithm [RFC2765]. In the event that new forms of translator are developed as alternatives to NAT-PT, the generic issues relevant to all IPv6-IPv4 translators should be borne in mind. Issues raised with IPv6-IPv4 translators in general and NAT-PT in particular can be categorized as follows: o Issues that are independent of the use of a DNS-ALG and are, therefore, applicable to any form of IPv6-IPv4 translator: * Disruption of all protocols that embed IP addresses (and/or ports) in packet payloads or apply integrity mechanisms using IP addresses (and ports). * Inability to re-direct traffic for protocols that lack demultiplexing capabilities or are not built on top of specific transport-layer protocols in situations where one NAPT-PT is translating for multiple IPv6 hosts. * Requirement for applications to use keep alive mechanisms to workaround connectivity issues caused by premature NAT-PT state timeout. * Loss of information due to incompatible semantics between IPv4 and IPv6 versions of headers and protocols. * Need for additional state and/or packet reconstruction in NAPT-PT translators dealing with packet fragmentation. * Interaction with SCTP and multihoming. * Need for NAT-PT to act as proxy for correspondent node when IPv6 node is mobile, with consequent restrictions on mobility. * NAT-PT not being able to handle multicast traffic. o Issues that are exacerbated by the use of a DNS-ALG and are, therefore, also applicable to any form of IPv6-IPv4 translator: * Constraints on network topology. * Scalability concerns together with introduction of single point of failure and security attack nexus. * Lack of address mapping persistence: Some applications require address retention between sessions. The user traffic will be disrupted if a different mapping is used. The use of the DNS- ALG to create address mappings with limited lifetimes means Aoun & Davies Expires April 23, 2006 [Page 5] =0C Internet-Draft NAT-PT Issues Analysis October 2005 that applications must start using the address shortly after the mapping is created, as well as keeping it alive once they start using it. * Creation of a DoS threat relating to exhaustion of memory and address/port pool resources on the translator. o Issues that result from the use of a DNS-ALG and are, therefore, specific to NAT-PT as defined in [RFC2766]: * Address selection issues when either the internal or external hosts implement both IPv4 and IPv6. * Restricted validity of translated DNS records: a translated record may be forwarded to an application that cannot use it. * Inappropriate translation of responses to A queries from IPv6 nodes. * Address selection issues and resource consumption in DNS-ALG with multi-addressed nodes. * Limitations on DNS security capabilities when using DNS-ALG. Section 2, Section 3 and Section 4 discuss these groups of issues. Section 5 examines the consequences of deploying NAT-PT for application developers and the long term effects of NAT-PT (or any form of generally deployed IPv6-IPv4 translator) on the further development of IPv6. The terminology used in this document is defined in [RFC2663], [RFC2766], and [RFC3314]. 2. Issues Unrelated to DNS-ALG 2.1. Issues with Protocols Embedding IP Addresses It is well known from work on IPv4 NATs (see Section 8 of [RFC2663] and [RFC3027]) that the large class of protocols that embed numeric IP addresses in their payloads either cannot work through NATs or require specific ALGs as helpers to translate the payloads in line with the address and port translations. The same set of protocols cannot pass through NAT-PT. The problem is exacerbated because the IPv6 and IPv4 addresses are of different lengths so that packet lengths as well as contents are altered. [RFC2766] describes the consequences as part of the description of the FTP ALG: similar workarounds are needed for all protocols with embedded IP addresses that run over TCP transports. The issues raised in Sections 2 and 3 of [RFC2663], relating to authentication and encryption with NAT, are also applicable to NAT-PT. Aoun & Davies Expires April 23, 2006 [Page 6] =0C Internet-Draft NAT-PT Issues Analysis October 2005 Implementing a suite of ALGs requires that NAT-PT equipment includes the logic for each of the relevant protocols. Most of these protocols are continuously evolving, requiring continual and coordinated updates of the ALGs to keep them in step. Assuming that the NAT-PT contains a co-located ALG for one of the relevant protocols, the ALG could replace the embedded IP addresses and ports. However, this replacement can only happen if no cryptographic integrity mechanism is used and the protocol messages are sent in the clear (i.e., not encrypted). A possible workaround relies on the NAT-PT being party to the security association used to provide authentication and/or encryption. NAT-PT would then be aware of the cryptographic algorithms and keys used to secure the traffic. It could then modify and re-secure the packets; this would certainly complicate network operations and provides additional points of security vulnerability. Unless UDP encapsulation is used for IPsec [RFC3498], traffic using IPsec AH (in transport and tunnel mode) and IPsec ESP (in transport mode) is unable to be carried through NAT-PT without terminating the security associations on the NAT-PT, due to their usage of cryptographic integrity protection. A related issue with DNS security is discussed in Section 4.5. 2.2. NAPT-PT Redirection Issues Section 4.2 of [RFC3027] discusses problems specific to RSVP and NATs, one of which is actually a more generic problem for all port translators. When several end-hosts are using a single NAPT-PT box, protocols that do not have a demultiplexing capability similar to transport-layer port numbers may be unable to work through NAPT-PT (and any other port translator) because there is nothing for NAPT-PT to use to identify the correct binding. This type of issue affects IPsec encrypted packets where the transport port is not visible (although it might be possible to use the Security Parameter Index (SPI) as an alternative demultiplexer) and protocols, such as RSVP, which are carried directly in IP datagrams rather than using a standard transport-layer protocol such as TCP or UDP. In the case of RSVP, packets going from the IPv4 domain to the IPv6 domain do not necessarily carry a suitable demultiplexing field, because the port fields in the flow identifier and traffic specifications are optional. Several ad hoc workarounds could be used to solve the demultiplexing issues, however in most cases these solutions are not documented Aoun & Davies Expires April 23, 2006 [Page 7] =0C Internet-Draft NAT-PT Issues Analysis October 2005 anywhere, which could lead to non-deterministic, undesirable behavior (for example, such workarounds often assume particular network topologies, etc., in order to function correctly; if the assumptions are not met in a deployment, the workaround may not work as expected). This issue is closely related to the fragmentation issue described in Section 2.5. 2.3. NAT-PT Binding State Decay NAT-PT will generally use dynamically created bindings to reduce the need for IPv4 addresses both for basic NAT-PT and NAPT-PT. Both basic NAT-PT and NAPT-PT use soft state mechanisms to manage the address and, in the case of NAPT-PT, port pools used for dynamically created address bindings. This allows all types of NAT-PT box to operate autonomously without requiring clients to signal, either implicitly or explicitly, that a binding is no longer required. In any case, without soft state timeouts, network and application unreliability would inevitably lead to leaks, eventually causing address or port pool exhaustion. For a dynamic binding to persist for longer than the soft state timeout, packets must be sent periodically from one side of the NAT-PT to the other (the direction is not specified by the NAT-PT specification). If no packets are sent in the proper direction, the NAT-PT binding will not be refreshed and the application connection will be broken. Hence, all applications need to maintain their NAT-PT bindings during long idle periods by incorporating a keep- alive mechanism, which may not be possible for legacy systems. Also, [RFC2766] does not specify how to choose timeouts for bindings. As is discussed in [RFC2663] for traditional NATs, selecting suitable values is a matter of heuristics, and coordinating with application expectations may be impossible. 2.4. Loss of Information through Incompatible Semantics NAT-PT reuses the SIIT header and protocol translations defined in [RFC2765]. Mismatches in semantics between IPv4 and IPv6 versions can lead to loss of information when packets are translated. Three issues arising from this are: o There is no equivalent in IPv4 for the flow label field of the IPv6 header. Hence, any special treatment of packets based on flow label patterns cannot be propagated into the IPv4 domain. Aoun & Davies Expires April 23, 2006 [Page 8] =0C Internet-Draft NAT-PT Issues Analysis October 2005 o IPv6 extension headers provide flexibility for improvements in the IP protocol suite in future. In the future, new headers may be defined that do not have equivalents in IPv4. In practice, some existing extensions such as routing headers and mobility extensions are not translatable. o As described in Section 2.2 of [I-D.satapati-v6ops-natpt- applicability], there are no equivalents in IPv6 for some ICMP(v4) messages, while for others (notably the 'Parameter Problem' messages) the semantics are not equivalent. Translation of such messages may lead to loss of information. However, this issue may not be very severe because the error messages relate to packets that have been translated by NAT-PT rather than arbitrary packets. If the NAT-PT is functioning correctly, there is, for example, no reason why IPv6 packets with unusual extension headers or options should be generated. This case is cited in [I-D.satapati-v6ops- natpt-applicability] as an example where the IPv6 error has no equivalent in IPv4 resulting in lost information. Loss of information in any of these cases could be a constraint to certain applications. A related matter concerns the propagation of the Differentiated Services Code Point (DSCP). NAT-PT and SIIT simply copy the DSCP field when translating packets. Accordingly, the IPv4 and IPv6 domains must have equivalent Per-Hop Behaviors for the same code point, or alternative means must be in place to translate the DSCP between domains. 2.5. NAT-PT and Fragmentation As mentioned in [RFC3027], simple port translators are unable to translate packet fragments, other than the first, from a fragmented packet, because subsequent fragments do not contain the port number information. This means that generally fragmentation cannot be allowed for any traffic that traverses a NAPT-PT. One attempted workaround requires the NAPT-PT to maintain state about fragmented packets in transit. This is not a complete solution because fragment misordering could lead to the first fragment appearing at the NAPT-PT after later fragments. The NAPT-PT would then not have the information needed to translate the fragments received before the first. Although it would not be expected in normal operation, NAPT-PT needs to be proofed against receiving short first fragments that don't contain the transport port numbers. Note that such packets are a problem for IPv6 stateful packet inspection. The current specifications of IPv6 do not mandate (1) any minimum packet size Aoun & Davies Expires April 23, 2006 [Page 9] =0C Internet-Draft NAT-PT Issues Analysis October 2005 beyond the need to carry the unfragmentable part (which doesn't include the transport port numbers) or (2) reassembly rules to minimize the effects of overlapping fragments. Thus, IPv6 is open to the sort of attacks described in [RFC1858] and [RFC3128]. An additional concern arises when a fragmented IPv4 UDP packet, which does not have a transport-layer checksum, traverses any type of NAT-PT box. As described in [RFC2766], the NAT-PT has to reconstruct the whole packet so that it can calculate the checksum needed for the translated IPv6 packet. This can result in significant delay to the packet, especially if it has to be re-fragmented before transmission on the IPv6 side. If NAT-PT boxes reassembled all incoming fragmented packets (both from the IPv4 and IPv6 directions) in the same way as they have to do for unchecksummed IPv4 UDP packets, this would be a solution to the first problem. The resource cost would be considerable apart from the potential delay problem if the outgoing packet has to be re- fragmented. In any case, fragmentation would mean that the NAT-PT would consume extra memory and CPU resources, making the NAT-PT even less scalable (see Section 3.2). Packet reassembly in a NAT-PT box also opens up the possibility of various fragment-related security attacks. Some of these are analogous to attacks identified for IPv4. Of particular concern is a DoS attack based on sending large numbers of small fragments without a terminating last fragment, which would potentially overload the reconstruction buffers and consume large amounts of CPU resources. 2.6. NAT-PT Interaction with SCTP and Multihoming The Stream Control Transmission Protocol (SCTP) [RFC2960] is a transport protocol, which has been standardized since SIIT was specified. SIIT does not explicitly cover translation of SCTP, but SCTP uses transport port numbers in the same way as UDP and TCP so that similar techniques could be used. However, SCTP also supports multihoming. During connection setup, SCTP control packets carry embedded addresses that would have to be translated. This would also require that the types of the options fields in the SCTP control packets be changed with consequent changes to packet length; the transport checksum would also have to be recalculated. The ramifications of multihoming as it might interact with NAT-PT have not been fully explored. Because of the 'chunked' nature of data transfer, it does not appear that state would have to be maintained to relate packets transmitted using the different IP addresses associated with the connection. Aoun & Davies Expires April 23, 2006 [Page 10] =0C Internet-Draft NAT-PT Issues Analysis October 2005 Even if these technical issues can be overcome, using SCTP in a NAT-PT environment may effectively nullify the multihoming advantages of SCTP if all the connections run through the same NAT-PT. The consequences of running a multihomed network with separate NAT-PT boxes associated with each of the 'homes' have not been fully explored, but one issue that will arise is described in Section 4.4. SCTP will need an associated 'ALG' -- actually a Transport Layer Gateway -- to handle the packet payload modifications. If it turns out that state is required, the state would have to distributed and synchronized across several NAT-PT boxes in a multihomed environment. SCTP running through NAT-PT in a multihomed environment is also incompatible with IPsec as described in Section 2.1. 2.7. NAT-PT as a Proxy Correspondent Node for MIPv6 As discussed in [I-D.lee-v6ops-natpt-mobility], it is not possible to propagate Mobile IPv6 control messages into the IPv4 domain. According to the IPv6 Node Requirements [I-D.ietf-ipv6-node- requirements], IPv6 nodes should normally be prepared to support the route optimization mechanisms needed in a correspondent node. If communications from an IPv6 mobile node are traversing a NAT-PT, the destination IPv4 node will certainly not be able to support the correspondent node features needed for route optimization. This can be resolved in two ways: o The NAT-PT can discard messages and headers relating to changes of care-of addresses, including reverse routing checks. Communications with the mobile node will continue through the home agent without route optimization. This is clearly sub-optimal, but communication should remain possible. o Additional functionality could be implemented in the NAT-PT to allow it to function as a proxy correspondent node for all IPv4 nodes for which it has bindings. This scheme adds considerably to the complexity of NAT-PT. Depending on the routability of the IPv6 PREFIX used for translated IPv4 addresses, it may also limit the extent of mobility of the mobile node: all communications to the IPv4 destination have to go through the same NAT-PT, even if the mobile node moves to a network that does not have direct IPv6 connectivity with the NAT-PT. In both cases, the existing NAT-PT specification would need to be extended to deal with IPv6 mobile nodes, and neither is a fully satisfactory solution. Aoun & Davies Expires April 23, 2006 [Page 11] =0C Internet-Draft NAT-PT Issues Analysis October 2005 2.8. NAT-PT and Multicast SIIT [RFC2765] cannot handle translation of multicast packets and NAT-PT does not discuss a way to map multicast addresses between IPv4 and IPv6. Some separate work has been done to provide an alternative mechanism to handle multicast. This uses a separate gateway that understands some or all of the relevant multicast control and routing protocols in each domain. This work has not been carried through into standards as yet. A basic mechanism, which involves only IGMP on the IPv4 side and MLD on the IPv6 side, is described in 'An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp)' [I-D.tsuchiya-mtp]. A more comprehensive approach, which includes proxying of the multicast routing protocols, is described in 'An IPv4 - IPv6 multicast gateway' [I-D.venaas-mboned-v4v6mcastgw]. Both approaches have several of the issues described in this section, notably issues with embedded addresses. [I-D.okazaki-v6ops-natpt-security] identifies the possibility of a multiplicative reflection attack if the NAT-PT can be spoofed into creating a binding for a multicast address. This attack would be very hard to mount because routers should not forward packets with multicast addresses in the source address field. However, it highlights the possibility that a naively implemented DNS-ALG could create such bindings from spoofed DNS responses since [RFC2766] does not mention the need for checks on the types of addresses in these responses. The issues for NAT-PT and multicast reflect the fact that NAT-PT is at best a partial solution. Completing the translation solution to cater for multicast traffic is likely to carry a similar set of issues to the current unicast NAT-PT and may open up significant additional security risks. 3. Issues exacerbated by the Use of DNS-ALG 3.1. Network Topology Constraints Implied by NAT-PT Traffic flow initiators in a NAT-PT environment are dependent on the DNS-ALG in the NAT-PT to provide the mapped address needed to communicate with the flow destination on the other side of the NAT-PT. Whether used for flows initiated in the IPv4 domain or the IPv6 domain, the NAT-PT has to be on the path taken by the DNS query sent by the flow initiator to the relevant DNS server; otherwise, the DNS query will not be modified and the response type would not be appropriate. Aoun & Davies Expires April 23, 2006 [Page 12] =0C Internet-Draft NAT-PT Issues Analysis October 2005 The implication is that the NAT-PT box also has to be the default IPv6 router for the site so that the DNS-ALG is able to examine all DNS requests made over IPv6. On sites with both IPv6 and dual-stack nodes, this will result in all traffic flowing through the NAT-PT with consequent scalability concerns. These constraints are described in more detail in [I-D.durand-natpt- dns-alg-issues]. [I-D.hallin-natpt-dns-alg-solutions] proposes a solution for flows initiated from the IPv6 domain, but it appears that this solution still has issues. For IPv6-only clients, the solution requires the use of a DNS server in the IPv4 domain accessed via an IPv6 address which uses the NAT-PT PREFIX (see [RFC2766]). Queries to this server would necessarily pass through the NAT-PT. Dual-stack hosts would use a separate DNS server accessed through a normal IPv6 address. This removes the need for the NAT-PT box to be the default IPv6 gateway for the domain. The primary proposal suggests that the IPv6-only clients should use this DNS server for all queries. This is expensive on NAT-PT resources because requests relating to hosts with native IPv6 addresses would also use the NAT-PT DNS-ALG. The alternate suggestion to reduce this burden appears to be flawed: if IPv6-only clients are provided with a list of DNS servers including both the server accessed via NAT-PT and server(s) accessed natively via IPv6, the proposal suggests that the client could avoid using NAT-PT for hosts that have native IPv6 addresses. Unfortunately for the alternate suggestion, there is no a priori way in which the initiator can decide which DNS server to use for a particular query. In the event that the initiator makes the wrong choice, the DNS query will return an empty list rather than failing to respond. With standard DNS logic, the initiator will not try alternative DNS servers because it has received a response. This means that the solution would consist of always using DNS servers having the NAT-PT prefix. This imposes the burden of always requiring DNS RR [RFC1035] translation. For flows initiated from the IPv4 network, the proposal recommends that the advertised DNS servers for the IPv6 network would have the IPv4 address of the NAT-PT. Again there is no deterministic way to choose the correct DNS server for each query resulting in the same issues as were raised for flows initiated from the IPv6 domain. Although the engineering workaround, just described, provides a Aoun & Davies Expires April 23, 2006 [Page 13] =0C Internet-Draft NAT-PT Issues Analysis October 2005 partial solution to the topology constraints issue, it mandates that DNS queries and responses should still go through a NAT-PT even if there would normally be no reason to do so. This mandatory passage through the NAT-PT for all DNS requests will exacerbate the other DNS-related issues discussed in Section 3.4 and Section 4.1. 3.2. Scalability and Single Point of Failure Concerns As with traditional NAT, NAT-PT is a bottleneck in the network with significant scalability concerns and the anchoring of flows to a particular NAT-PT makes the NAT-PT a potential single point of failure in the network. The addition of the DNS-ALG in NAT-PT further increases the scalability concerns. Solutions to both problems have been envisaged using collections of cooperating NAT-PT boxes, but such solutions require coordination and state synchronization, which has not yet been standardized and again adds to the functional and operational complexity of NAT-PT. One such solution is described in [I-D.park-scalable-multi-natpt]. As with traditional NAT, the concentration of flows through NAT-PT and the legitimate modification of packets in the NAT-PT make NAT-PTs enticing targets for security attacks. 3.3. Issues with Lack of Address Persistence Using the DNS-ALG to create address bindings requires that the application uses the translated address returned by the DNS query before the NAT-PT binding state is timed out (see Section 2.3). Applications will not normally be aware of this constraint, which may be different from the existing lifetime of DNS query responses. This could lead to "difficult to diagnose" problems with applications. Additionally, the DNS-ALG needs to determine the initial lifetime of bindings that it creates. As noted in Section 2.3, this may need to be determined heuristically. The DNS-ALG does not know which protocol the mapping is to be used for, and so needs another way to determine the initial lifetime. This could be tied to the DNS response lifetime, but that might open up additional DoS attack possibilities if very long validities are allowed. Also, the lifetime should be adjusted once the NAT-PT determines which protocol is being used with the binding. As with traditional NATs (see Section 2.5 of [RFC3027], NAT-PT will most likely break applications that require address mapping to be retained across contiguous sessions. These applications require the IPv4 to IPv6 address mapping to be retained between sessions so the same mapped address may be reused for subsequent session Aoun & Davies Expires April 23, 2006 [Page 14] =0C Internet-Draft NAT-PT Issues Analysis October 2005 interactions. NAT-PT cannot know this requirement and may reassign the previously used mapped address to different hosts between sessions. Trying to keep NAT-PT from discarding an address mapping would require either a NAT-PT extension protocol that would allow the application to request the NAT-PT device to retain the mappings, or an extended ALG (which has all the issues discussed in Section 2.1) that can interact with NAT-PT to keep the address mapping from being discarded after a session. 3.4. DoS Attacks on Memory and Address/Port Pools As discussed in Section 2.3, a NAT-PT may create dynamic NAT bindings, each of which consumes memory resources as well as an address (or port if NAPT-PT is used) from an address (or port) pool. A number of documents, including [RFC2766] and [I-D.okazaki-v6ops- natpt-security] discuss possible denial of service (DoS) attacks on basic NAT-PT and NAPT-PT that result in resource depletion associated with address and port pools. NAT-PT does not specify any authentication mechanisms; thus, an attacker may be able to create spurious bindings by spoofing addresses in packets sent through NAT-PT. The attack is more damaging if the attacker is able to spoof protocols with long binding timeouts (typically used for TCP). The use of the DNS-ALG in NAT-PT introduces another vulnerability that can result in resource depletion. The attack identified in [I-D.durand-natpt-dns-alg-issues] exploits the use of DNS queries traversing NAT-PT to create dynamic bindings. Every time a DNS query is sent through the NAT-PT, the NAT-PT may create a new basic NAT-PT or NAPT-PT binding without any end-host authentication or authorization mechanisms. This behavior could lead to a serious DoS attack on both memory and address or port pools. Address spoofing is not required for this attack to be successful. [I-D.hallin-natpt-dns-alg-solutions] proposes to mitigate the DoS attack by using Access Control Lists (ACLs) and static binds, which increases the operational cost and may not always be practical. The ideal mitigation solution would be to disallow dynamically created binds until authentication and authorization of the end-host needing the protocol translation has been carried out. This would require that the proper security infrastructure be in place to support the authentication and authorization, which increases the network operational complexity. Aoun & Davies Expires April 23, 2006 [Page 15] =0C Internet-Draft NAT-PT Issues Analysis October 2005 4. Issues Directly Related to Use of DNS-ALG 4.1. Address Selection Issues when Communicating with Dual-Stack End- Hosts [I-D.durand-natpt-dns-alg-issues] discusses NAT-PT DNS-ALG issues with regard to address selection. As specified in [RFC2766], the DNS-ALG returns AAAA resource records (RRs) from two possible sources to the IPv6 host that has made an AAAA DNS query. If the query relates to a dual-stack host, the query will return both the native IPv6 address(es) and the translated IPv4 address(es) in AAAA RRs. Without additional information, the IPv6 host address selection may pick a translated IPv4 address instead of selecting the more appropriate native IPv6 address. Under some circumstances, the address selection algorithms [RFC3484] will always prefer the translated address over the native IPv6 address; this is obviously undesirable. [I-D.hallin-natpt-dns-alg-solutions] proposes a solution that involves modification to the NAT-PT specification intended to return only the most appropriate address(es) to an IPv6 capable host: o When a DNS AAAA query traverses the NAT-PT DNS-ALG, the NAT-PT will forward the query to the DNS server in the IPv4 domain unchanged, but using IPv4 transport: * If the authoritative DNS server has one or more AAAA records, it returns them. The DNS-ALG then forwards this response to the IPv6 host and does not send an A query as the standard NAT-PT would do. * Otherwise, if the DNS server does not understand the AAAA query or has no AAAA entry for the host, it will return an error. The NAT-PT DNS-ALG will intercept the error or empty return and send an A query for the same host. If this query returns an IPv4 address, the ALG creates a binding and synthesizes a corresponding AAAA record, which it sends back to the IPv6 host. o The NAT-PT thus forwards the result of the first successful DNS response back to the end-host or an error if neither succeeds. Consequently, only AAAA RRs from one source will be provided instead of two as specified in [RFC2766], and it will contain the most appropriate address for a dual-stack or IPv6-only querier. There is, however, still an issue with the proposed solution: Aoun & Davies Expires April 23, 2006 [Page 16] =0C Internet-Draft NAT-PT Issues Analysis October 2005 o The DNS client may timeout the query if it doesn't receive a response in time. This is more likely because the NAT-PT may have to make two separate, sequential queries of which the client is not aware. It may be possible to reduce the response time by sending the two queries in parallel and ignoring the result of the A query if the AAAA returns one or more addresses. However, it is still necessary to delay after receiving the first response to determine if a second is coming, which may still trigger the DNS client timeout. Unfortunately, the two queries cannot be combined in a single DNS request (all known DNS servers only process a single DNS query per request message because of difficulties expressing authoritativeness for arbitrary combinations of requests). An alternative solution would be to allow the IPv6 host to have, within its address selection policies, the NAT-PT PREFIX [RFC2766] used and to assign it a low selection priority. This solution requires an automatic configuration of the NAT-PT PREFIX as well as its integration within the address selection policies. The simplest way to integrate this automatic configuration would be through configuration file download (in case the host or Dynamic Host Configuration Protocol for IPv6 (DHCPv6) server did not support vendor options, to avoid standardization effort on the NAT-PT PREFIX option). This solution does not require any modification to the NAT-PT specification. Neither of these solutions resolves a second issue related to address selection that is identified in [I-D.durand-natpt-dns-alg-issues]. Applications have no way of knowing that the IPv6 address returned from the DNS-ALG is not a 'real' IPv6 address, but a translated IPv4 address. The application may therefore be led to believe that it has end-to-end IPv6 connectivity with the destination. As a result, the application may use IPv6-specific options that are not supported by NAT-PT. This issue is closely related to the issue described in Section 4.2 and the discussion in Section 5. 4.2. Non-global Validity of Translated RR Records Some applications propagate information records retrieved from DNS to other applications. The published semantics of DNS imply that the results will be consistent to any user for the duration of the attached lifetime. RR records translated by NAT-PT violate these semantics because the retrieved addresses are only usable for communications through the translating NAT-PT. Applications that pass on retrieved DNS records to other applications will generally assume that they can rely on the passed on addresses Aoun & Davies Expires April 23, 2006 [Page 17] =0C Internet-Draft NAT-PT Issues Analysis October 2005 to be usable by the receiving application. This may not be the case if the receiving application is on another node, especially if it is not in the domain served by the NAT-PT that generated the translation. 4.3. Inappropriate Translation of Responses to A Queries Some applications running on dual-stack nodes may wish to query the IPv4 address of a destination. If the resulting A query passes through the NAT-PT DNS-ALG, the DNS-ALG will translate the response inappropriately into a AAAA record using a translated address. This happens because the DNS-ALG specified in [RFC2766] operates statelessly and hence has no memory of the IPv6 query that induced the A request on IPv4 side. The default action is to translate the response. The specification of NAT-PT could be modified to maintain minimal state about queries passed through the DNS-ALG, and hence to respond correctly to A queries as well as AAAA queries. 4.4. DNS-ALG and Multi-addressed Nodes Many IPv6 nodes, especially in multihomed situations but also in single homed deployments, can expect to have multiple global addresses. The same may be true for multihomed IPv4 nodes. Responses to DNS queries for these nodes will normally contain all these addresses. Since the DNS-ALG in the NAT-PT has no knowledge which of the addresses can or will be used by the application issuing the query, it is obliged to translate all of them. This could be a significant drain on resources in both basic NAT-PT and NAPT-PT, as bindings will have to be created for each address. When using SCTP in a multihomed network, the problem is exacerbated if multiple NAT-PTs translate multiple addresses. Also, it is not clear that SCTP will actually look up all the destination IP addresses via DNS so that bindings may not be in place when packets arrive. 4.5. Limitations on Deployment of DNS Security Capabilities Secure DNS (DNSSEC) [I-D.ietf-dnsext-dnssec-intro] uses public key cryptographic signing to authenticate DNS responses. The DNS-ALG modifies DNS query responses traversing the NAT-PT in both directions which would invalidate the signatures as (partially) described in Section 7.5 of [RFC2766]. Workarounds have been proposed, such as making the DNS-ALG behave Aoun & Davies Expires April 23, 2006 [Page 18] =0C Internet-Draft NAT-PT Issues Analysis October 2005 like a secure DNS server. This would need to be done separately for both the IPv6 and IPv4 domains. This is operationally very complex and there is a risk that the server could be mistaken for a conventional DNS server. The NAT-PT specification would have to be altered to implement any such workaround. Hence DNSSEC is not deployable in domains that use NAT-PT as currently specified. Widespread deployment of NAT-PT would become a serious obstacle to the large scale deployment of DNSSEC. 5. Impact on IPv6 Application Development One of the major design goals for IPv6 is to restore the end-to-end transparency of the Internet. Therefore, because IPv6 may be expected to remove the need for NATs and similar impediments to transparency, developers creating applications to work with IPv6 may be tempted to assume that the complex expedients that might have been needed to make the application work in a 'NATted' IPv4 environment are not required. Consequently, some classes of applications (e.g., peer-to-peer) that would need special measures to manage NAT traversal, including special encapsulations, attention to binding lifetime, and provision of keepalives, may build in assumptions on whether IPv6 is being used or not. Developers would also like to exploit additional capabilities of IPv6 not available in IPv4. NAT-PT as specified in [RFC2766] is intended to work autonomously and be transparent to applications. Therefore, there is no way for application developers to discover that a path contains a NAT-PT. If NAT-PT is deployed, applications that have assumed a NAT-free IPv6 environment may break when the traffic passes through a NAT-PT. This is bad enough, but requiring developers to include special capabilities to work around what is supposed to be a temporary transition 'aid' is even worse. Finally, deployment of NAT-PT is likely to inhibit the development and use of additional IPv6 capabilities enabled by the flexible extension header system in IPv6 packets. Some of these deleterious effects could possibly be alleviated if applications could discover the presence of NAT-PT boxes on paths in use, allowing the applications to take steps to workaround the problems. However, requiring applications to incorporate extra code to workaround problems with a transition aid still seems to be a very bad idea: the behavior of the application in native IPv6 and NAT-PT environments would be likely to be significantly different. Aoun & Davies Expires April 23, 2006 [Page 19] =0C Internet-Draft NAT-PT Issues Analysis October 2005 6. Security Considerations This document summarizes security issues related to the NAT-PT [RFC2766] specification. Security issues are discussed in various sections: o Section 2.1 discusses how IPsec AH (transport and tunnel mode) and IPsec ESP transport mode are broken by NAT-PT (when IPSEC UDP encapsulation is not used [RFC3498]); and authentication and encryption are generally incompatible with NAT-PT. o Section 2.5 discusses possible fragmentation related security attacks on NAT-PT. o Section 2.8 discusses security issues related to multicast addresses and NAT-PT. o Section 3.3 highlights that NAT-PT is an enticing nexus for security attacks. o Section 3.4 discusses possible NAT-PT DoS attacks on both memory and address/port pools. o Section 4.5 discusses why NAT-PT is incompatible with DNSSEC [RFC2535] and how deployment of NAT-PT may inhibit deployment of DNSSEC. 7. IANA Considerations There are no IANA considerations defined in this document. 8. Conclusion This document has discussed a number of significant issues with NAT-PT as defined in [RFC2766]. =46rom a deployment perspective, = 3GPP networks are currently the only 'standardised' scenario where an IPv6-only host communicates with an IPv4-only host using NAT-PT as described in the 3GPP IPv6 transition analysis [I-D.ietf-v6ops-3gpp- analysis], but NAT-PT has seen some limited usage for other purposes. Although some of the issues identified with NAT-PT appear to have solutions, many of the solutions required significant alterations to the existing specification and would be likely to increase operational complexity. Even if these solutions were applied, we have shown that NAT-PT still has significant, irresolvable issues and appears to have limited applicability. The potential constraints on the development of IPv6 applications described in Section 5 are particularly undesirable. It appears that alternatives to NAT-PT exist to cover the circumstances where NAT-PT has been suggested as a solution, such as the use of tunneling and header compression in 3GPP scenarios. Aoun & Davies Expires April 23, 2006 [Page 20] =0C Internet-Draft NAT-PT Issues Analysis October 2005 However, it is clear that in some circumstances an IPv6/IPv4 protocol translation solution may be a useful transitional solution, particularly in more constrained situations where the translator is not required to deal with traffic for a wide variety of protocols that are not determined in advance. Therefore, it is possible that a more limited form of NAT-PT could be defined for use in specific situations. Accordingly, we recommend that the IETF no longer suggest its usage as a general IPv4/IPv6 transition mechanism in the Internet, but retain it as an experimental mechanism while further experience is gained and any future replacement is defined and deployed. Consequently, we recommend moving RFC2766 to experimental status. 9. Acknowledgments This work builds on a large body of existing work examining the issues and applicability of NAT-PT: the work of the authors of the documents referred to in Section 1 has been extremely useful in creating this document. Particular thanks are due to Pekka Savola for rapid and thorough review of the document. 10. References 10.1. Normative References [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001. [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", Aoun & Davies Expires April 23, 2006 [Page 21] =0C Internet-Draft NAT-PT Issues Analysis October 2005 RFC 3314, September 2002. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [I-D.ietf-ipv6-node-requirements] Loughney, J., "IPv6 Node Requirements", draft-ietf-ipv6-node-requirements-11 (work in progress), August 2004. [I-D.ietf-v6ops-3gpp-analysis] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in progress), October 2004. [I-D.ietf-dnsext-dnssec-intro] Arends, R., Austein, R., Massey, D., Larson, M., and S. Rose, "DNS Security Introduction and Requirements", draft-ietf-dnsext-dnssec-intro-13 (work in progress), October 2004. 10.2. Informative References [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995. [RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001. [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [RFC3498] Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic Protection Switching (APS) Architectures", RFC 3498, March 2003. [I-D.satapati-v6ops-natpt-applicability] Satapati, S., "NAT-PT Applicability", draft-satapati-v6ops-natpt-applicability-00 (work in progress), October 2003. Aoun & Davies Expires April 23, 2006 [Page 22] =0C Internet-Draft NAT-PT Issues Analysis October 2005 [I-D.durand-natpt-dns-alg-issues] Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", draft-durand-natpt-dns-alg-issues-00 (work in progress), February 2002. [I-D.hallin-natpt-dns-alg-solutions] Hallingby, P. and S. Satapati, "NAT-PT DNS ALG solutions", draft-hallin-natpt-dns-alg-solutions-01 (work in progress), July 2002. [I-D.lee-v6ops-natpt-mobility] Shin, M. and J. Lee, "Considerations for Mobility Support in NAT-PT", draft-lee-v6ops-natpt-mobility-01 (work in progress), July 2005. [I-D.okazaki-v6ops-natpt-security] Okazaki, S. and A. Desai, "NAT-PT Security Considerations", draft-okazaki-v6ops-natpt-security-00 (work in progress), June 2003. [I-D.vanderpol-v6ops-translation-issues] Pol, R., Satapati, S., and S. Sivakumar, "Issues when translating between IPv4 and IPv6", draft-vanderpol-v6ops-translation-issues-00 (work in progress), January 2003. [I-D.elmalki-sipping-3gpp-translator] Malki, K., "IPv6-IPv4 Translation mechanism for SIP-based services in Third Generation Partnership Project (3GPP) Networks", draft-elmalki-sipping-3gpp-translator-00 (work in progress), December 2003. [I-D.tsuchiya-mtp] Tsuchiya, K., Higuchi, H., Sawada, S., and S. Nozaki, "An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp)", draft-tsuchiya-mtp-01 (work in progress), February 2003. [I-D.venaas-mboned-v4v6mcastgw] Venaas, S., "An IPv4 - IPv6 multicast gateway", draft-venaas-mboned-v4v6mcastgw-00 (work in progress), February 2003. [I-D.park-scalable-multi-natpt] Park, S., "Scalable mNAT-PT Solution", draft-park-scalable-multi-natpt-00 (work in progress), May 2003. Aoun & Davies Expires April 23, 2006 [Page 23] =0C Internet-Draft NAT-PT Issues Analysis October 2005 Authors' Addresses Cedric Aoun ZTE Corporation/ENST Paris France Email: aoun.cedric@zte.com.fr Elwyn B. Davies Consultant Soham, Cambs UK Phone: +44 7889 488 335 Email: elwynd@dial.pipex.com Aoun & Davies Expires April 23, 2006 [Page 24] =0C Internet-Draft NAT-PT Issues Analysis October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Aoun & Davies Expires April 23, 2006 [Page 25] =0C --Apple-Mail-17-287016294 Content-Type: text/plain; x-mac-type=54455854; x-unix-mode=0644; name="draft-ietf-v6ops-natpt-to-exprmntl-writeup.txt" Content-Disposition: attachment; filename=draft-ietf-v6ops-natpt-to-exprmntl-writeup.txt Content-Transfer-Encoding: 7bit 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? I, Fred Baker, have read it and believe that it is ready to forward to the IESG for review and action. 1.b) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Both the chairs and the authors believe it has been adequately reviewed: Much of the discussion in this document has been previously examined in other contexts and the totality in this formulation has seen a reasonable amount of discussion both on the WG mailing list and face-to-face. 1.c) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? As noted, it has already had fairly wide review, both in its present form and in the form of various drafts whose content was incorporated into it. As such, I do not believe that it needs additional review beyond the usual IETF last call. 1.d) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. I do not have issues with the document. I believe that NAT-PT or something like it is here to stay as a transition mechanism, if for no other reason than that some IT shops will find translation more palatable than IPv6 deployment in the near term. However, that doesn't make NAT-PT a particularly *good* solution. The sense of this document is that the choice of translation, and specifically this form of translation, as a solution is a problematic approach, one that may be worth documenting but not one that we can really recommend. Proposed Standard status suggests, to the uninitiated at any rate, that this is a good idea, and the proposal here is to no longer say that. 1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The original proposal was to deprecate the approach, which in my small mind is an undefined term (void the RFC number?). The working group consensus, as measured by the previous chairs, was and remains to declare NAT-PT "experimental", which is to say, "not standards track and not recommended for general deployment". This does not mean that the feature cannot be deployed, and there is current deployment and will be for some time. It does mean, in RFC 2026's language, that The "Experimental" designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process... I consider documentation of the approach, along with documentation of the issues inherent to it, to be a good thing. 1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. No 1.g) Have the chairs verified that the document adheres to all of the ID nits? (see http://www.ietf.org/ID-Checklist.html). Yes. The web page reports: idnits 1.82 tmp/draft-ietf-v6ops-natpt-to-exprmntl-03.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... the boilerplate looks good. No nits found. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. No nits found. 1.h) Is the document split into normative and informative references? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) Yes, it is split that way. The single dependent I-D, ietf-ipv6-node-requirements, is in the RFC Editor's queue. 1.i) For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: * Technical Summary * Working Group Summary * Protocol Quality This document is note iteself standards track, but documents comments regarding a standards track document: http://www.ietf.org/rfc/rfc2766.txt 2766 Network Address Translation - Protocol Translation (NAT-PT). G. Tsirtsis, P. Srisuresh. February 2000. (Format: TXT=49836 bytes) (Updated by RFC3152) (Status: PROPOSED STANDARD) As such, I think this section is appropriate. The introduction of the document reads: The Network Address Translator - Protocol Translator (NAT-PT) document [RFC2766] defines a set of network-layer translation mechanisms designed to allow nodes that only support IPv4 to communicate with nodes that only support IPv6 during the transition to the use of IPv6 in the Internet. [RFC2766] specifies the basic NAT-PT in which only addresses are translated and Network Address Port Translator - Protocol Translator (NAPT-PT), which also translates transport identifiers, allowing for greater economy of scarce IPv4 addresses. Protocol translation is performed using the Stateless IP/ICMP Translation Algorithm (SIIT) defined in [RFC2765]. In the following discussion, where the term "NAT-PT" is used unqualified, the discussion applies to both basic NAT-PT and NAPT-PT. "Basic NAT-PT" will be used if points apply to the basic address-only translator. A number of previous documents have raised issues with NAT-PT. This document will summarize these issues, note several other issues carried over from traditional IPv4 NATs, and identify some additional issues that have not been discussed elsewhere. Where solutions to the issues have been proposed, these are mentioned and any resulting need for changes to the specification is identified. Whereas NAT is seen as an ongoing capability that is needed to work around the limited availability of globally unique IPv4 addresses, NAT-PT has a different status as a transition mechanism for IPv6. As such, NAT-PT should not be allowed to constrain the development of IPv6 applications or impose limitations on future developments of IPv6. This document draws the conclusion that the technical and operational difficulties resulting from these issues, especially the possible future constraints on the development of IPv6 networks (see Section 5), make it undesirable to recommend NAT-PT as described in [RFC2766] as a general purpose transition mechanism for intercommunication between IPv6 networks and IPv4 networks. Although the [RFC2766] form of packet translation is not generally applicable, it is likely that in some circumstances a node that can only support IPv4 will need to communicate with a node that can only support IPv6; this needs a translation mechanism of some kind. Although this may be better carried out by an application-level proxy or transport-layer translator, there may still be scenarios in which a (possibly restricted) version of NAT-PT can be a suitable solution; accordingly, this document recommends that the IETF should reclassify RFC2766 from Standards Track to Experimental status. The substance of the document goes on to identify, point for point, classes of issues with translatores in general, issues with the DNS Algorithm (which is stated as being option but is in fact required for any working implementation), and issues with this particular approach. They are serious and substantive issues. The principal controversy in the working group related to the various drafts from which this document was constructed. Each would note a problem, but not all of the known problems. Eventually, it became clear that a summary document was needed, which is this document. The are existing implementations of NAT-PT, and if not deploying NAT-PT is an implementation fo this, yes, there are implementations of this as well. --Apple-Mail-17-287016294 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit -------------------------------------------------------------- "Don't worry about the world coming to an end today. It's already tomorrow in Australia." (Charles Schulz ) --Apple-Mail-17-287016294-- From owner-v6ops@ops.ietf.org Sun Nov 06 22:00:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYxEv-0006yV-V6 for v6ops-archive@megatron.ietf.org; Sun, 06 Nov 2005 22:00:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07378 for ; Sun, 6 Nov 2005 21:59:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EYxBD-000P0C-Ob for v6ops-data@psg.com; Mon, 07 Nov 2005 02:56:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EYxBC-000Ozz-OY for v6ops@ops.ietf.org; Mon, 07 Nov 2005 02:56:19 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jA72uHM13023 for ; Mon, 7 Nov 2005 04:56:17 +0200 Date: Mon, 7 Nov 2005 04:56:17 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: agenda for ietf64 ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk Do we have an agenda for IETF64? The meeting is supposed to be tomorrow. From owner-v6ops@ops.ietf.org Sun Nov 06 22:00:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYxF1-0006yl-3S for v6ops-archive@megatron.ietf.org; Sun, 06 Nov 2005 22:00:15 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07381 for ; Sun, 6 Nov 2005 21:59:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EYxDf-00001q-Bh for v6ops-data@psg.com; Mon, 07 Nov 2005 02:58:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [209.71.226.4] (helo=ex.hexago.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EYxDc-000Pzm-It for v6ops@ops.ietf.org; Mon, 07 Nov 2005 02:58:48 +0000 Received: from [10.100.11.15] (wbs.roomlinx.com [207.34.158.130] (may be forged)) by ex.hexago.com ( hexago/8.13.4) with ESMTP id jA72ugeb055900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Nov 2005 21:56:43 -0500 (EST) (envelope-from Florent.Parent@hexago.com) Date: Sun, 06 Nov 2005 21:58:41 -0800 From: Florent Parent To: v6ops@ops.ietf.org Subject: v6ops agenda for ietf64? Message-ID: X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Will there be an agenda sent to the list prior to the meeting? Florent From owner-v6ops@ops.ietf.org Sun Nov 06 22:02:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYxHO-0007Oe-FV for v6ops-archive@megatron.ietf.org; Sun, 06 Nov 2005 22:02:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07510 for ; Sun, 6 Nov 2005 22:02:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EYxGw-0001WE-S3 for v6ops-data@psg.com; Mon, 07 Nov 2005 03:02:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EYxGv-0001VR-LF for v6ops@ops.ietf.org; Mon, 07 Nov 2005 03:02:14 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jA731wH13163; Mon, 7 Nov 2005 05:02:01 +0200 Date: Mon, 7 Nov 2005 05:01:58 +0200 (EET) From: Pekka Savola To: Myung-Ki Shin cc: v6ops@ops.ietf.org Subject: Re: IEEE 802.16 access technology + IPv6 deployment In-Reply-To: <43684F30.3679C5A8@pec.etri.re.kr> Message-ID: References: <43684F30.3679C5A8@pec.etri.re.kr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, draft-ietf-v6ops-bb-deployment-scenarios-04.txt has been under development for a while and has already been Last Called. It is too late to add new material like this to it. I'd suggest that you write a separate document (maybe re-using the document layout) on 802.16 and we'll push that forward separately. However, maybe a better venue for that document would be the 16NG BOF as that's the place for those w/ expertise and interest in 802.16. On Wed, 2 Nov 2005, Myung-Ki Shin wrote: > I think v6ops is also interested in the draft - > Scenarios and Considerations of IPv6 in IEEE 802.16 Networks > http://www.ietf.org/internet-drafts/draft-shin-ipv6-ieee802.16-01.txt > > (The draft will be discussed in 16ng BoF (Tue.) at Vancouver.) > > IEEE 802.16 + IPv6 will be deployed as one of ISP > Broadband Access Networks such as Cable/HFC, BB Ethernet, > xDSL, WLAN, etc. > > So, I think IEEE 802.16 access technology should be also > added for completeness into > > > Any thoughts ? > > Thanks, > Myung-Ki, > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Nov 06 22:11:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYxPv-0000de-Pu for v6ops-archive@megatron.ietf.org; Sun, 06 Nov 2005 22:11:31 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07861 for ; Sun, 6 Nov 2005 22:11:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EYxPT-0005Om-3s for v6ops-data@psg.com; Mon, 07 Nov 2005 03:11:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EYxPS-0005Ob-H7 for v6ops@ops.ietf.org; Mon, 07 Nov 2005 03:11:02 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 06 Nov 2005 19:11:02 -0800 X-IronPort-AV: i="3.97,298,1125903600"; d="scan'208"; a="227735314:sNHT26214336" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA73Axdv000303; Sun, 6 Nov 2005 19:11:00 -0800 (PST) Received: from [209.52.107.183] (sjc-vpn4-1047.cisco.com [10.21.84.22]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jA73KF13011492; Sun, 6 Nov 2005 19:20:15 -0800 In-Reply-To: References: <43684F30.3679C5A8@pec.etri.re.kr> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <68692D07-74E1-4A3C-95AC-0D48EBE27272@cisco.com> Cc: Myung-Ki Shin , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: IEEE 802.16 access technology + IPv6 deployment Date: Sun, 6 Nov 2005 19:10:57 -0800 To: Pekka Savola X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=904; t=1131333615; x=1131765815; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20IEEE=20802.16=20access=20technology=20+=20IPv6=20deployment| From:Fred=20Baker=20| Date:Sun,=206=20Nov=202005=2019=3A10=3A57=20-0800| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=J+ES8yPbFCkZagYF8e/xzDaZUsbY+ZN3NxYzSekknwMR18dNz6zQZczoJnIeTtAcd8QuN6nY TRvll7Kw7o7/mL1oMrRbYd+IoAqQMZjNZBQpeUKqdFi/ZTQvtMrWLQqCe0FAuf7zG77MYQxf9Cl RylFsuGV8jb40N+Zv9oBPH9k= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is actually something we probably want to discuss breifly tomorrow. I'm told that DOCSIS has delayed its comments, and that a date has not been given. One way to look at that is "this document should wait for the DOCSIS comments and then be updated", which is where we came out in August; the other is that it is sufficient for DOCSIS 1.0, 1.1, and 2.0 services. If the latter is true, then we may simply want to add a note saying as much, publish this, and plan on a revision when DOCSIS emits its update. I have not heard that the latter is false. On Nov 6, 2005, at 7:01 PM, Pekka Savola wrote: > draft-ietf-v6ops-bb-deployment-scenarios-04.txt has been under > development for a while and has already been Last Called. It is too > late to add new material like this to it. I'd suggest that you > write a separate document (maybe re-using the document layout) on > 802.16 and we'll push that forward separately. -------------------------------------------------------------- "Don't worry about the world coming to an end today. It's already tomorrow in Australia." (Charles Schulz ) From owner-v6ops@ops.ietf.org Sun Nov 06 22:22:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYxac-0002bR-RD for v6ops-archive@megatron.ietf.org; Sun, 06 Nov 2005 22:22:34 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08338 for ; Sun, 6 Nov 2005 22:22:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EYxa8-000AGP-GV for v6ops-data@psg.com; Mon, 07 Nov 2005 03:22:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EYxa7-000AFE-L9 for v6ops@ops.ietf.org; Mon, 07 Nov 2005 03:22:04 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jA73Leu13536; Mon, 7 Nov 2005 05:21:40 +0200 Date: Mon, 7 Nov 2005 05:21:40 +0200 (EET) From: Pekka Savola To: Fred Baker cc: v6ops@ops.ietf.org Subject: status of bb-deployment [Re: IEEE 802.16 access technology + IPv6 deployment In-Reply-To: <68692D07-74E1-4A3C-95AC-0D48EBE27272@cisco.com> Message-ID: References: <43684F30.3679C5A8@pec.etri.re.kr> <68692D07-74E1-4A3C-95AC-0D48EBE27272@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, 6 Nov 2005, Fred Baker wrote: > This is actually something we probably want to discuss breifly tomorrow. I'm > told that DOCSIS has delayed its comments, and that a date has not been > given. One way to look at that is "this document should wait for the DOCSIS > comments and then be updated", which is where we came out in August; the > other is that it is sufficient for DOCSIS 1.0, 1.1, and 2.0 services. If the > latter is true, then we may simply want to add a note saying as much, publish > this, and plan on a revision when DOCSIS emits its update. I have not heard > that the latter is false. Back in August 2005, there was an offlist agreement (with chairs, authors, Alain, and Tony) as follows: "1) Let them (Alain & Tony) to provide all the required inputs maximum until middle of October, so they have actually more time that they asked for. 2) With inputs or without them, the document will be ready from our side, and they will not object if they didn't provided the inputs (for example new architecture still not agreed, etc.). So by the cut-off date before the next IETF, will be moved forward to the next step. 3) If no inputs are available or a more complete thing is needed for DOCSIS 3.0, then a new document can be made specifically for that architecture." It is no surprise that DOCSIS 3.0 might be delayed; that was expected already before the last IETF. Unless there is opposition to this from other members of the WG, we should IMHO move forward. We can't wait forever for input to come especially because we already agreed not to wait any longer. The document can easily be revised later on, or DOCSIS 3.0 can be described separately. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Nov 06 23:22:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYyW9-0006rm-E8 for v6ops-archive@megatron.ietf.org; Sun, 06 Nov 2005 23:22:01 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12234 for ; Sun, 6 Nov 2005 23:21:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EYyUn-00097s-Bz for v6ops-data@psg.com; Mon, 07 Nov 2005 04:20:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.52 (FreeBSD)) id 1EYyUm-00096j-8N for v6ops@ops.ietf.org; Mon, 07 Nov 2005 04:20:36 +0000 Received: from [209.52.110.223] by consulintel.es (MDaemon.PRO.v7.2.5.R) with ESMTP id md50001389685.msg for ; Mon, 07 Nov 2005 05:20:53 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 06 Nov 2005 20:20:18 -0800 Subject: Re: status of bb-deployment [Re: IEEE 802.16 access technology + IPv6 deployment From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: Thread-Topic: status of bb-deployment [Re: IEEE 802.16 access technology + IPv6 deployment Thread-Index: AcXjUo8+zfVxR09FEdq2ogANky3PwA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-MDRemoteIP: 209.52.110.223 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Mon, 07 Nov 2005 05:21:00 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit One more issue as part of this agreement was to further clarify in the document that it was preferring native IPv6 support. So the cable part of this document is only relevant to the case that you can't upgrade your cable equipment to support IPv6 natively. This has been done in the latest review, and this means that any new release of DOCSIS or any other way to offer native IPv6 support doesn't require any change to the current document status. Regards, Jordi > De: Pekka Savola > Responder a: > Fecha: Mon, 7 Nov 2005 05:21:40 +0200 (EET) > Para: Fred Baker > CC: "v6ops@ops.ietf.org" > Asunto: status of bb-deployment [Re: IEEE 802.16 access technology + IPv6 > deployment > > "1) Let them (Alain & Tony) to provide all the required inputs maximum > until middle of October, so they have actually more time that they > asked for. > > 2) With inputs or without them, the document will be ready from our > side, and they will not object if they didn't provided the inputs (for > example new architecture still not agreed, etc.). So by the cut-off > date before the next IETF, will be moved forward to the next step. > > 3) If no inputs are available or a more complete thing is needed for > DOCSIS 3.0, then a new document can be made specifically for that > architecture." > > It is no surprise that DOCSIS 3.0 might be delayed; that was expected > already before the last IETF. Unless there is opposition to this from > other members of the WG, we should IMHO move forward. We can't wait > forever for input to come especially because we already agreed not to > wait any longer. The document can easily be revised later on, or > DOCSIS 3.0 can be described separately. ************************************ The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Information available 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. From owner-v6ops@ops.ietf.org Mon Nov 07 01:58:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ0y0-0000fy-NC for v6ops-archive@megatron.ietf.org; Mon, 07 Nov 2005 01:58:58 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19554 for ; Mon, 7 Nov 2005 01:58:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZ0v1-000L0W-Mn for v6ops-data@psg.com; Mon, 07 Nov 2005 06:55:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0 Received: from [208.17.33.58] (helo=pacdcoavas09.cable.comcast.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EZ0v0-000KzN-Tl for v6ops@ops.ietf.org; Mon, 07 Nov 2005 06:55:51 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: status of bb-deployment [Re: IEEE 802.16 access technology + IPv6 deployment Date: Mon, 7 Nov 2005 01:55:19 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73022179C2@PACDCEXCMB01.cable.comcast.com> Thread-Topic: status of bb-deployment [Re: IEEE 802.16 access technology + IPv6 deployment Thread-Index: AcXjTAiqHVd7GcOsT/S0x2iJas2GqgACFYNU From: "Durand, Alain" To: "Pekka Savola" , "Fred Baker" Cc: , X-OriginalArrivalTime: 07 Nov 2005 06:55:20.0695 (UTC) FILETIME=[38154870:01C5E368] Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Pekka wrote: =20 > It is no surprise that DOCSIS 3.0 might be delayed; that was expected > already before the last IETF. Pekka, you should re-read what Fred wrote: " DOCSIS has delayed its = comments", which is very different from Docsis 3.0 might be delayed. I'm not authorized to make any public comment one way or another and I = doubt very much that you are.=20 - Alain. From owner-v6ops@ops.ietf.org Mon Nov 07 13:28:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZBj1-00085i-PL for v6ops-archive@megatron.ietf.org; Mon, 07 Nov 2005 13:28:13 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27497 for ; Mon, 7 Nov 2005 13:27:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZBgN-000KNY-DF for v6ops-data@psg.com; Mon, 07 Nov 2005 18:25:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZBgM-000KMQ-O8 for v6ops@ops.ietf.org; Mon, 07 Nov 2005 18:25:26 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 07 Nov 2005 10:25:27 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jA7IPHQQ024483 for ; Mon, 7 Nov 2005 10:25:17 -0800 (PST) Received: from [209.52.107.183] (sjc-vpn4-528.cisco.com [10.21.82.16]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jA7IYbcR016954 for ; Mon, 7 Nov 2005 10:34:38 -0800 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: v6ops@ops.ietf.org From: Fred Baker Subject: Status of documents and agenda for WG meeting Date: Mon, 7 Nov 2005 10:25:22 -0800 X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1362; t=1131388478; x=1131820678; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Status=20of=20documents=20and=20agenda=20for=20WG=20meeting| From:Fred=20Baker=20| Date:Mon,=207=20Nov=202005=2010=3A25=3A22=20-0800| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=NTudSHkmIe/pHBDtkZrcuYZVuxCGA6TlbdRGSB0fjycTFLRmnlExRGRGBWWe2Ds8Mv5jLbZA /IS75M+M/kG8oHp0l5tiFZeknOh/hNMUGpSh5ZR2+44OeSZy0PHtFB02FqZErugSmNDiK0lCsS5 BOUfPoKiE0jsdPtH7URQDOIc= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The following have been sent to the IESG draft-ietf-v6ops-onlinkassumption-03.txt draft-ietf-v6ops-vlan-usage-00.txt draft-ietf-v6ops-natpt-to-exprmntl-03.txt The following are in a position to send, and in fact I have my comments completed on them. I believe that there were questions raised concerning them that delayed them, resulting in updates to the Security Overview, NAP, and BB documents. I would like to have a brief discussion on each regarding their disposition. draft-ietf-v6ops-ipsec-tunnels-01.txt draft-ietf-v6ops-security-overview-03.txt draft-ietf-v6ops-nap-02.txt draft-ietf-v6ops-bb-deployment-scenarios-04.txt Where do we stand on the Enterprise Analysis? draft-ietf-v6ops-ent-analysis-03.txt Discussion today draft-chown-v6ops-port-scanning-implications-02.txt draft-palet-v6ops-6in4-vs-6over4-00.txt draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt draft-baker-v6ops-end2end-00.txt draft-blanchet-v6ops-routing-guidelines-00.txt draft-kim-v6ops-ipv6overwibro-issues-00.txt draft-lee-v6ops-natpt-mobility-01.txt Remaining documents labeled as related to v6ops which we will not discuss today. draft-chown-v6ops-renumber-thinkabout-03.txt draft-lee-v6ops-mipv6-deployment-00.txt draft-despres-v6ops-transition-v5roadmap-00.txt draft-blanchet-v6ops-tunnelbroker-tsp-03.txt draft-huitema-v6ops-teredo-05.txt draft-liumin-v6ops-silkroad-03.txt draft-ooms-v6ops-bgp-tunnel-05.txt draft-massar-v6ops-heartbeat-01.txt draft-massar-v6ops-tunneldiscovery-00.txt From owner-v6ops@ops.ietf.org Mon Nov 07 23:23:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZL1K-0006Lm-2X for v6ops-archive@megatron.ietf.org; Mon, 07 Nov 2005 23:23:42 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08787 for ; Mon, 7 Nov 2005 23:23:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZKyO-00055k-3O for v6ops-data@psg.com; Tue, 08 Nov 2005 04:20:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [202.249.10.124] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZKyL-00053c-6K for v6ops@ops.ietf.org; Tue, 08 Nov 2005 04:20:38 +0000 Received: from impact.jinmei.org (unknown [2001:410:1000:f000:cc39:6ae8:1d2b:a9e5]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 90BC41525D for ; Tue, 8 Nov 2005 13:20:30 +0900 (JST) Date: Tue, 08 Nov 2005 13:20:15 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: v6ops@ops.ietf.org Subject: Conclusion of KAME User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-v6ops@ops.ietf.org Precedence: bulk (Apologize for possible duplicate messages) Dear all, This is an important announcement from the KAME project. I'm JINMEI, Tatuya, sending this message on behalf of the project. It is our pleasure to announce that the KAME project has achieved its project mission, which was to establish the IPv6 platform technology and to deploy the IPv6 technology to the industry. We have observed that the missions of the KAME project, which were to provide an open reference implementation of the IPv6 protocol, have been achieved and so have decided that we can conclude the project. The KAME project will complete its work on the IPv6 reference implementation around the end of March 2006. We will conclude the project and then move on to other work in related areas through the following two activities. (1) Complete merging the KAME's IPv6 protocol stack into BSD operating systems source code suite, in order for the core IPv6 protocol stack to be maintained in each BSD community thereafter. (2) KAME members are going to focus on the next R&D items associated with IPv6 technology, while enhancing the collaboration and cooperation with the WIDE project members at large and some other related R&D organizations. The WIDE project, along with the members of the KAME project, has focused on some specific important areas including advanced core functions or applications associated with IPv6 technology. In other words, the WIDE project is going to reinforce the IPv6-related activities, rather than just to continue our effort on IPv6, according to the success and the conclusion of KAME project activity. (see also the official announcement from WIDE at http://www.wide.ad.jp/news/press/20051107-KAME-e.html) The WIDE project established the KAME project in 1998. The primary mission and the goal was to develop and to deploy the reference code of IPv6/IPsec and other advanced protocols related with the IPv6 system, in order to enable the deployment of the IPv6 technology. The majority of our implementation has been already merged into 4 major BSD operating systems (BSDi/FreeBSD/NetBSD/OpenBSD) and we believe the implementation is now quite stable, and has been integrated into many commercial products. This means that KAME's major task, which is to provide a reference implementation both to academia and to industry, has been achieved. Through various discussions with IETF members and others, we have reached a conclusion that there are no major issues in the basic functionality of our IPv6 code base. In fact, the IETF is now discussing how to make the core protocols advance to the full standard. Also, we can observe many IPv6 products other than BSD systems, including various kinds of commercial products/services, in the commercial market. We have observed: 1. The KAME project has achieved its development and deployment goal associated with the IPv6 core protocol stack/functions 2. The IPv6 core protocol specifications have matured and are now stable. 3. Products and services using the IPv6 technology have been widely developed and deployed. Given the above observations, we have realized that we can (and should) conclude the KAME project activity, in order to let the industry realize that IPv6 is stable enough for commercial development and deployment. To conclude the KAME project, we will focus on integrating all remaining KAME functionality into the *BSD operating systems. We hope to complete this effort by the end of March 2006. Some advanced features currently developed and distributed by the KAME project are not ready to be merged into BSD systems yet. Those include SCTP/DCCP, Mobile IPv6, NEMO, and IKEv2. We do not plan to incorporate them by the end of March 2006. Instead, the research and development activities on these features will continue via other working groups in the WIDE project. The following is a summary of the related groups: - SCTP/DCCP WIDE SCTP WG (http://member.wide.ad.jp/wg/sctp) - Mobile IPv6/NEMO WIDE Nautilus6 project (http://www.nautilus6.org/) - IKEv2 WIDE ipsec WG (http://www.wide.ad.jp/project/wg/ipsec.html) - DHCPv6 A new development activity is planned - pim6sd/pim6dd A new development activity is planned Other IPv6-related activates will also continue. - IPv6 code for Linux The USAGI project (http://www.linux-ipv6.org/) - IPv6 testing and evaluation The TAHI project (http://www.tahi.org/) Likewise, the mailing list "snap-users" will remain and the current core members of the KAME project will support questions/comments, if any, as much as possible. We hereby thank those who helped us. Without their help, our goal would have not been achieved. We believe the IPv6 will be deployed more universally in the near future. May IPv6 be with you... --- The KAME project (http://www.kame.net/) The WIDE project (http://www.wide.ad.jp/) From owner-v6ops@ops.ietf.org Tue Nov 08 16:46:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZbI0-0001hw-Rb for v6ops-archive@megatron.ietf.org; Tue, 08 Nov 2005 16:46:01 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07949 for ; Tue, 8 Nov 2005 16:45:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZbEK-000AUr-Ah for v6ops-data@psg.com; Tue, 08 Nov 2005 21:42:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [62.241.162.43] (helo=nmail0.systems.pipex.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EZbEJ-000AUY-9Q for v6ops@ops.ietf.org; Tue, 08 Nov 2005 21:42:11 +0000 Received: from nmail0.systems.pipex.net (localhost [127.0.0.1]) by nmail0.systems.pipex.net (8.13.3/8.13.3) with ESMTP id jA8Lg6CK000637; Tue, 8 Nov 2005 21:42:06 GMT Received: (from nobody@localhost) by nmail0.systems.pipex.net (8.13.3/8.13.3/Submit) id jA8Lg5ka000636; Tue, 8 Nov 2005 21:42:05 GMT Received: from 209.52.106.220 ( [209.52.106.220]) as user elwynd@dial.pipex.com by netmail.pipex.net with HTTP; Tue, 08 Nov 2005 21:42:05 +0000 Message-ID: <1131486125.43711badb468b@netmail.pipex.net> Date: Tue, 08 Nov 2005 21:42:05 +0000 From: elwynd@dial.pipex.com To: Fred Baker , kurtis@kurtis.pp.se Cc: v6ops@ops.ietf.org Subject: Fwd: Re: draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt comments MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: PIPEX NetMail (IMP3.1) X-Originating-IP: 209.52.106.220 X-PIPEX-Username: elwynd%dial.pipex.com X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit ----- Forwarded message from elwynd@dial.pipex.com ----- Date: Tue, 08 Nov 2005 19:44:53 +0000 From: elwynd@dial.pipex.com Reply-To: elwynd@dial.pipex.com Subject: Re: draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt comments To: Stig Venaas Quoting Stig Venaas : > Hi > > Some comments on the ICMPv6 filtering draft. > > The main question I have is wheather you should talk about ICMP > filtering on links. There are switches today that have some l3 > capabilities like doing ACL based IP filtering. The text currently > seems to assume links are not filtered. If this filtering is done, > I believe it might be good to mention filtering of RAs. It's very > useful for an administrator to only accept RAs on the router port. > There are several attacks possible through sending RAs. At the moment the title says firewalls. We could add a section to talk about filtering on switches if this acceptable to the chairs and list. From my point of view it would make sense. Fred, Kurt: do you have a view? > > Some other comments below. > > In section 2.3 it says: > > Local communications will use link-local addresses in many cases but > may also use global unicast addresses for example when configuring > global addresses. > > Huh? I have a hard time parsing this. What are you trying to say? I agree maybe the words need a respin. The point is that some address configuration messages are confined to the local link but use global addresses because (for example) DAD is being done on the global address. Also the scopes of source and destination can be mismatched. > > In section 2.4: > > firewalls for local delivery. Generally a firewall will also by > s/by/be OK. ^^ > > In section 4.1: > > Many of the messages used for establishment of communications on the > local link will be sent with link-local addresses for at least one of > their source and destination. Routers (and firewalls) conforming to > the IPv6 standards will not forward these packets; there is no need > to configure additional rules to prevent these packets traversing the > firewall/router. Also the specifications of ICMPv6 messages intended > > A firewall may be invisible at IP layer, at least if a firewall can be > say a l3 switch with acls... I believe in general there are firewalls > that forward packets without reducing hop count? Maybe needs to be better > defined in the draft what is meant by the term "firewall"? Hmm! That's a bit of an issue for all the various hop count 'tricks'. I hadn't thought about that area. I must admit I have never thought about what the Linux bridged firewall that I have at home does as regards hop count. So what we are saying is that for the firewalls that aren't actually routers, you have to actively filter transiting Category 3 (Ones that would be 'dropped anyway') because you can't rely on the firewall changing the hop count. I think this is the only place where it affects the rules. It would be good to discuss the possibilities of firewalls are not acting as routers a bit more (there is text somewhere about them 'generally being routers'). > > Finally I see some mix of English English and US English in the draft. I'll run it through a spell checker for some value of US or UK ;-) Thanks, Elwyn > > Stig > -- ----- End forwarded message ----- -- From aminadab@accubanc.com Mon Nov 14 00:32:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbWxb-0006lu-Mc for v6ops-archive@megatron.ietf.org; Mon, 14 Nov 2005 00:32:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25934 for ; Mon, 14 Nov 2005 00:32:24 -0500 (EST) Received: from 12-202-31-202.client.insightbb.com ([12.202.31.202]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EbXEX-0006Yu-DO for v6ops-archive@ietf.org; Mon, 14 Nov 2005 00:50:27 -0500 Message-ID: From: "Vanessa J. Smith" To: v6ops-archive@ietf.org Subject: =?iso-8859-1?B?UG9wdWxhciBzb2Z0IC0gNzUlIE9GRg==?= Date: Mon, 14 Nov 2005 06:16:40 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_FE65738B.1A981C89" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.9 (++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 This is a multi-part message in MIME format. ------=_NextPart_000_0000_FE65738B.1A981C89 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_D35C8253.6B99C81C" ------=_NextPart_001_0001_D35C8253.6B99C81C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Get all the popular software possible for prices substantially lower than in stores! We sell software 2-6 times cheaper than retail price. A few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $69.95 Dreamweaver MX 2004 / Flash MX 2004 / Fireworks MX $149.95 Adobe Creative Suite Premium (5 CD) $79.95 Adobe Acrobat 6.0 Professional $59.95 Corel Draw Graphics Suite 11 Special offers: $89.95 Windows XP Pro + Office XP Pro $129.95 Photoshop 7 + Premiere 7 + Illustrator 10 $109.95 Dreamweaver MX 2004 + Flash MX 2004 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many other... Go visit us at: http://www.alldisks.net Best, Jennifer Clark ________________________________ To be taken off future campaigns, go here ________________________________ ------=_NextPart_001_0001_D35C8253.6B99C81C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Get all the popular software possible for prices substantially lower than in stores!
We sell software 2-6 times cheaper than retail price.

A few examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$69.95 Dreamweaver MX 2004 / Flash MX 2004 / Fireworks MX
$149.95 Adobe Creative Suite Premium (5 CD)
$79.95 Adobe Acrobat 6.0 Professional
$59.95 Corel Draw Graphics Suite 11

Special offers:
$89.95 Windows XP Pro + Office XP Pro
$129.95 Photoshop 7 + Premiere 7 + Illustrator 10
$109.95 Dreamweaver MX 2004 + Flash MX 2004

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many other... Go visit us at:

http://www.alldisks.net

Best,
Jennifer Clark


________________________________
To be taken off future campaigns, go here
________________________________

------=_NextPart_001_0001_D35C8253.6B99C81C-- ------=_NextPart_000_0000_FE65738B.1A981C89-- From owner-v6ops@ops.ietf.org Thu Nov 17 04:18:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcfuI-0002z5-68 for v6ops-archive@megatron.ietf.org; Thu, 17 Nov 2005 04:18:16 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08953 for ; Thu, 17 Nov 2005 04:17:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ecfnn-000Lea-1W for v6ops-data@psg.com; Thu, 17 Nov 2005 09:11:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.54 (FreeBSD)) id 1Ecfnl-000LeJ-8O for v6ops@ops.ietf.org; Thu, 17 Nov 2005 09:11:29 +0000 Received: from [10.10.10.101] by consulintel.es (MDaemon.PRO.v7.2.5.R) with ESMTP id md50001413842.msg for ; Thu, 17 Nov 2005 10:11:41 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 17 Nov 2005 10:10:48 +0100 Subject: FW: I-D ACTION:draft-palet-v6ops-6in4-vs-6over4-01.txt From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: Thread-Topic: I-D ACTION:draft-palet-v6ops-6in4-vs-6over4-01.txt Thread-Index: AcXrVsx3Cw1zQldKEdqNdwANky3PwA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Thu, 17 Nov 2005 10:12:11 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, After talking with Fred last week, about this I-D, concluded that what may be wrong to make "should" or "must" to change the existing documents, so I just made a recommendation. I hope that now this as Informational could be ok for the people that want to avoid reading all the I-Ds that mix up this, as a single stop document. Regards, Jordi ------ Mensaje reenviado De: "Internet-Drafts@ietf.org" Responder a: "Internet-Drafts@ietf.org" Fecha: Wed, 16 Nov 2005 15:50:01 -0500 Para: Asunto: I-D ACTION:draft-palet-v6ops-6in4-vs-6over4-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : 6in4 versus 6over4 terminology Author(s) : J. Palet Filename : draft-palet-v6ops-6in4-vs-6over4-01.txt Pages : 8 Date : 2005-11-16 This document clarifies the existing terminology confusion among references to IPv6/IPv4 encapsulations and IPv4/IPv6 transition mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-palet-v6ops-6in4-vs-6over4-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-palet-v6ops-6in4-vs-6over4-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-palet-v6ops-6in4-vs-6over4-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. Content-Type: text/plain Content-ID: <2005-11-16150727.I-D@ietf.org> _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------ Fin del mensaje reenviado ************************************ The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Information available 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. From owner-v6ops@ops.ietf.org Thu Nov 17 13:52:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecorw-00039f-HQ for v6ops-archive@megatron.ietf.org; Thu, 17 Nov 2005 13:52:24 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13846 for ; Thu, 17 Nov 2005 13:51:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ecopl-0007UH-5l for v6ops-data@psg.com; Thu, 17 Nov 2005 18:50:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ecopj-0007Tw-B5 for v6ops@ops.ietf.org; Thu, 17 Nov 2005 18:50:07 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jAHIo0100453; Thu, 17 Nov 2005 20:50:00 +0200 Date: Thu, 17 Nov 2005 20:50:00 +0200 (EET) From: Pekka Savola To: JORDI PALET MARTINEZ cc: "v6ops@ops.ietf.org" Subject: Re: FW: I-D ACTION:draft-palet-v6ops-6in4-vs-6over4-01.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 17 Nov 2005, JORDI PALET MARTINEZ wrote: > I hope that now this as Informational could be ok for the people that want > to avoid reading all the I-Ds that mix up this, as a single stop document. Sure, whenever folks get confused you and we and always point to http://www.watersprings.org/pub/id/draft-palet-v6ops-6in4-vs-6over4-01.txt even after the doc expires. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Nov 17 14:22:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcpKk-000662-3c for v6ops-archive@megatron.ietf.org; Thu, 17 Nov 2005 14:22:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15377 for ; Thu, 17 Nov 2005 14:21:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EcpJj-0009av-65 for v6ops-data@psg.com; Thu, 17 Nov 2005 19:21:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0 Received: from [208.17.33.59] (helo=pacdcoavas10.cable.comcast.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EcpJh-0009aZ-SC for v6ops@ops.ietf.org; Thu, 17 Nov 2005 19:21:06 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: I-D ACTION:draft-palet-v6ops-6in4-vs-6over4-01.txt Date: Thu, 17 Nov 2005 14:20:42 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7303024520@PACDCEXCMB01.cable.comcast.com> Thread-Topic: I-D ACTION:draft-palet-v6ops-6in4-vs-6over4-01.txt Thread-Index: AcXrVsx3Cw1zQldKEdqNdwANky3PwAAVLHkA From: "Durand, Alain" To: , X-OriginalArrivalTime: 17 Nov 2005 19:20:41.0602 (UTC) FILETIME=[FFF3A620:01C5EBAB] Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I still strongly disagree with the recommendation to use (X in Y) instead of (X over Y) when the rest of the non-IPv6 world is using (X over Y). I thought the recommendation during the meeting in Vancouver was not to go there but write in the wikiopedia an article about the specific 6over4 transition mechanish and its unfortunate choice of acronym... - Alain. =20 =20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ > Sent: Thursday, November 17, 2005 4:11 AM > To: v6ops@ops.ietf.org > Subject: FW: I-D ACTION:draft-palet-v6ops-6in4-vs-6over4-01.txt >=20 > Hi all, >=20 > After talking with Fred last week, about this I-D, concluded=20 > that what may be wrong to make "should" or "must" to change=20 > the existing documents, so I just made a recommendation. >=20 > I hope that now this as Informational could be ok for the=20 > people that want to avoid reading all the I-Ds that mix up=20 > this, as a single stop document. >=20 > Regards, > Jordi >=20 >=20 >=20 > ------ Mensaje reenviado > De: "Internet-Drafts@ietf.org" =20 > Responder a: "Internet-Drafts@ietf.org" > Fecha: Wed, 16 Nov 2005 15:50:01 -0500 > Para: > Asunto: I-D ACTION:draft-palet-v6ops-6in4-vs-6over4-01.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : 6in4 versus 6over4 terminology > Author(s) : J. Palet > Filename : draft-palet-v6ops-6in4-vs-6over4-01.txt > Pages : 8 > Date : 2005-11-16 > =20 > This document clarifies the existing terminology confusion among > references to IPv6/IPv4 encapsulations and IPv4/IPv6 transition > mechanisms. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-palet-v6ops-6in4-vs- 6over4-01.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message. =20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then=20 > "get draft-palet-v6ops-6in4-vs-6over4-01.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-palet-v6ops-6in4-vs-6over4-01.txt". > =20 > NOTE: The mail server at ietf.org can return the document in =20 > MIME-encoded form by using the "mpack" utility. To use this =20 > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack"=20 > or a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers exhibit different behavior, especially when=20 > dealing with "multipart" MIME messages (i.e. documents which=20 > have been split up into multiple messages), so check your=20 > local documentation on how to manipulate these messages. > =20 > =20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. > Content-Type: text/plain > Content-ID: <2005-11-16150727.I-D@ietf.org> >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce >=20 > ------ Fin del mensaje reenviado >=20 >=20 >=20 >=20 > ************************************ > The IPv6 Portal: http://www.ipv6tf.org >=20 > Barcelona 2005 Global IPv6 Summit > Information available at: > http://www.ipv6-es.com >=20 > This electronic message contains information which may be=20 > privileged or confidential. The information is intended to be=20 > for the use of the individual(s) named above. If you are not=20 > the intended recipient be aware that any disclosure, copying,=20 > distribution or use of the contents of this information,=20 > including attached files, is prohibited. >=20 >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Nov 23 12:49:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeykZ-0006ni-Mo for v6ops-archive@megatron.ietf.org; Wed, 23 Nov 2005 12:49:43 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03120 for ; Wed, 23 Nov 2005 12:49:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeyhX-0001gB-Kv for v6ops-data@psg.com; Wed, 23 Nov 2005 17:46:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [47.129.242.56] (helo=zcars04e.ca.nortel.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeyhW-0001fu-S7 for v6ops@ops.ietf.org; Wed, 23 Nov 2005 17:46:35 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id jANHhQY15866 for ; Wed, 23 Nov 2005 12:43:27 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F055.D717CC5A" Subject: IPv4 vs. IPv6 operational costs Date: Wed, 23 Nov 2005 12:46:31 -0500 Message-ID: Thread-Topic: IPv4 vs. IPv6 operational costs Thread-Index: AcXwVdamcYCgQF2hSMWFu5pUSkvWvg== From: "Dwight Jamieson" To: Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F055.D717CC5A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is anyone aware of any studies that quantify the differences between the operating costs of an IPv4 network using private addressing vs. an IPv6 network using globally unique addresses? Cheers, Dwight ------_=_NextPart_001_01C5F055.D717CC5A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IPv4 vs. IPv6 operational costs


Is anyone aware of any studies that = quantify the differences between the operating costs of an IPv4 network = using private addressing vs. an IPv6 network using globally unique = addresses?

Cheers,
Dwight

------_=_NextPart_001_01C5F055.D717CC5A-- From owner-v6ops@ops.ietf.org Wed Nov 23 13:18:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EezCm-00028m-2N for v6ops-archive@megatron.ietf.org; Wed, 23 Nov 2005 13:18:52 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06901 for ; Wed, 23 Nov 2005 13:18:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EezBT-0004Rt-Hp for v6ops-data@psg.com; Wed, 23 Nov 2005 18:17:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EezBS-0004Rg-VW for v6ops@ops.ietf.org; Wed, 23 Nov 2005 18:17:31 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 23 Nov 2005 10:17:30 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jANIHSs2026162; Wed, 23 Nov 2005 10:17:28 -0800 (PST) Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jANIPghR003368; Wed, 23 Nov 2005 10:25:43 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2367721F-D457-4319-8E60-BEF7376BCAC1@cisco.com> Cc: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: IPv4 vs. IPv6 operational costs Date: Wed, 23 Nov 2005 10:17:17 -0800 To: "Dwight Jamieson" X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=346; t=1132770343; x=1133202543; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20IPv4=20vs.=20IPv6=20operational=20costs| From:Fred=20Baker=20| Date:Wed,=2023=20Nov=202005=2010=3A17=3A17=20-0800| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=DtesTrUL3q40C/AKWG1N5FCpHCVGdSuOjy+kn9kgvhrt2cazEX6LrUIH0SqS3WLJFV9RW8i+ OvgG7O7PrbdXiKHqLFTsGw+B1rBvDeDGV0gxNmBcw7+jMbObnxNMN6vRFgGON1Y/1vzijiPn8Uw R0PvFd0h+4HEi1OnpfYIWqU4= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Nov 23, 2005, at 9:46 AM, Dwight Jamieson wrote: > Is anyone aware of any studies that quantify the differences > between the operating costs of an IPv4 network using private > addressing vs. an IPv6 network using globally unique addresses? I'm not. What would lead you to believe that IPv6 networks, or IPv4 networks with global addressing, should have different costs than IPv4 networks with local addressing? From owner-v6ops@ops.ietf.org Wed Nov 23 13:27:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EezL7-0000ZT-48 for v6ops-archive@megatron.ietf.org; Wed, 23 Nov 2005 13:27:29 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07814 for ; Wed, 23 Nov 2005 13:26:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EezKE-0005Bb-Ec for v6ops-data@psg.com; Wed, 23 Nov 2005 18:26:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EezKD-0005BP-Kc for v6ops@ops.ietf.org; Wed, 23 Nov 2005 18:26:33 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jANIQTI00548; Wed, 23 Nov 2005 13:26:30 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: IPv4 vs. IPv6 operational costs Date: Wed, 23 Nov 2005 13:26:16 -0500 Message-ID: Thread-Topic: IPv4 vs. IPv6 operational costs Thread-Index: AcXwWlX9B2jBRwAjTPKTUOWLxqoLJwAABsuw From: "Dwight Jamieson" To: "Fred Baker" Cc: Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable My assumption is that there are operating costs associated with NAT devices and ALGs. I've heard anecdotal evidence that these costs can be significant.=20 -----Original Message----- From: Fred Baker [mailto:fred@cisco.com]=20 Sent: Wednesday, November 23, 2005 1:17 PM To: Jamieson, Dwight [CAR:NP10:EXCH] Cc: v6ops@ops.ietf.org Subject: Re: IPv4 vs. IPv6 operational costs On Nov 23, 2005, at 9:46 AM, Dwight Jamieson wrote: > Is anyone aware of any studies that quantify the differences > between the operating costs of an IPv4 network using private =20 > addressing vs. an IPv6 network using globally unique addresses? I'm not. What would lead you to believe that IPv6 networks, or IPv4 =20 networks with global addressing, should have different costs than =20 IPv4 networks with local addressing? From owner-v6ops@ops.ietf.org Wed Nov 23 13:34:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EezRa-0005lG-Ng for v6ops-archive@megatron.ietf.org; Wed, 23 Nov 2005 13:34:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08542 for ; Wed, 23 Nov 2005 13:33:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EezQa-0005kd-6v for v6ops-data@psg.com; Wed, 23 Nov 2005 18:33:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EezQZ-0005kQ-69 for v6ops@ops.ietf.org; Wed, 23 Nov 2005 18:33:07 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jANIWUI07351; Wed, 23 Nov 2005 20:32:36 +0200 Date: Wed, 23 Nov 2005 20:32:30 +0200 (EET) From: Pekka Savola To: Dwight Jamieson cc: v6ops@ops.ietf.org Subject: Re: IPv4 vs. IPv6 operational costs In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 23 Nov 2005, Dwight Jamieson wrote: > Is anyone aware of any studies that quantify the differences between the > operating costs of an IPv4 network using private addressing vs. an IPv6 > network using globally unique addresses? I've not but I'd be interested to see _real_ calculations. I assume from your wording that you're referring to an IPv6-only network. If so, my suspicion is that the costs can be high as you need to live on the bleeding edge, i.e., are the one that'll find the bugs, need to get a lot of consulting to get the network to work as v6-only, etc. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Nov 23 13:48:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EezfF-0006QS-9B for v6ops-archive@megatron.ietf.org; Wed, 23 Nov 2005 13:48:17 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10370 for ; Wed, 23 Nov 2005 13:47:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EezeG-0007BT-0m for v6ops-data@psg.com; Wed, 23 Nov 2005 18:47:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [47.140.192.55] (helo=zrtps0kn.nortelnetworks.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eeze5-00078f-Bx for v6ops@ops.ietf.org; Wed, 23 Nov 2005 18:47:05 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jANIkq515641; Wed, 23 Nov 2005 13:46:53 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: v6ops:IPv4 vs. IPv6 operational costs Date: Wed, 23 Nov 2005 13:46:51 -0500 Message-ID: Thread-Topic: v6ops:IPv4 vs. IPv6 operational costs Thread-Index: AcXwXFiX/zJ1IEfyQTmqgUjjd3GPjwAAEjrA From: "Dwight Jamieson" To: "Pekka Savola" Cc: Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Pekka, Looking a few years down the road, assuming that bulk of the bleeding is over, will operating that network be simpler, easier, cheaper than operating a network with private addressing today? How painful is introducing new applications behind NAT/ALGs? What percentage of an IT department's budget spent on issues relating to private addressing? -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi]=20 Sent: Wednesday, November 23, 2005 1:33 PM To: Jamieson, Dwight [CAR:NP10:EXCH] Cc: v6ops@ops.ietf.org Subject: Re: IPv4 vs. IPv6 operational costs On Wed, 23 Nov 2005, Dwight Jamieson wrote: > Is anyone aware of any studies that quantify the differences between=20 > the operating costs of an IPv4 network using private addressing vs. an > IPv6 network using globally unique addresses? I've not but I'd be interested to see _real_ calculations. I assume from your wording that you're referring to an IPv6-only=20 network. If so, my suspicion is that the costs can be high as you=20 need to live on the bleeding edge, i.e., are the one that'll find the=20 bugs, need to get a lot of consulting to get the network to work as=20 v6-only, etc. --=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 From owner-v6ops@ops.ietf.org Wed Nov 23 14:29:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef0Ip-00011E-PL for v6ops-archive@megatron.ietf.org; Wed, 23 Nov 2005 14:29:12 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15037 for ; Wed, 23 Nov 2005 14:28:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ef0HE-000AWb-EN for v6ops-data@psg.com; Wed, 23 Nov 2005 19:27:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,HTML_30_40, HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [20.137.2.248] (helo=amer-mta02.csc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Ef0HD-000AWP-Ff; Wed, 23 Nov 2005 19:27:31 +0000 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta02.csc.com (8.12.11/Switch-3.1.6) with ESMTP id jANJRRSw026998; Wed, 23 Nov 2005 14:27:27 -0500 (EST) In-Reply-To: To: "Dwight Jamieson" Cc: owner-v6ops@ops.ietf.org, "Pekka Savola" , v6ops@ops.ietf.org Subject: RE: v6ops:IPv4 vs. IPv6 operational costs MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Joe Loiacono X-MIMETrack: S/MIME Sign by Notes Client on Joe Loiacono/CIV/CSC(652HF83|November 04, 2004) at 11/23/2005 02:30:54 PM, Serialize by Notes Client on Joe Loiacono/CIV/CSC(652HF83|November 04, 2004) at 11/23/2005 02:30:54 PM, Serialize complete at 11/23/2005 02:30:54 PM, S/MIME Sign failed at 11/23/2005 02:30:54 PM: The cryptographic key was not found, Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 11/23/2005 02:26:56 PM, Serialize complete at 11/23/2005 02:26:56 PM Message-ID: Date: Wed, 23 Nov 2005 14:27:26 -0500 Content-Type: multipart/alternative; boundary="=_alternative 006B3308852570C2_=" Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 006B3308852570C2_= Content-Type: text/plain; charset="US-ASCII" It's my understanding that if you run an IPv6 only network, you will still need a NAT (e.g., NAT-PT) anyway to talk with v4 hosts. Joe "Dwight Jamieson" Sent by: owner-v6ops 11/23/2005 01:46 PM To: "Pekka Savola" cc: Subject: RE: v6ops:IPv4 vs. IPv6 operational costs Pekka, Looking a few years down the road, assuming that bulk of the bleeding is over, will operating that network be simpler, easier, cheaper than operating a network with private addressing today? How painful is introducing new applications behind NAT/ALGs? What percentage of an IT department's budget spent on issues relating to private addressing? -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Wednesday, November 23, 2005 1:33 PM To: Jamieson, Dwight [CAR:NP10:EXCH] Cc: v6ops@ops.ietf.org Subject: Re: IPv4 vs. IPv6 operational costs On Wed, 23 Nov 2005, Dwight Jamieson wrote: > Is anyone aware of any studies that quantify the differences between > the operating costs of an IPv4 network using private addressing vs. an > IPv6 network using globally unique addresses? I've not but I'd be interested to see _real_ calculations. I assume from your wording that you're referring to an IPv6-only network. If so, my suspicion is that the costs can be high as you need to live on the bleeding edge, i.e., are the one that'll find the bugs, need to get a lot of consulting to get the network to work as v6-only, etc. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --=_alternative 006B3308852570C2_= Content-Type: text/html; charset="US-ASCII"
It's my understanding that if you run an IPv6 only network, you will still need a NAT (e.g., NAT-PT) anyway to talk with v4 hosts.

Joe


"Dwight Jamieson" <djamies
@nortel.com>
Sent by: owner-v6ops

11/23/2005 01:46 PM

       
        To:        "Pekka Savola" <pekkas@netcore.fi>
        cc:        <v6ops@ops.ietf.org>
        Subject:        RE: v6ops:IPv4 vs. IPv6 operational costs



Pekka,

Looking a few years down the road, assuming that bulk of the bleeding is
over, will operating that network be simpler, easier, cheaper than
operating a network with private addressing today?

How painful is introducing new applications behind NAT/ALGs? What
percentage of an IT department's budget spent on issues relating to
private addressing?


-----Original Message-----
From: Pekka Savola [mailto:pekkas@netcore.fi]
Sent: Wednesday, November 23, 2005 1:33 PM
To: Jamieson, Dwight [CAR:NP10:EXCH]
Cc: v6ops@ops.ietf.org
Subject: Re: IPv4 vs. IPv6 operational costs


On Wed, 23 Nov 2005, Dwight Jamieson wrote:
> Is anyone aware of any studies that quantify the differences between
> the operating costs of an IPv4 network using private addressing vs. an

> IPv6 network using globally unique addresses?

I've not but I'd be interested to see _real_ calculations.

I assume from your wording that you're referring to an IPv6-only
network.  If so, my suspicion is that the costs can be high as you
need to live on the bleeding edge, i.e., are the one that'll find the
bugs, need to get a lot of consulting to get the network to work as
v6-only, etc.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--=_alternative 006B3308852570C2_=-- From owner-v6ops@ops.ietf.org Wed Nov 23 14:43:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef0Wu-0001Sc-1e for v6ops-archive@megatron.ietf.org; Wed, 23 Nov 2005 14:43:44 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18664 for ; Wed, 23 Nov 2005 14:43:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ef0Vo-000Bwb-24 for v6ops-data@psg.com; Wed, 23 Nov 2005 19:42:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ef0Vl-000BwI-C2 for v6ops@ops.ietf.org; Wed, 23 Nov 2005 19:42:33 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jANJfiP08811; Wed, 23 Nov 2005 21:41:51 +0200 Date: Wed, 23 Nov 2005 21:41:44 +0200 (EET) From: Pekka Savola To: Dwight Jamieson cc: v6ops@ops.ietf.org Subject: RE: v6ops:IPv4 vs. IPv6 operational costs In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 23 Nov 2005, Dwight Jamieson wrote: > Looking a few years down the road, assuming that bulk of the bleeding is > over, will operating that network be simpler, easier, cheaper than > operating a network with private addressing today? Once that point is reached, I'd suspect so. There's also an alternative or a variation: keep using the existing v4 infrastructure (for simpler applications), but introduce the new apps to (only) v6. > How painful is introducing new applications behind NAT/ALGs? What > percentage of an IT department's budget spent on issues relating to > private addressing? That's a good question. I'd guess that getting non-trivial apps (e.g., VoIP, video conferencing, etc.) to work across NATs is non-trivial exercise. I'd guess that most cost is borne by those folks who write and need to support those applications. That includes the enterprise if the app is important enough to the enterprise. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Nov 23 14:57:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef0jl-0000DP-S8 for v6ops-archive@megatron.ietf.org; Wed, 23 Nov 2005 14:57:02 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20387 for ; Wed, 23 Nov 2005 14:56:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ef0iV-000Dmr-Mo for v6ops-data@psg.com; Wed, 23 Nov 2005 19:55:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [194.138.37.40] (helo=gecko.sbs.de) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ef0iU-000DmV-HR for v6ops@ops.ietf.org; Wed, 23 Nov 2005 19:55:42 +0000 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id jANJtPpG014627; Wed, 23 Nov 2005 20:55:25 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id jANJtPq4016705; Wed, 23 Nov 2005 20:55:25 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.146]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Nov 2005 20:55:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: v6ops:IPv4 vs. IPv6 operational costs Date: Wed, 23 Nov 2005 20:55:24 +0100 Message-ID: Thread-Topic: v6ops:IPv4 vs. IPv6 operational costs Thread-Index: AcXwXFiX/zJ1IEfyQTmqgUjjd3GPjwAAEjrAAAJbOVA= From: "Sofia, Rute" To: "Dwight Jamieson" , "Pekka Savola" Cc: X-OriginalArrivalTime: 23 Nov 2005 19:55:25.0150 (UTC) FILETIME=[D85257E0:01C5F067] Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello, Considering IPv4, a NAT "serves" two purposes: from a basic perspective, either within the operator's net (to deal with overlapping IPs) or to allow a set of devices to achieve global IP connectivity by means of a single (globally routable) IP address. Assuming that you are referring to the most popular option - the second - then using a NAT requires workarounds to allow bi-directionality and to cope with applications that embed IP addresses in the payload. Being a translation solution, the first problem is that it adds entropy to the end-to-end path. Notice that in most cases, translation may be required in more than one point. Furthermore, ALGs have to be developed for already existing applications, or new applications *must* consider that a NAT is in the way. Or, NAT traversal techniques (STUN, etc.) can be applied but again, there is always entropy added. Is it very hard to deploy an ALG, or to rely on NAT traversal techniques? Not really, but the problem is again: entropy added to the end-to-end path and each time a new application emerges, one has to find a way to deal with the NAT...this means that new services are now in most cases dictated by the NAT existence which is pretty limitative. Imagine trying to place in the future multicast sources behind a NAT, for instance...or using mobility... I do not know if it's possible to "quantify" the operational costs of NAT+private addressing vs. IPv6. In fact, IMHO that does not really make sense. Particularly because the operator has no chance to really reach anything behind a NAT - unless you are referring to the use of a NAT somewhere in the access, not in the extremes, as mentioned. So, IMHO, what can be compared: the possibility of having *global* connectivity per device - new services will for sure appear. And, due to autoconfiguration it is possible to simplify the operations required to provide connectivity to a group of devices. Despite the fact that such features may or not be complete within the current standards - they are not - the fact is that IPv6 autoconfiguration is one of the most interesting features IPv6 has. Regards, Rute =20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Dwight Jamieson > Sent: Wednesday, November 23, 2005 7:47 PM > To: Pekka Savola > Cc: v6ops@ops.ietf.org > Subject: RE: v6ops:IPv4 vs. IPv6 operational costs >=20 > Pekka, >=20 > Looking a few years down the road, assuming that bulk of the=20 > bleeding is > over, will operating that network be simpler, easier, cheaper than > operating a network with private addressing today? >=20 > How painful is introducing new applications behind NAT/ALGs? What > percentage of an IT department's budget spent on issues relating to > private addressing? >=20 >=20 > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi]=20 > Sent: Wednesday, November 23, 2005 1:33 PM > To: Jamieson, Dwight [CAR:NP10:EXCH] > Cc: v6ops@ops.ietf.org > Subject: Re: IPv4 vs. IPv6 operational costs >=20 >=20 > On Wed, 23 Nov 2005, Dwight Jamieson wrote: > > Is anyone aware of any studies that quantify the=20 > differences between=20 > > the operating costs of an IPv4 network using private=20 > addressing vs. an >=20 > > IPv6 network using globally unique addresses? >=20 > I've not but I'd be interested to see _real_ calculations. >=20 > I assume from your wording that you're referring to an IPv6-only=20 > network. If so, my suspicion is that the costs can be high as you=20 > need to live on the bleeding edge, i.e., are the one that'll find the=20 > bugs, need to get a lot of consulting to get the network to work as=20 > v6-only, etc. >=20 > --=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 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Nov 23 14:58:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef0kz-0001Pc-VH for v6ops-archive@megatron.ietf.org; Wed, 23 Nov 2005 14:58:19 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20706 for ; Wed, 23 Nov 2005 14:57:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ef0kM-000E1Z-Ot for v6ops-data@psg.com; Wed, 23 Nov 2005 19:57:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [194.138.37.40] (helo=gecko.sbs.de) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ef0kL-000E1G-IG; Wed, 23 Nov 2005 19:57:38 +0000 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id jANJvMEc016292; Wed, 23 Nov 2005 20:57:22 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id jANJvMNb017983; Wed, 23 Nov 2005 20:57:22 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.146]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Nov 2005 20:57:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F068.1DB0E6ED" Subject: RE: v6ops:IPv4 vs. IPv6 operational costs Date: Wed, 23 Nov 2005 20:57:21 +0100 Message-ID: Thread-Topic: v6ops:IPv4 vs. IPv6 operational costs Thread-Index: AcXwZiiiQQP8HJ07RryERNl911ueIgAAcr3w From: "Sofia, Rute" To: "Joe Loiacono" , "Dwight Jamieson" Cc: , "Pekka Savola" , X-OriginalArrivalTime: 23 Nov 2005 19:57:21.0949 (UTC) FILETIME=[1DF074D0:01C5F068] Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F068.1DB0E6ED Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You may or not. You may rely on translation (some form of NAT, yes), or tunneling - 6to4, for instance. Or you may just consider that most of the nets are dual-stacked. =20 Rute =20 ________________________________ From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Joe Loiacono Sent: Wednesday, November 23, 2005 8:27 PM To: Dwight Jamieson Cc: owner-v6ops@ops.ietf.org; Pekka Savola; v6ops@ops.ietf.org Subject: RE: v6ops:IPv4 vs. IPv6 operational costs =09 =09 It's my understanding that if you run an IPv6 only network, you will still need a NAT (e.g., NAT-PT) anyway to talk with v4 hosts.=20 =09 Joe =09 =09 =09 =09 "Dwight Jamieson" =20 Sent by: owner-v6ops=20 11/23/2005 01:46 PM=20 =20 To: "Pekka Savola" =20 cc: =20 Subject: RE: v6ops:IPv4 vs. IPv6 operational costs Pekka, =09 Looking a few years down the road, assuming that bulk of the bleeding is over, will operating that network be simpler, easier, cheaper than operating a network with private addressing today? =09 How painful is introducing new applications behind NAT/ALGs? What percentage of an IT department's budget spent on issues relating to private addressing? =09 =09 -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi]=20 Sent: Wednesday, November 23, 2005 1:33 PM To: Jamieson, Dwight [CAR:NP10:EXCH] Cc: v6ops@ops.ietf.org Subject: Re: IPv4 vs. IPv6 operational costs =09 =09 On Wed, 23 Nov 2005, Dwight Jamieson wrote: > Is anyone aware of any studies that quantify the differences between=20 > the operating costs of an IPv4 network using private addressing vs. an =09 > IPv6 network using globally unique addresses? =09 I've not but I'd be interested to see _real_ calculations. =09 I assume from your wording that you're referring to an IPv6-only network. If so, my suspicion is that the costs can be high as you=20 need to live on the bleeding edge, i.e., are the one that'll find the=20 bugs, need to get a lot of consulting to get the network to work as=20 v6-only, etc. =09 --=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 =09 =09 =09 =09 ------_=_NextPart_001_01C5F068.1DB0E6ED Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
You may or not. You may rely on translation = (some form of=20 NAT, yes), or tunneling - 6to4, for instance. Or you may just consider = that most=20 of the nets are dual-stacked.
 
Rute
 

From: owner-v6ops@ops.ietf.org=20 [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Joe=20 Loiacono
Sent: Wednesday, November 23, 2005 8:27 = PM
To:=20 Dwight Jamieson
Cc: owner-v6ops@ops.ietf.org; Pekka Savola;=20 v6ops@ops.ietf.org
Subject: RE: v6ops:IPv4 vs. IPv6 = operational=20 costs


It's my understanding = that if you=20 run an IPv6 only network, you will still need a NAT (e.g., NAT-PT) = anyway to=20 talk with v4 hosts.

Joe



"Dwight Jamieson"=20 <djamies
@nortel.com>
Sent by: owner-v6ops=20

11/23/2005 01:46 PM =

        =
        To: =    =20    "Pekka Savola" <pekkas@netcore.fi> =
        cc: =    =20    <v6ops@ops.ietf.org>
        Subject:     =  =20  RE: v6ops:IPv4 vs. IPv6 operational=20 costs



Pekka,

Looking a few years down the road, assuming = that bulk=20 of the bleeding is
over, will operating that network be simpler, = easier,=20 cheaper than
operating a network with private addressing = today?

How=20 painful is introducing new applications behind NAT/ALGs? = What
percentage of=20 an IT department's budget spent on issues relating to
private=20 addressing?


-----Original Message-----
From: Pekka = Savola=20 [mailto:pekkas@netcore.fi]
Sent: Wednesday, November 23, 2005 1:33 = PM
To: Jamieson, Dwight [CAR:NP10:EXCH]
Cc:=20 v6ops@ops.ietf.org
Subject: Re: IPv4 vs. IPv6 operational=20 costs


On Wed, 23 Nov 2005, Dwight Jamieson wrote:
> = Is anyone=20 aware of any studies that quantify the differences between
> = the=20 operating costs of an IPv4 network using private addressing vs. = an

>=20 IPv6 network using globally unique addresses?

I've not but I'd = be=20 interested to see _real_ calculations.

I assume from your = wording that=20 you're referring to an IPv6-only
network.  If so, my = suspicion is=20 that the costs can be high as you
need to live on the bleeding = edge, i.e.,=20 are the one that'll find the
bugs, need to get a lot of consulting = to get=20 the network to work as
v6-only, etc.

--
Pekka Savola =  =20               "You each name = yourselves=20 king, yet the
Netcore Oy             =  =20      kingdom bleeds."
Systems. Networks. Security. = -- George=20 R.R. Martin: A Clash of=20 Kings



------_=_NextPart_001_01C5F068.1DB0E6ED-- From owner-v6ops@ops.ietf.org Wed Nov 23 15:01:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef0o4-0003CG-Tt for v6ops-archive@megatron.ietf.org; Wed, 23 Nov 2005 15:01:28 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21173 for ; Wed, 23 Nov 2005 15:00:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ef0nL-000ES9-2f for v6ops-data@psg.com; Wed, 23 Nov 2005 20:00:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ef0nI-000ERO-BZ for v6ops@ops.ietf.org; Wed, 23 Nov 2005 20:00:40 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jANK0UI23385; Wed, 23 Nov 2005 15:00:31 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F068.7C5B002B" Subject: RE: v6ops:IPv4 vs. IPv6 operational costs Date: Wed, 23 Nov 2005 14:59:59 -0500 Message-ID: Thread-Topic: v6ops:IPv4 vs. IPv6 operational costs Thread-Index: AcXwZgusfzQaim1OSzatyCF/gZ5nvAAAP8lg From: "Dwight Jamieson" To: "Pekka Savola" Cc: Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F068.7C5B002B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >On Wed, 23 Nov 2005, Dwight Jamieson wrote: >> Looking a few years down the road, assuming that bulk of the bleeding >> is over, will operating that network be simpler, easier, cheaper than >> operating a network with private addressing today? >Once that point is reached, I'd suspect so. There's also an=20 >alternative or a variation: keep using the existing v4 infrastructure=20 >(for simpler applications), but introduce the new apps to (only) v6. Yes, that would be the transition path. New apps would be v6 only.=20 Existing apps would be transitioned to v6 only, as soon as that makes sense The core would be transitioned to IPv6 soon as it makes sense Hosts would remain dual stack as long as v4 only services need to be reached - tunnel hosts v4/v6 to a dual stack router/relay - of course this requires NAT, but hopefully limited ALG support >> How painful is introducing new applications behind NAT/ALGs? What=20 >> percentage of an IT department's budget spent on issues relating to=20 >> private addressing? >That's a good question. I'd guess that getting non-trivial apps=20 >(e.g., VoIP, video conferencing, etc.) to work across NATs is=20 >non-trivial exercise. I'd guess that most cost is borne by those=20 >folks who write and need to support those applications. That includes=20 >the enterprise if the app is important enough to the enterprise. --=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 ------_=_NextPart_001_01C5F068.7C5B002B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: v6ops:IPv4 vs. IPv6 operational costs



>On Wed, 23 Nov 2005, Dwight Jamieson = wrote:
>> Looking a few years down the road, assuming = that bulk of the bleeding
>> is over, will operating that network be = simpler, easier, cheaper than
>> operating a network with private addressing = today?

>Once that point is reached, I'd suspect = so.  There's also an
>alternative or a variation: keep using the = existing v4 infrastructure
>(for simpler applications), but introduce the = new apps to (only) v6.

Yes, that would be = the transition path. New apps would be v6 only.
Existing apps = would be transitioned to v6 only, as soon as that makes = sense
The core would be = transitioned to IPv6 soon as it makes sense
Hosts would = remain dual stack as long as v4 only services need to be = reached
 - tunnel = hosts v4/v6 to a dual stack router/relay
 - of course = this requires NAT, but hopefully limited ALG support


>> How painful is introducing new applications = behind NAT/ALGs? What
>> percentage of an IT department's budget = spent on issues relating to
>> private addressing?

>That's a good question.  I'd guess that = getting non-trivial apps
>(e.g., VoIP, video conferencing, etc.) to work = across NATs is
>non-trivial exercise.  I'd guess that most = cost is borne by those
>folks who write and need to support those = applications.  That includes
>the enterprise if the app is important enough to = the enterprise.

--
Pekka = Savola           &= nbsp;     "You each name yourselves king, yet = the
Netcore = Oy            = ;        kingdom = bleeds."
Systems. = Networks. Security. -- George R.R. Martin: A Clash of = Kings

------_=_NextPart_001_01C5F068.7C5B002B-- From owner-v6ops@ops.ietf.org Wed Nov 23 15:02:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef0p8-0003qS-2I for v6ops-archive@megatron.ietf.org; Wed, 23 Nov 2005 15:02:34 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21383 for ; Wed, 23 Nov 2005 15:01:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ef0oB-000EYM-PK for v6ops-data@psg.com; Wed, 23 Nov 2005 20:01:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ef0o9-000EXw-3K for v6ops@ops.ietf.org; Wed, 23 Nov 2005 20:01:33 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 23 Nov 2005 12:01:33 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jANK1WCJ004073; Wed, 23 Nov 2005 12:01:32 -0800 (PST) Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jANK9kWQ004573; Wed, 23 Nov 2005 12:09:46 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6D1DAA23-09DD-4976-9C25-B21B3C2C9030@cisco.com> Cc: "Pekka Savola" , Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: v6ops:IPv4 vs. IPv6 operational costs Date: Wed, 23 Nov 2005 12:01:21 -0800 To: "Dwight Jamieson" X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=4354; t=1132776587; x=1133208787; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20v6ops=3AIPv4=20vs.=20IPv6=20operational=20costs| From:Fred=20Baker=20| Date:Wed,=2023=20Nov=202005=2012=3A01=3A21=20-0800| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=g7y5XHQIJ1Y4jK22KE5WKLHOa7hIu6Epvl1yqUdWaxxLoNtO2vxL9Q6zjZyvwRVSrs9Ioysw UPQRrB3xgBlTHi2b+tjoUpLAreJzzuLSSBOc6uPI1K5kcRweM5h7+apiN+J5dG82nvA5oPR3Hk5 lBoLKRsy60JZri2XljylhLTU= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit These are a lot of questions. Chair hat off. There is a desire on the part of most networks to provide external access to only those systems that require external access. There are a list of reasons, but they all boil down to some flavor of "security". If you haven't read it, draft-ietf-v6ops-nap-02.txt gives a fairly thorough discussion of this. There is one problem with this - one has to in some way filter out external traffic coming into the network directed to those addresses. That can be with an ACL, by a stronger firewall, or whatever one likes. My preferred solution is truly simple-minded - make the external- facing systems be *only* globally addressable, and in them program a null route to the prefix that one is using for one's internal-only systems (in IPv6, the internal interface would be addressed using a link-local address and one would route to the external-facing interface or to a loop-back address). It's a really cheap filter, and there is nothing quite like an air gap... Note that this would work whether the internal prefix is private or public. It also works for both IPv4 and IPv6 - if you're an IPv4 ISP and are using 192.168.0.0/16 to address your internal-only systems, it works fine, and if you're an enterprise using a global address (Cisco uses some subset of 171.70.0.0/16 for internal data centers, for example) you can shield them just as effectively that way. It does mean that said internal-only systems are truly internal-only - they can't, for example, do a direct web access to the great wide world, or SMTP to some remote system - they have to go through a proxy of some sort. I don't know about Nortel, but Cisco does that at least for SMTP anyway, and one could imagine doing the same for other applications. Solves the multi-homing problem too, at least at the local end. The first problem with introducing new applications behinds NATs/ALGs is that one has to have an ALG to deploy the application. Ask yourself how the web was popularized, and ask yourself whether the requisite proxy technology would have been deployed at your favorite company without there first being a business case to support it. If we were trying to deploy the web today, I'm not sure we would be able to do so. Note that we would have the same problem with the above "air gap" suggestion, apart from the fact that the department in question might simply choose to deploy its web access using globally addressable systems. The second problem relates to the kind of application. The web is essentially client-server, so the only system that needs anything resembling a permanent address is the web server. There is no need for IP Mobility etc for the client - it works just fine using whatever address DHCP gave the client most recently, regardless of how a NAT munges the address. Now say VoIP... in a peer-to-peer application anyone can "call" the system, so it needs an address at the time that they "call" it. We can put a gateway into a NAT/ Firewall if we like; the SIP Proxy lives in the Linksys box or whatever, the telephone maintains a relationship with the proxy, and when a remote system sends an INVITE to the proxy referencing the name of the relevant telephone or group of telephones, the proxy can program the NAT link things up. Heck, it can even make the NAT translation of the destination address be a multicast address if appropriate. But if you want to do it without the proxy, you *have* to have a global address if you want to call outside, or you have to maintain a relationship with someone who does (as peer2peer applications often do for NAT traversal). The question is whether you want to be called from outside. If we can simply assume that anyone is accessible from anywhere, all that goes away - it becomes easier to deploy a new application, and it becomes easier to ddos the system deploying it. On Nov 23, 2005, at 10:46 AM, Dwight Jamieson wrote: > Pekka, > > Looking a few years down the road, assuming that bulk of the > bleeding is > over, will operating that network be simpler, easier, cheaper than > operating a network with private addressing today? > > How painful is introducing new applications behind NAT/ALGs? What > percentage of an IT department's budget spent on issues relating to > private addressing? > > > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Wednesday, November 23, 2005 1:33 PM > To: Jamieson, Dwight [CAR:NP10:EXCH] > Cc: v6ops@ops.ietf.org > Subject: Re: IPv4 vs. IPv6 operational costs > > > On Wed, 23 Nov 2005, Dwight Jamieson wrote: >> Is anyone aware of any studies that quantify the differences between >> the operating costs of an IPv4 network using private addressing >> vs. an > >> IPv6 network using globally unique addresses? > > I've not but I'd be interested to see _real_ calculations. > > I assume from your wording that you're referring to an IPv6-only > network. If so, my suspicion is that the costs can be high as you > need to live on the bleeding edge, i.e., are the one that'll find the > bugs, need to get a lot of consulting to get the network to work as > v6-only, etc. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Nov 23 15:16:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef12W-0001x5-D3 for v6ops-archive@megatron.ietf.org; Wed, 23 Nov 2005 15:16:24 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23016 for ; Wed, 23 Nov 2005 15:15:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ef11T-000GMM-5R for v6ops-data@psg.com; Wed, 23 Nov 2005 20:15:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_40_50, HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [20.137.2.248] (helo=amer-mta02.csc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Ef11S-000GLz-8j; Wed, 23 Nov 2005 20:15:18 +0000 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta02.csc.com (8.12.11/Switch-3.1.6) with ESMTP id jANKFDv7004297; Wed, 23 Nov 2005 15:15:13 -0500 (EST) In-Reply-To: To: "Sofia, Rute" Cc: "Dwight Jamieson" , owner-v6ops@ops.ietf.org, "Pekka Savola" , v6ops@ops.ietf.org Subject: RE: v6ops:IPv4 vs. IPv6 operational costs MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Joe Loiacono X-MIMETrack: S/MIME Sign by Notes Client on Joe Loiacono/CIV/CSC(652HF83|November 04, 2004) at 11/23/2005 03:18:24 PM, Serialize by Notes Client on Joe Loiacono/CIV/CSC(652HF83|November 04, 2004) at 11/23/2005 03:18:24 PM, Serialize complete at 11/23/2005 03:18:24 PM, S/MIME Sign failed at 11/23/2005 03:18:25 PM: The cryptographic key was not found, Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 11/23/2005 03:14:41 PM, Serialize complete at 11/23/2005 03:14:41 PM Message-ID: Date: Wed, 23 Nov 2005 15:15:11 -0500 Content-Type: multipart/alternative; boundary="=_alternative 006F8C34852570C2_=" Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 006F8C34852570C2_= Content-Type: text/plain; charset="US-ASCII" I need to take a closer look at 6to4. Thanks. >Or you may just consider that most of the nets are dual-stacked. It may be a long time before even a moderate portion of hosts are dual-stacked, in the sense that IPv6 is enabled on the hosts and intermediate networks route it and DNS supports it. At least in the US. Joe "Sofia, Rute" 11/23/2005 02:57 PM To: Joe Loiacono/CIV/CSC@CSC, "Dwight Jamieson" cc: , "Pekka Savola" , Subject: RE: v6ops:IPv4 vs. IPv6 operational costs You may or not. You may rely on translation (some form of NAT, yes), or tunneling - 6to4, for instance. Or you may just consider that most of the nets are dual-stacked. Rute From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Joe Loiacono Sent: Wednesday, November 23, 2005 8:27 PM To: Dwight Jamieson Cc: owner-v6ops@ops.ietf.org; Pekka Savola; v6ops@ops.ietf.org Subject: RE: v6ops:IPv4 vs. IPv6 operational costs It's my understanding that if you run an IPv6 only network, you will still need a NAT (e.g., NAT-PT) anyway to talk with v4 hosts. Joe "Dwight Jamieson" Sent by: owner-v6ops 11/23/2005 01:46 PM To: "Pekka Savola" cc: Subject: RE: v6ops:IPv4 vs. IPv6 operational costs Pekka, Looking a few years down the road, assuming that bulk of the bleeding is over, will operating that network be simpler, easier, cheaper than operating a network with private addressing today? How painful is introducing new applications behind NAT/ALGs? What percentage of an IT department's budget spent on issues relating to private addressing? -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Wednesday, November 23, 2005 1:33 PM To: Jamieson, Dwight [CAR:NP10:EXCH] Cc: v6ops@ops.ietf.org Subject: Re: IPv4 vs. IPv6 operational costs On Wed, 23 Nov 2005, Dwight Jamieson wrote: > Is anyone aware of any studies that quantify the differences between > the operating costs of an IPv4 network using private addressing vs. an > IPv6 network using globally unique addresses? I've not but I'd be interested to see _real_ calculations. I assume from your wording that you're referring to an IPv6-only network. If so, my suspicion is that the costs can be high as you need to live on the bleeding edge, i.e., are the one that'll find the bugs, need to get a lot of consulting to get the network to work as v6-only, etc. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --=_alternative 006F8C34852570C2_= Content-Type: text/html; charset="US-ASCII"
I need to take a closer look at 6to4. Thanks.

>Or you may just consider that most of the nets are dual-stacked.

It may be a long time before even a moderate portion of hosts are dual-stacked, in the sense that IPv6 is enabled on the hosts and intermediate networks route it and DNS supports it. At least in the US.
Joe


"Sofia, Rute" <rute.sofia
@siemens.com>

11/23/2005 02:57 PM

       
        To:        Joe Loiacono/CIV/CSC@CSC, "Dwight Jamieson" <djamies@nortel.com>
        cc:        <owner-v6ops@ops.ietf.org>, "Pekka Savola" <pekkas@netcore.fi>, <v6ops@ops.ietf.org>
        Subject:        RE: v6ops:IPv4 vs. IPv6 operational costs



You may or not. You may rely on translation (some form of NAT, yes), or tunneling - 6to4, for instance. Or you may just consider that most of the nets are dual-stacked.
 
Rute
 

From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Joe Loiacono
Sent: Wednesday, November 23, 2005 8:27 PM
To: Dwight Jamieson
Cc: owner-v6ops@ops.ietf.org; Pekka Savola; v6ops@ops.ietf.org
Subject: RE: v6ops:IPv4 vs. IPv6 operational costs

It's my understanding that if you run an IPv6 only network, you will still need a NAT (e.g., NAT-PT) anyway to talk with v4 hosts.

Joe
"Dwight Jamieson" <djamies
@nortel.com>
Sent by: owner-v6ops

11/23/2005 01:46 PM

       
       To:        "Pekka Savola" <pekkas@netcore.fi>
       cc:        <v6ops@ops.ietf.org>
       Subject:        RE: v6ops:IPv4 vs. IPv6 operational costs




Pekka,

Looking a few years down the road, assuming that bulk of the bleeding is
over, will operating that network be simpler, easier, cheaper than
operating a network with private addressing today?

How painful is introducing new applications behind NAT/ALGs? What
percentage of an IT department's budget spent on issues relating to
private addressing?


-----Original Message-----
From: Pekka Savola [mailto:pekkas@netcore.fi]
Sent: Wednesday, November 23, 2005 1:33 PM
To: Jamieson, Dwight [CAR:NP10:EXCH]
Cc: v6ops@ops.ietf.org
Subject: Re: IPv4 vs. IPv6 operational costs


On Wed, 23 Nov 2005, Dwight Jamieson wrote:
> Is anyone aware of any studies that quantify the differences between
> the operating costs of an IPv4 network using private addressing vs. an

> IPv6 network using globally unique addresses?

I've not but I'd be interested to see _real_ calculations.

I assume from your wording that you're referring to an IPv6-only
network.  If so, my suspicion is that the costs can be high as you
need to live on the bleeding edge, i.e., are the one that'll find the
bugs, need to get a lot of consulting to get the network to work as
v6-only, etc.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--=_alternative 006F8C34852570C2_=-- From owner-v6ops@ops.ietf.org Wed Nov 23 16:23:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef25t-0007VZ-BW for v6ops-archive@megatron.ietf.org; Wed, 23 Nov 2005 16:23:57 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01242 for ; Wed, 23 Nov 2005 16:23:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ef23h-000MqX-2P for v6ops-data@psg.com; Wed, 23 Nov 2005 21:21:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ef23g-000MqJ-CL; Wed, 23 Nov 2005 21:21:40 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 23 Nov 2005 13:21:39 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jANLLaeS026610; Wed, 23 Nov 2005 13:21:36 -0800 (PST) Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jANLToC2005211; Wed, 23 Nov 2005 13:29:50 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <82323D35-67EE-4C5B-BF9E-9C84F78B7927@cisco.com> Cc: "Sofia, Rute" , "Dwight Jamieson" , owner-v6ops@ops.ietf.org, "Pekka Savola" , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: v6ops:IPv4 vs. IPv6 operational costs Date: Wed, 23 Nov 2005 13:21:25 -0800 To: Joe Loiacono X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=422; t=1132781390; x=1133213590; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20v6ops=3AIPv4=20vs.=20IPv6=20operational=20costs| From:Fred=20Baker=20| Date:Wed,=2023=20Nov=202005=2013=3A21=3A25=20-0800| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=IfyC6z+d/vRvHEacugPxD81jrzDj3uXeQB4VYz9sYGNSZ5zNp7Z4uxk0T9P7WaVtzhwOWR16 9ockhP3Qk6yCunXHQAKRaMIC2IcrfucP/UJLw03FVNXSwuF69yKEKdIdWqGxwECy4kZL1X8V4Bu qssyC5ECtsRLPx83bBtVgK7g= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit that would surprise me. My Mac is dual stacked now, and they tell me that Windows Leghorn (Longhorn?) will be as well. Comes that way out of the box. The question will be whether IT departments turn it on in the network, not whether the hosts will use it if hey do. On Nov 23, 2005, at 12:15 PM, Joe Loiacono wrote: > It may be a long time before even a moderate portion of hosts are > dual-stacked, in the sense that IPv6 is enabled on the hosts and > intermediate networks route it and DNS supports it. At least in the > US. From owner-v6ops@ops.ietf.org Thu Nov 24 04:28:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfDOl-0005al-Im for v6ops-archive@megatron.ietf.org; Thu, 24 Nov 2005 04:28:13 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06598 for ; Thu, 24 Nov 2005 04:27:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfDKy-00029j-8b for v6ops-data@psg.com; Thu, 24 Nov 2005 09:24:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [152.78.68.161] (helo=peewit.ecs.soton.ac.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EfDKu-00029X-I4 for v6ops@ops.ietf.org; Thu, 24 Nov 2005 09:24:12 +0000 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe23:58df]) by peewit.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id jAO9PnbV025591 for ; Thu, 24 Nov 2005 09:25:49 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id jAO9O4B15842 for v6ops@ops.ietf.org; Thu, 24 Nov 2005 09:24:04 GMT Date: Thu, 24 Nov 2005 09:24:04 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: v6ops:IPv4 vs. IPv6 operational costs Message-ID: <20051124092403.GM14900@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <82323D35-67EE-4C5B-BF9E-9C84F78B7927@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82323D35-67EE-4C5B-BF9E-9C84F78B7927@cisco.com> User-Agent: Mutt/1.4i X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@smtp.ecs.soton.ac.uk Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Nov 23, 2005 at 01:21:25PM -0800, Fred Baker wrote: > that would surprise me. My Mac is dual stacked now, and they tell me > that Windows Leghorn (Longhorn?) will be as well. Comes that way out > of the box. > > The question will be whether IT departments turn it on in the > network, not whether the hosts will use it if hey do. The question isn't only the 'cost', it's also about the benefit. You also need to define 'cost' :) Our experience of deploying dual-stack as far as open source and vendor provided solutions go on an enterprise of over 1,000 hosts is that the additional 'cost' is low. We didn't buy new hardware specifically for IPv6. We used to run a parallel IPv6 routing infrastructure on BSD, but went 'properly' dual stacked when we reprocured our old IPv4 equipment this summer. No extra cost per se. The MRs on the procurement meant the new kit supported IPv6 features (unicast amd multicast). The costs lie more in managing the additional protocol, and in ensuring support staff have expertise to do their job. For most platforms, deployment Just Works. The main gaps we have lie in certain vender applications (e.g. Exchange) and in commercial firewall product, but from the host and router platform view, the picture is good. We have no issues running DNS, MXs, web, etc dual-stack. We have occassional minor operational issues, but these cause very little extra supprot effort. By deploying dual-stack early, we believe our staff gain the expertise in IPv6 at an early stage. As an educational site, we expose our CS graduates to be to the technology. That is a benefit in our context. I would imagine the backbone NRENs that have deployed would say likewise, provided they deployed IPv6 incrementally through new procurements rather than going out and buying new line cards specifically to support IPv6 in hardware. You can find example deployment reports at www.6net.org. In terms of benefits, well, restoring global addressability is important, and in places where IPv4+NAT was used we can run IPv6 in parallel and use point to point conferencing and other applications that would have been very hard to do between two NATed sites. Dual stack with IPv4+NAT alongside IPv6 will be common, I believe. Another benefit is that, as an educational site, we see new innovation and interest in networking, I believe in part because catering for NATs is no longer an issue. A couple of student developed packages have attracted (some) commercial interest. I think Fred sums it up well when he says that had a business case been required for the web, it probably wouldn't have happened. -- Tim/::1 From owner-v6ops@ops.ietf.org Thu Nov 24 09:11:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfHpA-0001CG-UK for v6ops-archive@megatron.ietf.org; Thu, 24 Nov 2005 09:11:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04549 for ; Thu, 24 Nov 2005 09:11:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfHmw-000MPO-CC for v6ops-data@psg.com; Thu, 24 Nov 2005 14:09:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.212.29.137] (helo=mtagate4.uk.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EfHmt-000MPB-EQ for v6ops@ops.ietf.org; Thu, 24 Nov 2005 14:09:23 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id jAOE9IRj261128 for ; Thu, 24 Nov 2005 14:09:18 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAOE9IHv215656 for ; Thu, 24 Nov 2005 14:09:18 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id jAOE9HJk018714 for ; Thu, 24 Nov 2005 14:09:18 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id jAOE9H86018700; Thu, 24 Nov 2005 14:09:17 GMT Received: from zurich.ibm.com (sig-9-145-255-215.de.ibm.com [9.145.255.215]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA33626; Thu, 24 Nov 2005 15:09:16 +0100 Message-ID: <4385C987.6000700@zurich.ibm.com> Date: Thu, 24 Nov 2005 15:09:11 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Pekka Savola CC: Dwight Jamieson , v6ops@ops.ietf.org Subject: Re: v6ops:IPv4 vs. IPv6 operational costs References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit My assumption is that there will be a one-off operational cost of updating procedures and scripts, and re-training of staff, when a network switches to dual stack. But after that peak, IPv6 will just be part of normal operations and won't stand out as a separate cost at all. Of course, if you choose a complex co-existence strategy, interworking boxes will create operations costs of their own. Anybody who's operated protocol gateways of any kind knows this. That's why I've always been a strong advocate of straightforward dual stack solutions. A few years down the road, the simplicity due to having enough address space and no more NAT-related glitches and complexities should contain operations costs - but that really is intangible today. Brian Pekka Savola wrote: > On Wed, 23 Nov 2005, Dwight Jamieson wrote: > >> Looking a few years down the road, assuming that bulk of the bleeding is >> over, will operating that network be simpler, easier, cheaper than >> operating a network with private addressing today? > > > Once that point is reached, I'd suspect so. There's also an alternative > or a variation: keep using the existing v4 infrastructure (for simpler > applications), but introduce the new apps to (only) v6. > >> How painful is introducing new applications behind NAT/ALGs? What >> percentage of an IT department's budget spent on issues relating to >> private addressing? > > > That's a good question. I'd guess that getting non-trivial apps (e.g., > VoIP, video conferencing, etc.) to work across NATs is non-trivial > exercise. I'd guess that most cost is borne by those folks who write > and need to support those applications. That includes the enterprise if > the app is important enough to the enterprise. > From owner-v6ops@ops.ietf.org Thu Nov 24 10:27:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfJ0H-0007dg-0j for v6ops-archive@megatron.ietf.org; Thu, 24 Nov 2005 10:27:17 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16152 for ; Thu, 24 Nov 2005 10:26:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfIyc-0001qb-QV for v6ops-data@psg.com; Thu, 24 Nov 2005 15:25:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EfIyb-0001qQ-V2 for v6ops@ops.ietf.org; Thu, 24 Nov 2005 15:25:34 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jAOFPOD25072; Thu, 24 Nov 2005 10:25:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: v6ops:IPv4 vs. IPv6 operational costs Date: Thu, 24 Nov 2005 10:25:21 -0500 Message-ID: Thread-Topic: v6ops:IPv4 vs. IPv6 operational costs Thread-Index: AcXw20tWz2xt9Fa+S22KvcIhcLBhuwAKJeug From: "Dwight Jamieson" To: "Tim Chown" , Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Let me refine the original question. Let's suppose that there is an enterprise using private IPv4 addressing with NAT/ALG/FW. This enterprise is a service consumer. It doesn't offer any public service other than a web site describing the organization. It currently uses a few services that it has managed to get working across the NAT/ALG. The organization has turned on sparse IPv6 capabilities. The strategy for initial IPv6 use is to turn on dual stack in the hosts with intra-site IPv6/IPv4 tunneling to a dual stack exit point.=20 1. The enterprise wants to use a new corporate wide service that is deployed in many sites. The service works over the public Internet or corporate network (VPN). The service is a centrally controlled P2P type service. The service has been developed to work on both IPv4/NAT/ALG(proxy) and IPv6 using global addresses.=20 - will the IPv6 solution be easier/faster/cheaper to deploy? - will the IPv6 solution be easier/cheaper to maintain and operate? - will the IPv6 service typically offer enhance features (allowing content anywhere)? - will it be typical for services to be developed for both IPv6 and IPv4/ALG or IPv6 first because it's easier or IPv6 only? - others? 2. One of the organization's existing corporate services is made available to work over IPv6 with global addressing and it's time for a software upgrade for that service. What is the case for moving this service to dual stack or even single stack IPv6? - ?? From the replies to the original question, it seems that many applications will be easier/cheaper to deploy and operate using IPv6 global addresses, but it's not clear how heavy the cost factor will be in the decision making process. Dwight -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Tim Chown Sent: Thursday, November 24, 2005 4:24 AM To: v6ops@ops.ietf.org Subject: Re: v6ops:IPv4 vs. IPv6 operational costs On Wed, Nov 23, 2005 at 01:21:25PM -0800, Fred Baker wrote: > that would surprise me. My Mac is dual stacked now, and they tell me > that Windows Leghorn (Longhorn?) will be as well. Comes that way out =20 > of the box. >=20 > The question will be whether IT departments turn it on in the > network, not whether the hosts will use it if hey do. The question isn't only the 'cost', it's also about the benefit. You=20 also need to define 'cost' :) Our experience of deploying dual-stack as far as open source and vendor=20 provided solutions go on an enterprise of over 1,000 hosts is that the additional 'cost' is low. =20 We didn't buy new hardware specifically for IPv6. We used to run a parallel IPv6 routing infrastructure on BSD, but went 'properly' dual stacked when we reprocured our old IPv4 equipment this summer. No extra cost per se. The MRs on the procurement meant the new kit=20 supported IPv6 features (unicast amd multicast). The costs lie more in managing the additional protocol, and in ensuring support staff have=20 expertise to do their job. For most platforms, deployment Just Works. The main gaps we have lie=20 in certain vender applications (e.g. Exchange) and in commercial firewall=20 product, but from the host and router platform view, the picture is good. We have no issues running DNS, MXs, web, etc dual-stack. We have occassional minor operational issues, but these cause very=20 little extra supprot effort. By deploying dual-stack early, we believe our staff gain the expertise in IPv6 at an early stage. As an educational site, we expose our CS graduates to be to the technology. That is a benefit in our context. I would imagine the backbone NRENs that have deployed would say likewise, provided they deployed IPv6 incrementally through new procurements=20 rather than going out and buying new line cards specifically to support IPv6 in hardware. =20 You can find example deployment reports at www.6net.org. In terms of benefits, well, restoring global addressability is important, and in places where IPv4+NAT was used we can run IPv6 in parallel and use point to point conferencing and other applications that would have=20 been very hard to do between two NATed sites. Dual stack with IPv4+NAT alongside IPv6 will be common, I believe. Another benefit is that, as an educational site, we see new innovation and=20 interest in networking, I believe in part because catering for NATs is no=20 longer an issue. A couple of student developed packages have attracted (some) commercial interest. I think Fred sums it up well when he says that had a business case been required for the web, it probably wouldn't have happened. --=20 Tim/::1 From owner-v6ops@ops.ietf.org Thu Nov 24 10:57:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfJTK-0001uG-FH for v6ops-archive@megatron.ietf.org; Thu, 24 Nov 2005 10:57:18 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19705 for ; Thu, 24 Nov 2005 10:56:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfJSg-0004Vm-CF for v6ops-data@psg.com; Thu, 24 Nov 2005 15:56:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, SOME_BREAKTHROUGH autolearn=no version=3.1.0 Received: from [194.138.37.40] (helo=gecko.sbs.de) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EfJSf-0004VY-Ag for v6ops@ops.ietf.org; Thu, 24 Nov 2005 15:56:37 +0000 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id jAOFuNH7024022; Thu, 24 Nov 2005 16:56:23 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id jAOFuN3Y016164; Thu, 24 Nov 2005 16:56:23 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.146]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Nov 2005 16:56:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: v6ops:IPv4 vs. IPv6 operational costs Date: Thu, 24 Nov 2005 16:56:20 +0100 Message-ID: Thread-Topic: v6ops:IPv4 vs. IPv6 operational costs Thread-Index: AcXw20tWz2xt9Fa+S22KvcIhcLBhuwAKJeugAAKRDAA= From: "Sofia, Rute" To: "Dwight Jamieson" , "Tim Chown" , X-OriginalArrivalTime: 24 Nov 2005 15:56:23.0499 (UTC) FILETIME=[9E71D1B0:01C5F10F] Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Dwight, > controlled P2P type > service. The service has been developed to work on both > IPv4/NAT/ALG(proxy) and IPv6 using global addresses.=20 > - will the IPv6 solution be easier/faster/cheaper to deploy? > - will the IPv6 solution be easier/cheaper to maintain and operate? > - will the IPv6 service typically offer enhance features (allowing > content anywhere)? > - will it be typical for services to be developed for both IPv6 and > IPv4/ALG or IPv6 first because it's easier or IPv6 only? > - others? I am afraid that *we all* would like to have *quantitative* answers = concerning such numbers. :) However, that is impossible to get. As Tim = mentioned and related to (6NET) - NRENs expertise - you have plenty of = info stating how to do things and the possible gaps. >=20 > From the replies to the original question, it seems that many > applications will be easier/cheaper to deploy and operate using IPv6 > global addresses, but it's not clear how heavy the cost factor will be > in the decision making process. >=20 There is no magic answer to the questions above. IP is IP so don't = expect any major breakthrough. Having global connectivity is something = that at least today can only be achieved (from a wide perspective) by = means of IPv6. Or, one keeps adding hacks to deal with NAT. The cost factor will for sure have some impact in the situation. But = possibly what is really preventing a migration to IPv6 is 1) lack of = generalized knowledge about current features and how mature is IPv6 when = compared to IPv4 and 2) where is the business case for it. The answer to 1) is provided by deployments in GEANT, Abilene or = CERNET2, the research backbones. It shows that IPv6 is at least mature. = And it is also provided by Japan IPv6 infrastructures and (starting to = emerge) commercial services. The answer to 2) is harder to get. Mainly because IPv6 is not a = disruptive technology. Possible operational savings will only be seen in = the long-run. Not by trying to compare IPv6 vs. IPv4 private = addressing+NAT... Regards, Rute > Dwight >=20 >=20 >=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Tim Chown > Sent: Thursday, November 24, 2005 4:24 AM > To: v6ops@ops.ietf.org > Subject: Re: v6ops:IPv4 vs. IPv6 operational costs >=20 >=20 > On Wed, Nov 23, 2005 at 01:21:25PM -0800, Fred Baker wrote: > > that would surprise me. My Mac is dual stacked now, and they tell me > > that Windows Leghorn (Longhorn?) will be as well. Comes=20 > that way out =20 > > of the box. > >=20 > > The question will be whether IT departments turn it on in the > > network, not whether the hosts will use it if hey do. >=20 > The question isn't only the 'cost', it's also about the benefit. You=20 > also need to define 'cost' :) >=20 > Our experience of deploying dual-stack as far as open source=20 > and vendor=20 > provided solutions go on an enterprise of over 1,000 hosts is that the > additional 'cost' is low. =20 >=20 > We didn't buy new hardware specifically for IPv6. We used to run a > parallel IPv6 routing infrastructure on BSD, but went 'properly' dual > stacked when we reprocured our old IPv4 equipment this summer. No > extra cost per se. The MRs on the procurement meant the new kit=20 > supported IPv6 features (unicast amd multicast). The costs=20 > lie more in >=20 > managing the additional protocol, and in ensuring support staff have=20 > expertise to do their job. >=20 > For most platforms, deployment Just Works. The main gaps we=20 > have lie=20 > in certain vender applications (e.g. Exchange) and in commercial > firewall=20 > product, but from the host and router platform view, the picture is > good. We have no issues running DNS, MXs, web, etc dual-stack. >=20 > We have occassional minor operational issues, but these cause very=20 > little extra supprot effort. >=20 > By deploying dual-stack early, we believe our staff gain the expertise > in IPv6 at an early stage. As an educational site, we expose our CS > graduates > to be to the technology. That is a benefit in our context. >=20 > I would imagine the backbone NRENs that have deployed would say > likewise, provided they deployed IPv6 incrementally through new > procurements=20 > rather than going out and buying new line cards specifically=20 > to support > IPv6 in hardware. =20 >=20 > You can find example deployment reports at www.6net.org. >=20 > In terms of benefits, well, restoring global addressability is > important, and in places where IPv4+NAT was used we can run IPv6 in > parallel and use point to point conferencing and other=20 > applications that > would have=20 > been very hard to do between two NATed sites. Dual stack=20 > with IPv4+NAT >=20 > alongside IPv6 will be common, I believe. >=20 > Another benefit is that, as an educational site, we see new innovation > and=20 > interest in networking, I believe in part because catering for NATs is > no=20 > longer an issue. A couple of student developed packages=20 > have attracted >=20 > (some) commercial interest. >=20 > I think Fred sums it up well when he says that had a business=20 > case been > required for the web, it probably wouldn't have happened. >=20 > --=20 > Tim/::1 >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Fri Nov 25 03:10:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfYek-0006eR-Cz for v6ops-archive@megatron.ietf.org; Fri, 25 Nov 2005 03:10:06 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24100 for ; Fri, 25 Nov 2005 03:09:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfYap-0005SC-H2 for v6ops-data@psg.com; Fri, 25 Nov 2005 08:06:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.212.29.136] (helo=mtagate3.uk.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EfYam-0005RB-P9 for v6ops@ops.ietf.org; Fri, 25 Nov 2005 08:06:01 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id jAP86Tbf254974 for ; Fri, 25 Nov 2005 08:06:29 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAP85ua1231790 for ; Fri, 25 Nov 2005 08:05:56 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id jAP85tB1016223 for ; Fri, 25 Nov 2005 08:05:56 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id jAP85tOl016217; Fri, 25 Nov 2005 08:05:55 GMT Received: from zurich.ibm.com (sig-9-146-217-123.de.ibm.com [9.146.217.123]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA30082; Fri, 25 Nov 2005 09:05:52 +0100 Message-ID: <4386C5DD.6010409@zurich.ibm.com> Date: Fri, 25 Nov 2005 09:05:49 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Dwight Jamieson CC: v6ops@ops.ietf.org Subject: Re: v6ops:IPv4 vs. IPv6 operational costs References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > ... The service has been developed to work on both > IPv4/NAT/ALG(proxy) i.e. complicated and prone to glitches > ... and IPv6 using global addresses. i.e. simple and straightforward Once you've got over the learning curve, that difference should answer your questions, > - will it be typical for services to be developed for both IPv6 and > IPv4/ALG or IPv6 first because it's easier or IPv6 only? That will change over time. Today, anybody looking for real customers has to do both. ... > 2. One of the organization's existing corporate services is made > available to work over IPv6 with global addressing and it's time for a > software upgrade for that service. What is the case for moving this > service to dual stack or even single stack IPv6? If the service is well designed, it won't care and will decide for itself according to what network-layer services it finds. But I wouldn't expect any current enterprise to *drop* IPv4 service for many years; I expect to see creeping penetration of dual stack service. In ten years, you may notice that there's no IPv4 traffic any more, at which point you can switch it off. Brian From owner-v6ops@ops.ietf.org Mon Nov 28 10:38:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egl4w-000133-Qe for v6ops-archive@megatron.ietf.org; Mon, 28 Nov 2005 10:38:07 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20814 for ; Mon, 28 Nov 2005 10:37:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Egl1o-000MsH-4p for v6ops-data@psg.com; Mon, 28 Nov 2005 15:34:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Egl1n-000Mrt-Gp for v6ops@ops.ietf.org; Mon, 28 Nov 2005 15:34:51 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jASFYll20626 for ; Mon, 28 Nov 2005 10:34:47 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F431.3A7D5955" Subject: V6ops: Service Provider IPv6 Deployments Date: Mon, 28 Nov 2005 10:34:31 -0500 Message-ID: Thread-Topic: V6ops: Service Provider IPv6 Deployments Thread-Index: AcX0MToWJt1tn+ojShm3s7kEo61kiw== From: "Dwight Jamieson" To: Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F431.3A7D5955 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are there sources available that track the trends within the more active Service Providers about how many /48 addresses they are allocating? How many tunnels are they supporting? I have seen how many aggregated addresses are advertised in the core and how that is increasing. It would be interesting to see what is happening closer to the edge. Cheers, Dwight ------_=_NextPart_001_01C5F431.3A7D5955 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable V6ops: Service Provider IPv6 Deployments

Are there sources available that track = the trends within the more active Service Providers about how many /48 = addresses they are allocating? How many tunnels are they = supporting?

I have seen how many aggregated = addresses are advertised in the core and how that is increasing. It = would be interesting to see what is happening closer to the = edge.

Cheers,
Dwight

------_=_NextPart_001_01C5F431.3A7D5955-- From owner-v6ops@ops.ietf.org Mon Nov 28 11:49:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgmBw-00022E-Cq for v6ops-archive@megatron.ietf.org; Mon, 28 Nov 2005 11:49:24 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29609 for ; Mon, 28 Nov 2005 11:48:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Egm9s-0003t2-8Y for v6ops-data@psg.com; Mon, 28 Nov 2005 16:47:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [213.136.24.43] (helo=purgatory.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Egm9q-0003sk-Tp for v6ops@ops.ietf.org; Mon, 28 Nov 2005 16:47:15 +0000 Received: from [IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42] (hell.unfix.org [IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 40C7B7FE8; Mon, 28 Nov 2005 17:47:08 +0100 (CET) Message-ID: <438B3473.4060903@unfix.org> Date: Mon, 28 Nov 2005 17:46:43 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Dwight Jamieson CC: v6ops@ops.ietf.org Subject: Re: V6ops: Service Provider IPv6 Deployments References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 OpenPGP: id=333E7C23; url=http://unfix.org/~jeroen/jeroen-unfix.org-pgpkey Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig736EE86791D1C40372511BB9" Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig736EE86791D1C40372511BB9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dwight Jamieson wrote: >=20 > Are there sources available that track the trends within the more activ= e > Service Providers about how many /48 addresses they are allocating? How= > many tunnels are they supporting? XS26 claim to have 10500 tunnels with 9947 subnets. (From http://www.xs26.net/stat.bat) A list of tunnel brokers around the world can be found at http://www.sixxs.net/tools/aiccu/brokers/ but most don't have any public statistics available. SixXS, being one of the larger public tunnel providers, currently have almost 4700 _active_ tunnels. Number of tunnels (/64's) /subnets (/48's) toward end users/sites: http://www.sixxs.net/misc/growth/ Traffic Stats: http://www.sixxs.net/misc/traffic/ Where the users come from: http://www.sixxs.net/misc/usage/ A lot more stats can be found under http://www.sixxs.net/misc/ eg DFP's that are getting announced: http://www.sixxs.net/tools/grh/dfp/ according to which 52.58% (590 prefixes) are being announced of the blocks that are allocated from the various RIR's. Greets, Jeroen --------------enig736EE86791D1C40372511BB9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQFDizR3KaooUjM+fCMRAoxjAJkB/16vWKpFl8Cd6kQFVdGGl5zQAwCfV9KJ x2r/BJ2gtGvqQ0p7kYtFN9M= =iNIT -----END PGP SIGNATURE----- --------------enig736EE86791D1C40372511BB9-- From owner-v6ops@ops.ietf.org Tue Nov 29 00:12:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egxn5-0000ZL-Q2 for v6ops-archive@megatron.ietf.org; Tue, 29 Nov 2005 00:12:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12031 for ; Tue, 29 Nov 2005 00:11:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgxkC-00089I-MI for v6ops-data@psg.com; Tue, 29 Nov 2005 05:09:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [63.197.255.154] (helo=sinett.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgxkB-00088q-CO for v6ops@ops.ietf.org; Tue, 29 Nov 2005 05:09:31 +0000 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: Tiny fragments and IPv6 Date: Mon, 28 Nov 2005 21:14:01 -0800 Message-ID: Thread-Topic: Tiny fragments and IPv6 Thread-Index: AcX0IoMwld8Me2BDSsazG4LoZ25oUwAe2m7g From: "Vishwas Manral" To: Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi folks, To summarize the discussion we had on/off the ipv6 list, I have put in a short draft. The chairs of the groups (ipv6 and v6ops) wanted the discussion to move to the v6ops list; hence I am forwarding the discussion here. Do let me know if you have any comments or suggestions on the same? Thanks, Vishwas =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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D Routing Working Group V. Manral Internet-Draft SiNett Corp Expires: May 29, 2006 =20 =20 Operational issues with Tiny Fragments in IPv6 draft-manral-v6ops-tiny-fragments-issues-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 January 2, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract IPv6 fragmentation allows fragments to be sent only by the source of a=20 packet. The Fragment header is used by an IPv6 source to send a=20 packet larger than would fit in the path MTU to its destination.=20 Firewalls generally use 5-tuples to filter out packets. However there are cases where fragmentation can be used to disguise TCP packets=20 from IP filters used in routers and hosts. This document specifies where=20 tiny fragments can be issues. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1. Problem Statement With many IP implementations it is possible to impose a fragment small=20 enough to force some of a packet's Upper Layer e.g. TCP header fields into the second fragment.=20 This can cause all middlebox's like firewall and NAT-PT which expect the fields header information in the first fragment to not work properly. =20 Though the NAT Behave draft, states that NAT box should reassemble the packets, a lot of new issues can result. Keeping state could result=20 in easy DoS attacks. Besides the jury is still out about how many NAT boxes do reassembly. All policy based devices where packets are forwarded or sent on a tunnel based on some policy are also affected. 2. Issues with Firewalls There are different types of firewalls and state can be created in these firewalls through different methods. Independent of the adopted method, firewalls typically look at five parameters of the traffic arriving at the firewalls: o Source IP address o Destination IP address o Protocol type o Source port number o Destination port number Based on these parameters, firewalls usually decide whether to allow the traffic or to drop the packets. =20 However in cases where the first fragment does not have the upper layer=20 header information, the firewall is not able to get the port information and other upper layer information, thus allowing the packets to be sent to the protected side. =20 This can lead to attacks to the network and the firewall not being able=20 to block such an attack. =20 3. Issues with NAT-PT NAT-PT [RFC2766] assumes that for NAPT-PT operation the ports are visible to the translator. However if the Upper Layer Header is not=20 there in the first fragment. This causes the visibility ot the port to be lost. This can cause the translation process to fail. When the translator gets a tiny IPv6 fragment which has to be translated=20 to an IPv4 packet. The translator will have to reassemble the packets as=20 the IPv4 non last fragment needs to have a datagram size of 68 octets=20 atleast. =20 STD 5, RFC 791 states: Every internet module must be able to forward a datagram of 68 octets without further fragmentation. This is because an internet header may be up to 60 octets, and the minimum fragment is 8 octets. 4. Issues with Policy Boxes=20 Tiny Fragments could cause issues to Policy boxes which look further inside the packet, to make decisions. For IPsec Security Policy Database (SPD) specifies what services are to be offered to IP datagrams and in what fashion. The draft [RFC2401bis] states: "Non-initial" vs "Initial" Fragments Throughout this document, the phrase "non-initial" fragments is used to mean fragments that do not contain all of the selector values that may be needed for access control And the phrase "initial" fragment is used to mean a fragment that=20 contains all the selector values needed for access control. However, it should be noted that for IPv6, which fragment contains the Next Layer Protocol and ports (or ICMP message type/code or Mobility Header type) will depend on the kind and number of extension headers present. Having tiny fragments could mean that none of the fragments would be the Initial Fragment. So any access control/ tunneling based on that=20 may not work unless reassembly is done, or extra state like next Header and previous header length remaining are kept across fragments. =20 5. Proposed solutions to the problem a. Impose a minimum packet size for the non-last fragment. =20 b. Reassemble the packet, translate the header fields and, glean relevent information and then pass the original fragments ahead after modifying the relevent fields. =20 c. If upper layer protocol present then the header must be there in the first fragment. The above is just a first summary and the proposal are expected to be=20 changed as the draft matures. 6. Issues with fragment size of Minimum MTU The minimum fragment size of the non last fragment could be specified to be 1280 octets, the minimum link MTU [RFC2460].=20 However if the IPv6 packet has to be further tunnelled the packet may have to be fragmented. To prevent such a case a minimum packet size of=20 the non-last fragment should be less then 1280. 7. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 8. Security Considerations This draft outlines security issues arising if "Tiny Fragments" are sent. This draft raises no new security issues. 9. Acknowledgements =20 This draft borrows text heavily from draft-ietf-mip6-firewalls-03.txt=20 and RFC1858. Thanks to Brian Carpenter, Pekka Savola, Stig Venaas, Fred Baker, Pyda Srisuresh and Radhakrishnan.S for the helpful discussion. 10. References 10.1 Normative References [RFC2460] Deering & Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC2460, December 1998 [RFC2766] Tsirtsis & Srisuresh, "Network Address Translation - Protocol=20 Translation (NAT-PT)", RFC2766, February 2000 [RFC2401bis] Kent & Seo, "Security Architecture for the Internet=20 Protocol", Work in Progress, September, 2005 10.2 Informative References [RFC1858] Ziemba, Reed & Traina , "Security Considerations - IP=20 Fragment Filtering", RFC1858, October 1995 Authors' Addresses Vishwas Manral SiNett Corp Bangalore India Phone: +91-80-5137-7023 Fax: +91-80-5137-7001 Email: vishwas@sinett.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. From owner-v6ops@ops.ietf.org Tue Nov 29 06:44:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh3uP-0006K9-Rt for v6ops-archive@megatron.ietf.org; Tue, 29 Nov 2005 06:44:29 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22083 for ; Tue, 29 Nov 2005 06:43:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eh3ra-00053Y-TG for v6ops-data@psg.com; Tue, 29 Nov 2005 11:41:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_06_12 autolearn=no version=3.1.0 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eh3ra-00053M-DI for v6ops@ops.ietf.org; Tue, 29 Nov 2005 11:41:34 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 29 Nov 2005 03:41:34 -0800 X-IronPort-AV: i="3.97,388,1125903600"; d="scan'208"; a="679233045:sNHT28789520" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jATBfVOp003029; Tue, 29 Nov 2005 03:41:31 -0800 (PST) Received: from [10.0.0.107] (sjc-vpn2-355.cisco.com [10.21.113.99]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jATBnM8S008040; Tue, 29 Nov 2005 03:49:24 -0800 Mime-Version: 1.0 (Apple Message framework v746.2) References: <4AD3FB9C-660D-40DA-80D0-10CE10DB3F59@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4F6139F9-D1C3-46D2-96B5-F5E69FDF21F2@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Fwd: [voipeer] Is MOS for voice an endpoint feature? Date: Mon, 28 Nov 2005 23:38:52 -0500 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=352; t=1133264965; x=1133697165; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Fwd=3A=20[voipeer]=20Is=20MOS=20for=20voice=20an=20endpoint=20feature?| From:Fred=20Baker=20| Date:Mon,=2028=20Nov=202005=2023=3A38=3A52=20-0500| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=MR+pqJnw+wLzd3NSwMaBDj6nbR3MN0tTlYkSkzWcDUICkP6jWesYu9sg249g03vuXQNluukB QWdSn5YE7pSgVQ34SNkCvgodixn5gNt0lopaoDMyF5Pg0CMdrfYL3ZaLikOJwukvlySmUiCHHk8 flIgUyuHOaD4uolc8cVoEGXc= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Any ISPs or other networks that are represented on this list - I'd appreciate operational comment directed towards voipeer@lists.uoregon.edu (the 'voice peering' BOF). I think operational input is needed on what it means to peer and what it means for an ISP to deploy a voice service. List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html From owner-v6ops@ops.ietf.org Tue Nov 29 08:25:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh5U4-00021H-3k for v6ops-archive@megatron.ietf.org; Tue, 29 Nov 2005 08:25:24 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02657 for ; Tue, 29 Nov 2005 08:24:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eh5Rz-0009mr-LV for v6ops-data@psg.com; Tue, 29 Nov 2005 13:23:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eh5Ry-0009mc-9T for v6ops@ops.ietf.org; Tue, 29 Nov 2005 13:23:14 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 29 Nov 2005 05:23:15 -0800 X-IronPort-AV: i="3.97,388,1125903600"; d="scan'208"; a="679254131:sNHT31936148" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jATDNDCJ023770; Tue, 29 Nov 2005 05:23:13 -0800 (PST) Received: from [10.0.0.107] (sjc-vpn2-355.cisco.com [10.21.113.99]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jATDV6mt008940; Tue, 29 Nov 2005 05:31:06 -0800 Mime-Version: 1.0 (Apple Message framework v746.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Vishwas Manral Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Fwd: Tiny fragments and IPv6 Date: Tue, 29 Nov 2005 08:23:12 -0500 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=7454; t=1133271067; x=1133703267; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Fwd=3A=20Tiny=20fragments=20and=20IPv6| From:Fred=20Baker=20| Date:Tue,=2029=20Nov=202005=2008=3A23=3A12=20-0500| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=Ng6JMSeZGQk4Dttoe8OaqOAKtXf3LGNe5sqzlatH2A9SBizfZY8HjuZLUPlzXyTNDNvH5n6M IahjwlkH0VFU1E35sjCo7K92bElxPCbMq8cgCWfpzstxUuXRh6PKhr/Jw1WqM3CbQtYCzBcbn/L dDZqGn0xKRweZ/DrDitWN0gs= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( 74 extraneous bytes; message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This has been moved to v6ops, as it is more operational in nature than a protocol discussion. Begin forwarded message: > From: "Vishwas Manral" > Date: November 28, 2005 8:49:11 AM EST > To: "IPv6" > Subject: Tiny fragments and IPv6 > > Hi folks, > > To summarize the discussion we have had on and off the list, I have > put > in a short draft. > > Do let me know if you have any comments or suggestions for the same? > > Thanks, > Vishwas > ====================================================================== > == > == > > Routing Working Group V. > Manral > Internet-Draft SiNett > Corp > Expires: May 28, 2006 > > > > > > > > Issues with Tiny Fragments in IPv6 > draft-manral-ipv6-tiny-fragments-issues-00 > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > 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 January 2, 2006. > > Copyright Notice > > Copyright (C) The Internet Society (2005). > > Abstract > > IPv6 fragmentation allows fragments to be sent only by the > source of > a > packet. The Fragment header is used by an IPv6 source to send a > packet larger than would fit in the path MTU to its destination. > > Firewalls generally use 5-tuples to filter out packets. However > there > are cases where fragmentation can be used to disguise TCP packets > from IP filters used in routers and hosts. This document specifies > where > tiny fragments can be issues. > > Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > > > > 1. Problem Statement > > With many IP implementations it is possible to impose a fragment > small > enough to force some of a packet's Upper Layer e.g. TCP header > fields > into the second fragment. > > This can cause application like firewall and NAT-PT which expect the > fields > header information in the first fragment to not work properly. > > 2. Issues with Firewalls > > There are different types of firewalls and state can be created in > these firewalls through different methods. Independent of the > adopted method, firewalls typically look at five parameters of the > traffic arriving at the firewalls: > > o Source IP address > > o Destination IP address > > o Protocol type > > o Source port number > > o Destination port number > > Based on these parameters, firewalls usually decide whether to > allow > the traffic or to drop the packets. > > However in cases where the first fragment does not have the upper > layer > header information, the firewall is not able to get the port > information and > other upper layer information, thus allowing the packets to be > sent to > the > protected side. > > This can lead to attacks to the network and the firewall not being > able to > block such an attack. > > > 3. Issues with NAT-PT > > NAT-PT [RFC2766] assumes that for NAPT-PT operation the ports are > visible to > the translator. However if the Upper Layer Header is not there > in the > first > fragment. This causes the visibility ot the port to be lost. > This can > cause the > translation process to fail. > > When the translator gets a tiny IPv6 fragment which has to be > translated to an > IPv4 packet. The translator will have to reassemble the packets > as the > IPv4 non > last fragment needs to have a datagram size of 68 octets atleast. > > STD 5, RFC 791 states: > > Every internet module must be able to forward a datagram of 68 > octets without further fragmentation. This is because an > internet > header may be up to 60 octets, and the minimum fragment is 8 > octets. > > > 4. Proposed solutions to the problem > > a. Impose a minimum packet size for the non-last fragment. > > b. Reassemble the packet, translate the header fields and, glean > relevent > information and then pass the original fragments ahead after > modifying the > relevent fields. > > c. If upper layer protocol present then the header must be there in > the first > fragment. > > The above is just a first summary and the proposal are expected > to be > changed > as the draft matures. > > > 5. Issues with fragment size of Minimum MTU > > The minimum fragment size of the non last fragment is set to 1280 > octets, the > minimum link MTU to be supported [RFC2460] could be specified. > However > if the IPv6 packet has to be further tunnelled the packet may > have to > be > fragmented. To prevent such a case a minimum packet size of the > non-last > fragment should be less then 1280. > > > 6. IANA Considerations > > This document makes no request of IANA. > > Note to RFC Editor: this section may be removed on publication > as an > RFC. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 7. Security Considerations > > This draft outlines security issues arising if Tiny fragments are > sent. > This draft raises no new security issues. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 7. Acknowledgements > > This draft borrows text heavily from > draft-ietf-mip6-firewalls-03.txt and RFC1858. > Thanks to Brian Carpenter, Pekka Savola, Stig Venaas, Fred > Baker and > > Radhakrishnan.S for the helpful discussion. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 9. References > > 9.1 Normative References > > [RFC2460] Deering & Hinden, "Internet Protocol, Version 6 (IPv6) > Specification", > RFC2460, December 1998 > > [RFC2766] Tsirtsis & Srisuresh, "Network Address Translation - > Protocol > Translation (NAT-PT)", RFC2766, February 2000 > > > 9.2 Informative References > > [RFC1858] Ziemba, Reed & Traina , "Security Considerations - IP > Fragment Filtering", RFC1858, October 1995 > > > > > > > > > > > > Authors' Addresses > > Vishwas Manral > SiNett Corp > Bangalore > India > > Phone: +91-80-5137-7023 > Fax: +91-80-5137-7001 > Email: vishwas@sinett.com > > > > > > > > > > > > > > > Intellectual Property Statement > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights 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; nor does it represent that it has > made any independent effort to identify any such rights. > Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this > specification can be obtained from the IETF on-line IPR > repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > > Disclaimer of Validity > > This document and the information contained herein are provided > on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Copyright Statement > > Copyright (C) The Internet Society (2005). This document is > subject > to the rights, licenses and restrictions contained in BCP 78, and > except as set forth therein, the authors retain all their rights. > > > Acknowledgment > > Funding for the RFC Editor function is currently provided by the > Internet Society. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From owner-v6ops@ops.ietf.org Tue Nov 29 13:16:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhA1f-0007Mk-3L for v6ops-archive@megatron.ietf.org; Tue, 29 Nov 2005 13:16:23 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14607 for ; Tue, 29 Nov 2005 13:15:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eh9yh-0000w5-4o for v6ops-data@psg.com; Tue, 29 Nov 2005 18:13:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.9.221.21] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eh9yf-0000vm-GG for v6ops@ops.ietf.org; Tue, 29 Nov 2005 18:13:17 +0000 Received: from [66.93.138.196] (account margaret HELO ceili) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 607975; Tue, 29 Nov 2005 13:13:14 -0500 From: "Margaret Wasserman" To: "'Fred Baker'" , Cc: "'Vishwas Manral'" Subject: RE: Tiny fragments and IPv6 Date: Tue, 29 Nov 2005 13:13:12 -0500 Message-ID: <002301c5f510$94158f90$5b03a8c0@instant802.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcX06rJAA+YWB7G5S8aVhLVMJrYP2wABgFoA Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Why is this an IPv6-specific problem? Is there a reason why the same type of attack does not work in IPv4? Margaret > -----Original Message----- > From: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker > Sent: Tuesday, November 29, 2005 8:23 AM > To: v6ops@ops.ietf.org > Cc: Vishwas Manral > Subject: Fwd: Tiny fragments and IPv6 > > This has been moved to v6ops, as it is more operational in > nature than a protocol discussion. > > Begin forwarded message: > > > From: "Vishwas Manral" > > Date: November 28, 2005 8:49:11 AM EST > > To: "IPv6" > > Subject: Tiny fragments and IPv6 > > > > Hi folks, > > > > To summarize the discussion we have had on and off the list, I have > > put in a short draft. > > > > Do let me know if you have any comments or suggestions for the same? > > > > Thanks, > > Vishwas > > > ====================================================================== > > == > > == > > > > Routing Working Group V. > > Manral > > Internet-Draft > SiNett > > Corp > > Expires: May 28, 2006 > > > > > > > > > > > > > > > > Issues with Tiny Fragments in IPv6 > > draft-manral-ipv6-tiny-fragments-issues-00 > > > > Status of this Memo > > > > By submitting this Internet-Draft, each author > represents that any > > applicable patent or other IPR claims of which he or she is aware > > have been or will be disclosed, and any of which he or > she becomes > > aware will be disclosed, in accordance with Section 6 of BCP 79. > > > > 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 January 2, 2006. > > > > Copyright Notice > > > > Copyright (C) The Internet Society (2005). > > > > Abstract > > > > IPv6 fragmentation allows fragments to be sent only by > the source > > of a > > packet. The Fragment header is used by an IPv6 source to send a > > packet larger than would fit in the path MTU to its destination. > > > > Firewalls generally use 5-tuples to filter out packets. However > > there > > are cases where fragmentation can be used to disguise > TCP packets > > from IP filters used in routers and hosts. This document > specifies > > where > > tiny fragments can be issues. > > > > Requirements Language > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", > "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > > this > > document are to be interpreted as described in RFC 2119 > [RFC2119]. > > > > > > > > > > 1. Problem Statement > > > > With many IP implementations it is possible to impose a fragment > > small > > enough to force some of a packet's Upper Layer e.g. TCP header > > fields > > into the second fragment. > > > > This can cause application like firewall and NAT-PT which > expect the > > fields > > header information in the first fragment to not work properly. > > > > 2. Issues with Firewalls > > > > There are different types of firewalls and state can be > created in > > these firewalls through different methods. Independent of the > > adopted method, firewalls typically look at five > parameters of the > > traffic arriving at the firewalls: > > > > o Source IP address > > > > o Destination IP address > > > > o Protocol type > > > > o Source port number > > > > o Destination port number > > > > Based on these parameters, firewalls usually decide whether to > > allow > > the traffic or to drop the packets. > > > > However in cases where the first fragment does not have the upper > > layer > > header information, the firewall is not able to get the port > > information and > > other upper layer information, thus allowing the packets > to be sent > > to the > > protected side. > > > > This can lead to attacks to the network and the firewall > not being > > able to > > block such an attack. > > > > > > 3. Issues with NAT-PT > > > > NAT-PT [RFC2766] assumes that for NAPT-PT operation the > ports are > > visible to > > the translator. However if the Upper Layer Header is not > there in > > the first > > fragment. This causes the visibility ot the port to be lost. > > This can > > cause the > > translation process to fail. > > > > When the translator gets a tiny IPv6 fragment which has to be > > translated to an > > IPv4 packet. The translator will have to reassemble the > packets as > > the > > IPv4 non > > last fragment needs to have a datagram size of 68 octets atleast. > > > > STD 5, RFC 791 states: > > > > Every internet module must be able to forward a datagram of 68 > > octets without further fragmentation. This is because an > > internet > > header may be up to 60 octets, and the minimum fragment is 8 > > octets. > > > > > > 4. Proposed solutions to the problem > > > > a. Impose a minimum packet size for the non-last fragment. > > > > b. Reassemble the packet, translate the header fields and, glean > > relevent > > information and then pass the original fragments ahead after > > modifying the > > relevent fields. > > > > c. If upper layer protocol present then the header must > be there in > > the first > > fragment. > > > > The above is just a first summary and the proposal are > expected to > > be changed > > as the draft matures. > > > > > > 5. Issues with fragment size of Minimum MTU > > > > The minimum fragment size of the non last fragment is > set to 1280 > > octets, the > > minimum link MTU to be supported [RFC2460] could be specified. > > However > > if the IPv6 packet has to be further tunnelled the > packet may have > > to be > > fragmented. To prevent such a case a minimum packet size of the > > non-last > > fragment should be less then 1280. > > > > > > 6. IANA Considerations > > > > This document makes no request of IANA. > > > > Note to RFC Editor: this section may be removed on > publication as > > an > > RFC. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 7. Security Considerations > > > > This draft outlines security issues arising if Tiny > fragments are > > sent. > > This draft raises no new security issues. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 7. Acknowledgements > > > > This draft borrows text heavily from > > draft-ietf-mip6-firewalls-03.txt and RFC1858. > > Thanks to Brian Carpenter, Pekka Savola, Stig Venaas, > Fred Baker > > and > > > > Radhakrishnan.S for the helpful discussion. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 9. References > > > > 9.1 Normative References > > > > [RFC2460] Deering & Hinden, "Internet Protocol, Version 6 (IPv6) > > Specification", > > RFC2460, December 1998 > > > > [RFC2766] Tsirtsis & Srisuresh, "Network Address Translation - > > Protocol > > Translation (NAT-PT)", RFC2766, February 2000 > > > > > > 9.2 Informative References > > > > [RFC1858] Ziemba, Reed & Traina , "Security Considerations - IP > > Fragment Filtering", RFC1858, October 1995 > > > > > > > > > > > > > > > > > > > > > > > > Authors' Addresses > > > > Vishwas Manral > > SiNett Corp > > Bangalore > > India > > > > Phone: +91-80-5137-7023 > > Fax: +91-80-5137-7001 > > Email: vishwas@sinett.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Intellectual Property Statement > > > > The IETF takes no position regarding the validity or scope of any > > Intellectual Property Rights 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; nor does it represent > that it has > > made any independent effort to identify any such rights. > > Information > > on the procedures with respect to rights in RFC documents can be > > found in BCP 78 and BCP 79. > > > > Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this > > specification can be obtained from the IETF on-line IPR > repository > > at > > http://www.ietf.org/ipr. > > > > The IETF invites any interested party to bring to its > attention any > > copyrights, patents or patent applications, or other proprietary > > rights that may cover technology that may be required to > implement > > this standard. Please address the information to the IETF at > > ietf-ipr@ietf.org. > > > > > > Disclaimer of Validity > > > > This document and the information contained herein are > provided on > > an > > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > > REPRESENTS > > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND > THE INTERNET > > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS > OR IMPLIED, > > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A > PARTICULAR PURPOSE. > > > > > > Copyright Statement > > > > Copyright (C) The Internet Society (2005). This document is > > subject > > to the rights, licenses and restrictions contained in BCP 78, and > > except as set forth therein, the authors retain all their rights. > > > > > > Acknowledgment > > > > Funding for the RFC Editor function is currently provided by the > > Internet Society. > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > From owner-v6ops@ops.ietf.org Tue Nov 29 13:25:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhAAo-0004DB-DR for v6ops-archive@megatron.ietf.org; Tue, 29 Nov 2005 13:25:52 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15945 for ; Tue, 29 Nov 2005 13:25:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhAAC-0001ZL-R5 for v6ops-data@psg.com; Tue, 29 Nov 2005 18:25:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,HTML_40_50, HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [63.197.255.154] (helo=sinett.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EhAAC-0001Yy-2g for v6ops@ops.ietf.org; Tue, 29 Nov 2005 18:25:12 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F512.3BE3C5E4" Subject: RE: Tiny fragments and IPv6 Date: Tue, 29 Nov 2005 10:25:11 -0800 Message-ID: Thread-Topic: Tiny fragments and IPv6 Thread-Index: AcX06rJAA+YWB7G5S8aVhLVMJrYP2wABgFoAAAf+wf0= From: "Vishwas Manral" To: "Margaret Wasserman" , "Fred Baker" , Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F512.3BE3C5E4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Margaret, =20 One small difference is that we can have a lot of extension headers in = IPv6 while we do not have the same in IPv4. In IPv4 the TCP header if = present will be just after the IPv4 header, which may not be the case in = IPv6 (because of the extension headers). Besides STD 5, RFC 791 states:- Every internet module must be able to forward a datagram of 68 octets without further fragmentation. This is because an internet header may be up to 60 octets, and the minimum fragment is 8 octets. =20 There is no minimum non-last fragment size specified in IPv6. RFC1858 = already states issues with IPv4 with tiny fragments. =20 Thanks, Vishwas ________________________________ From: Margaret Wasserman [mailto:margaret@thingmagic.com] Sent: Tue 11/29/2005 10:13 AM To: 'Fred Baker'; v6ops@ops.ietf.org Cc: Vishwas Manral Subject: RE: Tiny fragments and IPv6 Why is this an IPv6-specific problem? Is there a reason why the same = type of attack does not work in IPv4? Margaret > -----Original Message----- > From: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker > Sent: Tuesday, November 29, 2005 8:23 AM > To: v6ops@ops.ietf.org > Cc: Vishwas Manral > Subject: Fwd: Tiny fragments and IPv6 > > This has been moved to v6ops, as it is more operational in > nature than a protocol discussion. > > Begin forwarded message: > > > From: "Vishwas Manral" > > Date: November 28, 2005 8:49:11 AM EST > > To: "IPv6" > > Subject: Tiny fragments and IPv6 > > > > Hi folks, > > > > To summarize the discussion we have had on and off the list, I have > > put in a short draft. > > > > Do let me know if you have any comments or suggestions for the same? > > > > Thanks, > > Vishwas > > =20 =20 ------_=_NextPart_001_01C5F512.3BE3C5E4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= RE: Tiny fragments and IPv6=0A= =0A= =0A=
=0A=
Hi = Margaret,
=0A=
 
=0A=
One small difference is that = we can have a =0A= lot of extension headers in IPv6 while we do not have the same in IPv4. = In IPv4 =0A= the TCP header if present will be just after the IPv4 header, which may = not be =0A= the case in IPv6 (because of the extension headers). Besides = STD 5, RFC 791 =0A= states:-

      Every internet module = must be =0A= able to forward a datagram of 68
      = octets =0A= without further fragmentation.  This is because an =0A= internet
      header may be up to 60 = octets, and =0A= the minimum fragment is 8
      =0A= octets.
=0A=
 
=0A=
There is no minimum = non-last fragment =0A= size specified in IPv6. RFC1858 already states issues with IPv4 with = tiny =0A= fragments.
=0A=
 
=0A=
Thanks,
=0A=
Vishwas
=0A=
=0A=
=0A=
=0A=
From: Margaret = Wasserman =0A= [mailto:margaret@thingmagic.com]
Sent: Tue 11/29/2005 10:13 =0A= AM
To: 'Fred Baker'; v6ops@ops.ietf.org
Cc: Vishwas =0A= Manral
Subject: RE: Tiny fragments and IPv6
=0A=
=0A=

Why is this an IPv6-specific problem?  Is there a = reason =0A= why the same type
of attack does not work in =0A= IPv4?

Margaret

> -----Original Message-----
> = From: =0A= owner-v6ops@ops.ietf.org
> [mailto:owner-v6ops@ops.ietf.org<= /A>] On =0A= Behalf Of Fred Baker
> Sent: Tuesday, November 29, 2005 8:23 = AM
> =0A= To: v6ops@ops.ietf.org
> Cc: Vishwas Manral
> Subject: Fwd: = Tiny =0A= fragments and IPv6
>
> This has been moved to v6ops, as it = is more =0A= operational in
> nature than a protocol = discussion.
>
> Begin =0A= forwarded message:
>
> > From: "Vishwas Manral" =0A= <Vishwas@sinett.com>
> > Date: November 28, 2005 8:49:11 = AM =0A= EST
> > To: "IPv6" <ipv6@ietf.org>
> > Subject: = Tiny =0A= fragments and IPv6
> >
> > Hi folks,
> = >
> > =0A= To summarize the discussion we have had on and off the list, I = have
> > =0A= put in a short draft.
> >
> > Do let me know if you = have any =0A= comments or suggestions for the same?
> >
> > = Thanks,
> =0A= > Vishwas
> >

=0A=

 

=0A=

 

=0A= =0A= =0A= ------_=_NextPart_001_01C5F512.3BE3C5E4-- From owner-v6ops@ops.ietf.org Tue Nov 29 13:34:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhAJC-0006Wu-11 for v6ops-archive@megatron.ietf.org; Tue, 29 Nov 2005 13:34:30 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16918 for ; Tue, 29 Nov 2005 13:33:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhAIc-0002Bx-5Z for v6ops-data@psg.com; Tue, 29 Nov 2005 18:33:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [158.38.60.10] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EhAIZ-0002Bb-8B for v6ops@ops.ietf.org; Tue, 29 Nov 2005 18:33:51 +0000 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id jATIXlW0015397; Tue, 29 Nov 2005 19:33:47 +0100 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id jATIXl5G002664; Tue, 29 Nov 2005 19:33:47 +0100 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id jATIXkvL002663; Tue, 29 Nov 2005 19:33:46 +0100 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 29 Nov 2005 19:33:46 +0100 From: Stig Venaas To: Vishwas Manral Cc: Margaret Wasserman , Fred Baker , v6ops@ops.ietf.org Subject: Re: Tiny fragments and IPv6 Message-ID: <20051129183346.GA2648@storhaugen.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: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Nov 29, 2005 at 10:25:11AM -0800, Vishwas Manral wrote: > Hi Margaret, > > One small difference is that we can have a lot of extension headers in IPv6 while we do not have the same in IPv4. In IPv4 the TCP header if present will be just after the IPv4 header, which may not be the case in IPv6 (because of the extension headers). Besides STD 5, RFC 791 states:- > > Every internet module must be able to forward a datagram of 68 > octets without further fragmentation. This is because an internet > header may be up to 60 octets, and the minimum fragment is 8 > octets. Well, this is because in some cases fragments cannot be made smaller if they are to contain a maximum size IP header. I don't think it prohibits smaller fragments. Isn't this sort of similar to the 1280 limit in IPv6? You shouldn't need to fragment IPv6 datagrams of 1280 or less... What I mainly would have like to see, both for IPv4 and IPv6, is some- thing saying that fragments MUST not be overlapped. When receiving such one could then just discard them... Stig > > There is no minimum non-last fragment size specified in IPv6. RFC1858 already states issues with IPv4 with tiny fragments. > > Thanks, > Vishwas > ________________________________ > > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Tue 11/29/2005 10:13 AM > To: 'Fred Baker'; v6ops@ops.ietf.org > Cc: Vishwas Manral > Subject: RE: Tiny fragments and IPv6 > > > Why is this an IPv6-specific problem? Is there a reason why the same type > of attack does not work in IPv4? > > Margaret > > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker > > Sent: Tuesday, November 29, 2005 8:23 AM > > To: v6ops@ops.ietf.org > > Cc: Vishwas Manral > > Subject: Fwd: Tiny fragments and IPv6 > > > > This has been moved to v6ops, as it is more operational in > > nature than a protocol discussion. > > > > Begin forwarded message: > > > > > From: "Vishwas Manral" > > > Date: November 28, 2005 8:49:11 AM EST > > > To: "IPv6" > > > Subject: Tiny fragments and IPv6 > > > > > > Hi folks, > > > > > > To summarize the discussion we have had on and off the list, I have > > > put in a short draft. > > > > > > Do let me know if you have any comments or suggestions for the same? > > > > > > Thanks, > > > Vishwas > > > > > > > > From owner-v6ops@ops.ietf.org Tue Nov 29 14:19:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhB0Y-0006kO-Iv for v6ops-archive@megatron.ietf.org; Tue, 29 Nov 2005 14:19:18 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22731 for ; Tue, 29 Nov 2005 14:18:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhAyy-0004s4-P2 for v6ops-data@psg.com; Tue, 29 Nov 2005 19:17:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EhAyx-0004rt-SC for v6ops@ops.ietf.org; Tue, 29 Nov 2005 19:17:40 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 29 Nov 2005 11:17:38 -0800 X-IronPort-AV: i="3.97,389,1125903600"; d="scan'208"; a="235369014:sNHT24792026" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jATJHZ6a000517; Tue, 29 Nov 2005 11:17:36 -0800 (PST) Received: from [10.0.2.19] (sjc-vpn4-419.cisco.com [10.21.81.163]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jATJPR9r012555; Tue, 29 Nov 2005 11:25:28 -0800 In-Reply-To: <002301c5f510$94158f90$5b03a8c0@instant802.com> References: <002301c5f510$94158f90$5b03a8c0@instant802.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <66C182A3-0F10-452F-9D84-95E7ACD551C4@cisco.com> Cc: , "'Vishwas Manral'" Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Tiny fragments and IPv6 Date: Tue, 29 Nov 2005 14:17:34 -0500 To: "Margaret Wasserman" X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=296; t=1133292328; x=1133724528; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20Tiny=20fragments=20and=20IPv6| From:Fred=20Baker=20| Date:Tue,=2029=20Nov=202005=2014=3A17=3A34=20-0500| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=X8vVu/GzlM/m/iWxx8k2msYGIAivWEjo2vSbJLpA2FCrs75mn4CIKr/p/Lx55v/aVyn32fWB MAI2oBiW99C7zcR6ep5ZuLVRayS8wGJcXSDMGIXG6sj5Pl52omO/WJqFie2wNpY3DVzjEgzVyiB Zqdhwtg17976TwYl2j2Q9uRc= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It does happen in IPv4. Vishwas' concern is that the attack that happens in IPv4 might happen in IPv6, and is wondering whether there are best practices that we can discuss to minimize the impact. On Nov 29, 2005, at 1:13 PM, Margaret Wasserman wrote: > Why is this an IPv6-specific problem? Is there a reason why the > same type > of attack does not work in IPv4? From owner-v6ops@ops.ietf.org Tue Nov 29 14:30:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhBBh-0005Ly-ED for v6ops-archive@megatron.ietf.org; Tue, 29 Nov 2005 14:30:49 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23925 for ; Tue, 29 Nov 2005 14:30:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhBB8-0005hR-1a for v6ops-data@psg.com; Tue, 29 Nov 2005 19:30:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [193.6.222.240] (helo=mail.ki.iif.hu) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EhBB7-0005hC-6L for v6ops@ops.ietf.org; Tue, 29 Nov 2005 19:30:13 +0000 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id 5ED0655BA; Tue, 29 Nov 2005 20:30:12 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 5C9F555B9; Tue, 29 Nov 2005 20:30:12 +0100 (CET) Date: Tue, 29 Nov 2005 20:30:12 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Dwight Jamieson Cc: v6ops@ops.ietf.org Subject: Re: V6ops: Service Provider IPv6 Deployments In-Reply-To: Message-ID: <20051129134912.S22599@mignon.ki.iif.hu> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 28 Nov 2005, Dwight Jamieson wrote: > > Are there sources available that track the trends within the more active > Service Providers about how many /48 addresses they are allocating? How > many tunnels are they supporting? For example NIIF/HUNGARNET allocated approximately 80 /48 and 5 tunnels. I think number of tunnels is bad metrics. Most of ISP is providing IPv6 natively nowadays..... > > I have seen how many aggregated addresses are advertised in the core and > how that is increasing. It would be interesting to see what is happening > closer to the edge. Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > Cheers, > Dwight > From owner-v6ops@ops.ietf.org Tue Nov 29 14:49:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhBTR-0005xq-Ui for v6ops-archive@megatron.ietf.org; Tue, 29 Nov 2005 14:49:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25959 for ; Tue, 29 Nov 2005 14:48:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhBSk-0006sQ-90 for v6ops-data@psg.com; Tue, 29 Nov 2005 19:48:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EhBSj-0006sE-Iw for v6ops@ops.ietf.org; Tue, 29 Nov 2005 19:48:25 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jATJmNU29070 for ; Tue, 29 Nov 2005 14:48:23 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F51D.C03D4FDB" Subject: V6ops: IPv6 site multihoming best practices Date: Tue, 29 Nov 2005 14:47:37 -0500 Message-ID: Thread-Topic: V6ops: IPv6 site multihoming best practices Thread-Index: AcX1Hb/nUKgEKnbYR/qbudOSYK88Mg== From: "Dwight Jamieson" To: Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F51D.C03D4FDB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the absence of mature protocol support for site multi-homing (shim6), what are the best practice recommendations for an enterprise or service provider? Cheers, Dwight ------_=_NextPart_001_01C5F51D.C03D4FDB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable V6ops: IPv6 site multihoming best practices

In the absence of mature protocol = support for site multi-homing (shim6), what are the best practice = recommendations for an enterprise or service provider?

Cheers,
Dwight

------_=_NextPart_001_01C5F51D.C03D4FDB-- From owner-v6ops@ops.ietf.org Tue Nov 29 15:02:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhBgV-0003e1-4s for v6ops-archive@megatron.ietf.org; Tue, 29 Nov 2005 15:02:39 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28115 for ; Tue, 29 Nov 2005 15:01:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhBfs-00081u-Ah for v6ops-data@psg.com; Tue, 29 Nov 2005 20:02:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [65.124.20.195] (helo=mx01.bos.ma.towardex.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EhBfr-00081i-DI for v6ops@ops.ietf.org; Tue, 29 Nov 2005 20:01:59 +0000 Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.5_DAKN, from userid 1143) id F2AD66D47A; Tue, 29 Nov 2005 15:01:58 -0500 (EST) Received: from hcmczombvvlcmo (unknown [216.93.252.30]) by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.5_DAKN) with ESMTP id EC3E16D44E; Tue, 29 Nov 2005 15:01:52 -0500 (EST) Reply-To: From: "James Jun" To: "'Dwight Jamieson'" , Subject: RE: V6ops: IPv6 site multihoming best practices Date: Tue, 29 Nov 2005 15:03:51 -0500 Organization: TowardEX Technologies, Inc. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0118_01C5F4F6.1BC0CEC0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Thread-Index: AcX1Hb/nUKgEKnbYR/qbudOSYK88MgAAfpyQ In-Reply-To: Message-Id: <20051129200152.EC3E16D44E@mx01.bos.ma.towardex.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0118_01C5F4F6.1BC0CEC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit _____ From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Dwight Jamieson Sent: Tuesday, November 29, 2005 2:48 PM To: v6ops@ops.ietf.org Subject: V6ops: IPv6 site multihoming best practices In the absence of mature protocol support for site multi-homing (shim6), what are the best practice recommendations for an enterprise or service provider? Cheers, Dwight ------=_NextPart_000_0118_01C5F4F6.1BC0CEC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable V6ops: IPv6 site multihoming best practices

From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Dwight Jamieson
Sent: Tuesday, November = 29, 2005 2:48 PM
To: = v6ops@ops.ietf.org
Subject: V6ops: IPv6 site multihoming best practices

 

 

In the absence of mature protocol support for site multi-homing (shim6), = what are the best practice recommendations for an enterprise or service = provider?

Cheers,
Dwight

 

------=_NextPart_000_0118_01C5F4F6.1BC0CEC0-- From owner-v6ops@ops.ietf.org Tue Nov 29 15:18:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhBvz-00043D-O6 for v6ops-archive@megatron.ietf.org; Tue, 29 Nov 2005 15:18:42 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00106 for ; Tue, 29 Nov 2005 15:17:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhBv0-00093c-HR for v6ops-data@psg.com; Tue, 29 Nov 2005 20:17:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [65.124.20.195] (helo=mx01.bos.ma.towardex.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EhBuz-00093P-FD for v6ops@ops.ietf.org; Tue, 29 Nov 2005 20:17:37 +0000 Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.5_DAKN, from userid 1143) id 3A0126D48E; Tue, 29 Nov 2005 15:16:07 -0500 (EST) Received: from hcmczombvvlcmo (unknown [216.93.252.30]) by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.5_DAKN) with ESMTP id 05FA86D489; Tue, 29 Nov 2005 15:16:05 -0500 (EST) Reply-To: From: "James Jun" To: , "'Dwight Jamieson'" , Subject: RE: V6ops: IPv6 site multihoming best practices Date: Tue, 29 Nov 2005 15:18:03 -0500 Organization: TowardEX Technologies, Inc. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0122_01C5F4F8.17A8C390" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Thread-Index: AcX1Hb/nUKgEKnbYR/qbudOSYK88MgAAfpyQAACMhIA= In-Reply-To: <20051129200152.EC3E16D44E@mx01.bos.ma.towardex.com> Message-Id: <20051129201605.05FA86D489@mx01.bos.ma.towardex.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0122_01C5F4F8.17A8C390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ugh, sorry guys, for the blank email. This was a mistake. Regards, James Jun IP Infrastructure & Technology Services TowardEX Technologies, Inc. WWW: http://www.towardex.com Email: james@towardex.com Office: +1 (617) 459-4051 Ext. 179 Mobile: +1 (978) 394-2867 _____ From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of James Jun Sent: Tuesday, November 29, 2005 3:04 PM To: 'Dwight Jamieson'; v6ops@ops.ietf.org Subject: RE: V6ops: IPv6 site multihoming best practices _____ From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Dwight Jamieson Sent: Tuesday, November 29, 2005 2:48 PM To: v6ops@ops.ietf.org Subject: V6ops: IPv6 site multihoming best practices In the absence of mature protocol support for site multi-homing (shim6), what are the best practice recommendations for an enterprise or service provider? Cheers, Dwight ------=_NextPart_000_0122_01C5F4F8.17A8C390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable V6ops: IPv6 site multihoming best practices

Ugh, sorry guys, for the blank = email.  This was a mistake.

 

Regards,

 

From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of James Jun
Sent: Tuesday, November = 29, 2005 3:04 PM
To: 'Dwight Jamieson'; v6ops@ops.ietf.org
Subject: RE: V6ops: IPv6 = site multihoming best practices

 

From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Dwight Jamieson
Sent: Tuesday, November = 29, 2005 2:48 PM
To: = v6ops@ops.ietf.org
Subject: V6ops: IPv6 site multihoming best practices

 

 

In the absence of mature protocol support for site multi-homing (shim6), what = are the best practice recommendations for an enterprise or service = provider?

Cheers,
Dwight

 

------=_NextPart_000_0122_01C5F4F8.17A8C390-- From owner-v6ops@ops.ietf.org Tue Nov 29 16:32:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhD5Q-0000YZ-Pv for v6ops-archive@megatron.ietf.org; Tue, 29 Nov 2005 16:32:28 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11527 for ; Tue, 29 Nov 2005 16:31:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhD3g-000DZv-OZ for v6ops-data@psg.com; Tue, 29 Nov 2005 21:30:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EhD3f-000DZa-TG for v6ops@ops.ietf.org; Tue, 29 Nov 2005 21:30:39 +0000 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA13919; Tue, 29 Nov 2005 13:30:38 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jATLUbC05318; Tue, 29 Nov 2005 15:30:37 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Nov 2005 13:30:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Tiny fragments and IPv6 Date: Tue, 29 Nov 2005 13:30:33 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A181898C@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: Tiny fragments and IPv6 Thread-Index: AcX1GB/nBn8d/LjDSMKlFkfDRsxjmgAEuNZg From: "Templin, Fred L" To: "Stig Venaas" Cc: X-OriginalArrivalTime: 29 Nov 2005 21:30:33.0801 (UTC) FILETIME=[216BDB90:01C5F52C] Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Stig,=20 > -----Original Message----- > From: Stig Venaas [mailto:Stig.Venaas@uninett.no]=20 > What I mainly would have like to see, both for IPv4 and IPv6, is some- > thing saying that fragments MUST not be overlapped. When=20 > receiving such > one could then just discard them... This may be a bit out of scope but (since you asked) the following is a proposal for segmentation/reassembly at a layer below IPv6 yet above IPv4 (for tunnels) that mandates fragments not be overlapped: http://www.ietf.org/internet-drafts/draft-templin-linkadapt-01.txt A requirements document related to this spec was briefed at the IETF64 v6ops session, but the spec itself will be targeted for some other working group. Fred fred.l.templin@boeing.com From owner-v6ops@ops.ietf.org Wed Nov 30 03:04:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhMx8-00038b-Il for v6ops-archive@megatron.ietf.org; Wed, 30 Nov 2005 03:04:34 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11859 for ; Wed, 30 Nov 2005 03:03:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhMsy-000MB4-Tw for v6ops-data@psg.com; Wed, 30 Nov 2005 08:00:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [193.6.222.240] (helo=mail.ki.iif.hu) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EhMsx-000MAf-F8 for v6ops@ops.ietf.org; Wed, 30 Nov 2005 08:00:15 +0000 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id 2CECF55BB; Wed, 30 Nov 2005 09:00:13 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 277FE55BA; Wed, 30 Nov 2005 09:00:13 +0100 (CET) Date: Wed, 30 Nov 2005 09:00:13 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Dwight Jamieson Cc: v6ops@ops.ietf.org Subject: Re: V6ops: IPv6 site multihoming best practices In-Reply-To: Message-ID: <20051130085657.I22599@mignon.ki.iif.hu> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I do prefer working solutions that exist for site multihoming: e.g RFC 3178. I also cover several alternatives in my IPv6 Multihoming presentation: http://www.6diss.org/workshops/saf/multihoming.pdf Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 On Tue, 29 Nov 2005, Dwight Jamieson wrote: > > > In the absence of mature protocol support for site multi-homing (shim6), > what are the best practice recommendations for an enterprise or service > provider? > > Cheers, > Dwight > From owner-v6ops@ops.ietf.org Wed Nov 30 09:27:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhSvP-0003Fs-7m for v6ops-archive@megatron.ietf.org; Wed, 30 Nov 2005 09:27:11 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22776 for ; Wed, 30 Nov 2005 09:26:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhSsd-000JP3-Lp for v6ops-data@psg.com; Wed, 30 Nov 2005 14:24:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EhSsc-000JOl-0E for v6ops@ops.ietf.org; Wed, 30 Nov 2005 14:24:18 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jAUEO1s08713; Wed, 30 Nov 2005 09:24:01 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: V6ops: IPv6 site multihoming best practices Date: Wed, 30 Nov 2005 09:23:44 -0500 Message-ID: Thread-Topic: V6ops: IPv6 site multihoming best practices Thread-Index: AcX1hBu5awjiUSpZSMW/P+c0tzfmfwAM41Ng From: "Dwight Jamieson" To: "Mohacsi Janos" Cc: Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Janos, The mechanisms described in RFC 3178 would maintain connectivity for an ISP link failure and have the potential to maintain connectivity after an ISP PE failure. Of course, a total ISP melt down would cause connections to be lost for the end stations in the site using the failed ISP. They could be reestablished using the alternate ISP. Do you know if this solution has wide acceptance from enterprises or ISPs? Cheers, Dwight -----Original Message----- From: Mohacsi Janos [mailto:mohacsi@niif.hu]=20 Sent: Wednesday, November 30, 2005 3:00 AM To: Jamieson, Dwight [CAR:NP10:EXCH] Cc: v6ops@ops.ietf.org Subject: Re: V6ops: IPv6 site multihoming best practices Hi, I do prefer working solutions that exist for site multihoming: e.g RFC 3178. I also cover several alternatives in my IPv6 Multihoming=20 presentation: http://www.6diss.org/workshops/saf/multihoming.pdf Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 On Tue, 29 Nov 2005, Dwight Jamieson wrote: > > > In the absence of mature protocol support for site multi-homing=20 > (shim6), what are the best practice recommendations for an enterprise=20 > or service provider? > > Cheers, > Dwight >