http://blog.gmane.org/gmane.ietf.ipv6 hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.ipv6/25489 <pre>Hi, This version is intended to respond to WG comments. In particular: - the title, Abstract and text have been modified to clarify the nature of the entire IID, not just the U/G bits; - there is additional text about DAD failures; - expanded IANA considerations. Please read and comment. Brian + Sheng -------- Original Message -------- Subject: I-D Action: draft-ietf-6man-ug-01.txt Date: Fri, 24 May 2013 21:23:55 -0700 From: internet-drafts&lt; at &gt;ietf.org Reply-To: internet-drafts&lt; at &gt;ietf.org To: i-d-announce&lt; at &gt;ietf.org CC: ipv6&lt; at &gt;ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Significance of IPv6 Interface Identifiers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-ietf-6man-ug-01.txt Pages : 11 Date : 2013-05-24 Abstract: The IPv6 addressing architecture includes a unicast interface identi</pre> Brian E Carpenter 2013-05-25T04:30:31 http://comments.gmane.org/gmane.ietf.ipv6/25463 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Enhanced Duplicate Address Detection Author(s) : Rajiv Asati Hemant Singh Wes Beebee Eli Dart Wes George Carlos Pignataro Filename : draft-ietf-6man-enhanced-dad-03.txt Pages : 12 Date : 2013-05-24 Abstract: Appendix A of the IPv6 Duplicate Address Detection (DAD) document in RFC 4862 discusses Loopback Suppression and DAD. However, RFC 4862 does not settle on one specific automated means to detect loopback of Neighbor Discovery (ND of RFC 4861) messages used by DAD. Several service provider communities have expressed a need for automated detection of looped backed ND messages used by DAD. This document includes mitigation techniques and then </pre> internet-drafts< at >ietf.org 2013-05-24T14:04:17 http://comments.gmane.org/gmane.ietf.ipv6/25447 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC) Author(s) : Fernando Gont Filename : draft-ietf-6man-stable-privacy-addresses-08.txt Pages : 26 Date : 2013-05-23 Abstract: This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware address (e.g., using IEEE identifiers), such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. </pre> internet-drafts< at >ietf.org 2013-05-24T01:01:21 http://comments.gmane.org/gmane.ietf.ipv6/25437 <pre>I first want to thank Dave who took the time to read and comment on my draft and to discuss the problems associated with it. Based on some offline discussions with Dave, I have changed this document to better address the current issues with RFC 4941 which are actually related to differences in interpretation of the wording used in the that document. In many cases the wording used gives implementations the choice of how best to accomplish the goal which can lead to bad choices being made which negates the purpose of the document. This draft is thus an update to the Privacy Extension document and also, because it does not allow a node to generate and use an IID based on a MAC address, an update to one section of RFC 4862 which pertains to this. In this document an approach is recommend that doesn't make use MAC addresses in the generation of public addresses. It does, in fact, endorse the use other approaches that aren't based on the use of MAC addresses in the generation of public addresses. Public addres</pre> Hosnieh Rafiee 2013-05-23T14:53:40 http://comments.gmane.org/gmane.ietf.ipv6/25435 <pre>The following errata report has been submitted for RFC6874, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6874&amp;eid=3633 -------------------------------------- Type: Technical Reported by: Michael Sweet &lt;msweet&lt; at &gt;apple.com&gt; Section: 4 Original Text ------------- An HTTP client, proxy, or other intermediary MUST remove any ZoneID attached to an outgoing URI, as it has only local significance at the sending host. Corrected Text -------------- An HTTP client, proxy, or other intermediary MUST retain any ZoneID attached to an outgoing URI, as it will be the only way for an HTTP server to return a URI containing a link-local address that can subsequently be used by the HTTP client. Notes ----- NOTE: PLEASE DO NOT REJECT THIS ERRATA BEFORE FURTHER REVIEW. I WILL BE SUBMITTING A NEW DRAFT PROPOSING THESE CHANGES; THIS ERRATA CA</pre> RFC Errata System 2013-05-23T14:44:25 http://comments.gmane.org/gmane.ietf.ipv6/25433 <pre>The following errata report has been submitted for RFC6874, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6874&amp;eid=3632 -------------------------------------- Type: Technical Reported by: Michael Sweet &lt;msweet&lt; at &gt;apple.com&gt; Section: 3 Original Text ------------- Such bare "%" signs are for user interface convenience, and need to be turned into properly encoded characters (where "%25" encodes "%") before the URI is used in any protocol or HTML document. However, URIs including a ZoneID have no meaning outside the originating node. It would therefore be highly desirable for a browser to remove the ZoneID from a URI before including that URI in an HTTP request. Corrected Text -------------- Such bare "%" signs are for user interface convenience, and need to be turned into properly encoded characters (where "%25" encodes "%</pre> RFC Errata System 2013-05-23T14:42:35 http://comments.gmane.org/gmane.ietf.ipv6/25429 <pre>Dear all, We prepared a new version which lists the changes to be added to RFC 3956, RFC 3306 and RFC 4607: http://tools.ietf.org/html/draft-ietf-6man-multicast-addr-arch-update-01 We are interested to hear your feedback on the proposed changes and also on the better approach to actually do the changes. We have considered two approaches: (1) maintain all the changes in this document (i.e., it will update the address architecture + RFC 3956, RFC 3306 and RFC 4607) (2) this document updates only the address architecture with the new flag + edit bis documents which will update RFC 3956, RFC 3306 and RFC 4607. What approach the WG want us to implement? Comments are more than welcome. Cheers, Med -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6&lt; at &gt;ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- </pre> mohamed.boucadair< at >orange.com 2013-05-23T08:16:17 http://comments.gmane.org/gmane.ietf.ipv6/25428 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Updates to the IPv6 Multicast Addressing Architecture Author(s) : Mohamed Boucadair Stig Venaas Filename : draft-ietf-6man-multicast-addr-arch-update-01.txt Pages : 10 Date : 2013-05-23 Abstract: This document updates the IPv6 multicast addressing architecture by defining the 17-20 reserved bits as generic flag bits. The document provides also some clarifications related to the use of these flag bits. This document updates RFC 3956, RFC 3306, RFC 4607 and RFC 4291. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-multicast-addr-arch-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-multicast-addr-arch-update-01 A diff from the previous version is avai</pre> internet-drafts< at >ietf.org 2013-05-23T08:02:26 http://comments.gmane.org/gmane.ietf.ipv6/25421 <pre>The following errata report has been submitted for RFC6874, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6874&amp;eid=3631 -------------------------------------- Type: Technical Reported by: Michael Sweet &lt;msweet&lt; at &gt;apple.com&gt; Section: 4 Original Text ------------- An HTTP client, proxy, or other intermediary MUST remove any ZoneID attached to an outgoing URI, as it has only local significance at the sending host. Corrected Text -------------- An HTTP client, proxy, or other intermediary MUST retain any ZoneID attached to an outgoing URI, as it will be the only way for an HTTP server to return a URI containing a link-local address that can subsequently be used by the HTTP client. Notes ----- The original advice ignores a very real issue: HTTP Servers that generate URIs from the client's Host: need to include the Clie</pre> RFC Errata System 2013-05-23T03:59:36 http://comments.gmane.org/gmane.ietf.ipv6/25420 <pre>The following errata report has been submitted for RFC6874, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6874&amp;eid=3630 -------------------------------------- Type: Technical Reported by: Michael Sweet &lt;msweet&lt; at &gt;apple.com&gt; Section: 3 Original Text ------------- Such bare "%" signs are for user interface convenience, and need to be turned into properly encoded characters (where "%25" encodes "%") before the URI is used in any protocol or HTML document. However, URIs including a ZoneID have no meaning outside the originating node. It would therefore be highly desirable for a browser to remove the ZoneID from a URI before including that URI in an HTTP request. Corrected Text -------------- Such bare "%" signs are for user interface convenience, and need to be turned into properly encoded characters (where "%25" enc</pre> RFC Errata System 2013-05-23T03:51:51 http://comments.gmane.org/gmane.ietf.ipv6/25418 <pre>Since July is holiday month for many (at least for me), we are starting the planning for IETF87 early. We have asked for a two hour slot in Berlin for the 6MAN working group. If you have a draft you would like to discuss, please send your request for agenda time to the 6man chairs. Please include in the request, the title and file name of the draft, the speakers name (and email), and how much time you need. We will prioritise drafts that are working group items and drafts that have been actively discussed on the list. We expect about half the presentation time to be used for open discussion, please plan your presentation accordingly. New drafts not discussed on the mailing list prior to the meeting, or drafts that do not appear to have support from the working group are unlikely to get time at the meeting. Please have agenda items to us by 2013-06-30 and also note the following deadlines for IETF87: 2013-07-08 (Monday): Internet Draft Cut-off for initial document (-00) submission by UTC 24:00 2013-07-1</pre> Ole Troan 2013-05-22T09:41:54 http://comments.gmane.org/gmane.ietf.ipv6/25410 <pre>Disclaimer: haven't read all the prior list discussion so don't know if this duplicates some existing discussion. I have some fundamental problems with this document as is. I will concentrate on sections 1, 2, and Appendix B, being the motivation/goals/justification, as opposed to the technical details. Let's start with B.1.1, which attempts to motivate a desire to prevent tracking hosts across networks using their public address(es): The above text convolutes two orthogonal issues: higher-layer ID (username in this case) and location. The higher-layer ID in other apps would be the DNS name, but here the text uses the username, though even in P2P applications the higher-layer ID used to resolve an application or piece of content would already be stable, and the question is what you can link it to. If you have two addresses that simultaneously or over time are associated with the same higher-layer ID, then those two addresses can be linked. Separate is the issue of location. Once you have a stable hig</pre> Dave Thaler 2013-05-20T19:56:53 http://comments.gmane.org/gmane.ietf.ipv6/25391 <pre>Folks, I've posted a rev of the aforementioned document, meant to address the comments received during IETF LC. This rev is the result of the IETF LC discussions we had on the 6man wg list and on the general IETF list, and of off-list discussions with a number of folks who generously provided input, reviewed proposed changes, etc. I'd expect this rev to be "ready to ship" or very close to that. But please provide your input confirming whether you think that's the case, or whether there are any remaining issues to be solved. The rev is available at: &lt;http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-07&gt;. A diff from the previous version of the I-D is available at: &lt;tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-6man-stable-privacy-addresses-06.txt&amp;url2=http://tools.ietf.org/id/draft-ietf-6man-stable-privacy-addresses-07.txt&gt;. Thanks so much! Best regards, </pre> Fernando Gont 2013-05-19T17:33:27 http://comments.gmane.org/gmane.ietf.ipv6/25383 <pre>Hello, A new version of http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy is available online. I considered the comments that I received and made the pertinent changes to this version. I also improved the document to better address the following issues that I have with RFC 4941. 1- lifetime of the IID The fact that the node might not generate a new IID when it receives a new subnet prefix Solution: Give the router prefix a higher priority than the IID's max lifetime 2- Nodes may use an IID that was generated based on a MAC address and use this in their response A MAC based IID may still be valid and this RFC does not force the node to stop using it. Solution: The node MUST not generate its IID based on a MAC address when using this approach. The Privacy Extension RFC does not clearly address this. 3- A better way to handle trouble shooting and debugging 4-The need to maintain the status of reserved IIDs and already used IIDs requiring a large storage space and the fact that the randomization of I</pre> Hosnieh Rafiee 2013-05-14T20:37:22 http://comments.gmane.org/gmane.ietf.ipv6/25382 <pre>#4: Normative section / Informational section After reading the document again, the main issue is that the document specifies a solution to a problem by detailing a specific implementation, but does not explain the design choices behind that solution. As such, we end up with an over constrained specification, which at the same time fails to explain the problems at hand. The specification aims at providing addresses that are "stable and different," so that the same host connecting will have different and uncorrelated addresses when connecting to different networks, but will keep the same address when connecting repeatedly to the same network. As Mike St-Johns pointed out, the solution is trivial: create a different random number each time the host connect to a new network; make sure that the same random number is reused if the host reconnect to the same network. The latter property can be achieved either by keeping of log of previously visited networks and the corresponding address, or by usin</pre> 6man issue tracker 2013-05-08T20:14:04 http://comments.gmane.org/gmane.ietf.ipv6/25381 <pre>#3: Need for DAD counter Your draft attempts to make the fallback predictable, by incorporating a DAD counter in the seeds of your nominal algorithm. But that means redefining the solution a only a guarantee that "the visiting host will have one of the same 2 or 3 addresses on the visited network." I am not sure it is worth the additional complexity, by opposition to just saying, "in case of collision, pick a new number." </pre> 6man issue tracker 2013-05-08T20:07:44 http://comments.gmane.org/gmane.ietf.ipv6/25368 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Packet loss resiliency for Router Solicitations Author(s) : Suresh Krishnan Dmitry Anipko Dave Thaler Filename : draft-ietf-6man-resilient-rs-01.txt Pages : 7 Date : 2013-05-06 Abstract: When an interface on a host is initialized, the host transmits Router Solicitations in order to minimize the amount of time it needs to wait until the next unsolicited multicast Router Advertisement is received. In certain scenarios, these router solicitations transmitted by the host might be lost. This document specifies a mechanism for hosts to cope with the loss of the initial Router Solicitations. Furthermore, on some links, unsolicited multicast Router Advertisements are never sent and the mechanism in this document is intend</pre> internet-drafts< at >ietf.org 2013-05-06T22:51:04 http://comments.gmane.org/gmane.ietf.ipv6/25356 <pre>Has anybody had a chance to look at this draft (http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy )? Any comments? The aim of this draft is to adapt the current RFC to the latest European law http://europa.eu/rapid/press-release_IP-12-46_en.htm?locale=en and to accommodate the needs of customers with relation to the new law for a long term period. The purpose is to allow users to choose their means to the privacy and anonymity within a network as well as across networks. There is still an option of merging this draft with other drafts, that address the issue of allowing users to set the lifetime of the IP address during the installation or an option to set it by the users, if people on the mailing list thinks it would be useful. Share your technical ideas. Thanks, Best, Hosnieh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6&lt; at &gt;ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 ---------------------------------</pre> Hosnieh Rafiee 2013-05-04T19:17:37 http://comments.gmane.org/gmane.ietf.ipv6/25337 <pre>Dear all, I explained the purpose of this draft in my last message to the list ( You can find it here http://www.ietf.org/mail-archive/web/ipv6/current/msg17718.html ). I upload this draft which addresses the problems in rfc 4941. I would appreciate your comments. Share your ideas as to whether or not you find it useful. Thanks, Best, Hosnieh Filename: draft-rafiee-6man-ra-privacy Revision: 00 Title: Router Advertisement based privacy extension in IPv6 autoconfiguration Creation date: 2013-05-02 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-rafiee-6man-ra-privacy-00.txt Status: http://datatracker.ietf.org/doc/draft-rafiee-6man-ra-privacy Htmlized: http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy-00 Abstract: Privacy is an important issue for many governments and users where its importance becomes more evident every day. Nodes might change their IP addresses frequently in order to avoid being tracked by </pre> Hosnieh Rafiee 2013-05-02T19:54:20 http://comments.gmane.org/gmane.ietf.ipv6/25336 <pre>Dear All, Since Fernando's proposal is not going to solve the current problem with RFC 4941, I have suggested to him, on several occasions, that he resolve this problem so that the node's privacy will be better protected but he ignored this suggestion and claiming that his purpose is different. This is the main reason that today I wrote an RFC draft which I will submit to the IETF repository. This draft does not overlap Fernando's proposal it is related to the problems with this RFC (RFC 4941) which he doesn't feel the need to address. The problems that I address here concern the fact that the node should also change its IID when it receives different router prefixes. In the experimental results, Windows machine that implemented privacy extension RFC, generates different IIDs by rebooting .But when it receives a different prefix without a reboot, then, on the first two occasions that the new prefixes received, the node was generated a new IID, but not for other new prefix generations. Also, as you</pre> Hosnieh Rafiee 2013-05-02T19:35:06 http://comments.gmane.org/gmane.ietf.ipv6/25326 <pre>#2: Description of issues with traditional SLAAC addresses (embedding IEEE identifiers) Some folks have noted that this I-D should clarify what are the issues with traditional SLAAC addresses (addresses that embed link-layer addresses). This is deemed as key to clarify which of them are solved/mitigated by the method discussed in this document. </pre> 6man issue tracker 2013-04-30T07:51:04 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.ipv6