http://permalink.gmane.org/gmane.ietf.ipv6 hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.ipv6/25914 <pre>Hi, On 18/06/2013 23:17, Fernando Gont wrote: I tend to agree with Fernando. The dependency is the other way round; stable-privacy-addresses is a reference for the new draft. I have the same question about draft-ietf-6man-ug. We responded to all comments in the -01 version. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6&lt; at &gt;ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- </pre> Brian E Carpenter 2013-06-18T22:32:29 http://permalink.gmane.org/gmane.ietf.ipv6/25913 <pre>I have improved the document and also clearly explained the problems that this document addresses in the Introduction section. I also improved the algorithm for IID lifetime, which is now a conditional application based lifetime. &lt;http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy-04&gt; http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy-04 Abstract: Privacy is an important issue which concerns many governments and users, with its importance becoming more evident every day. Nodes change their IP addresses frequently in order to avoid being tracked by attackers. The act of frequently changing IP addresses also helps to prevent the leakage of information by nodes. In IPv6 networks there is currently one solution for maintaining the privacy of nodes when IPv6 StateLess Address AutoConfiguration (SLAAC) (RFC 4862) is used. Unfortunately there are some problems associated with this solution which entails the use of the Privacy Extension (RFC 4941). One of t</pre> Hosnieh Rafiee 2013-06-18T17:33:01 http://permalink.gmane.org/gmane.ietf.ipv6/25912 <pre>Ole, On 06/18/2013 10:20 AM, Ole Troan wrote: I'm already working on such I-D.. but I disagree that progrees of this document should depend on such document. Why should it? We kind of beaten this issue to death.. and that's the reason for which I ended up adding all the text that I added to the I-D. There's people working on implementations of this document, so we should progress it in a timely fashion. Besides, my personal sense of the wg is that all of the comments I received were addressed, and that there's general agreement to move the document forward. So, procedurally-speaking, I don't understand the basis of stalling this document. Cheers, </pre> Fernando Gont 2013-06-18T11:17:25 http://permalink.gmane.org/gmane.ietf.ipv6/25911 <pre>Fernando, We are thinking that it would be good to have a separate draft that describes the current approaches to IID creation and how they effect privacy and tracking. Somewhat along the lines of the email and chart sent to the IPv6 list by Alissa Cooper. The stable-privacy draft should then wait until that work has progressed. Best regards, Ole (6man co-chair hat on) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6&lt; at &gt;ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- </pre> Ole Troan 2013-06-18T08:20:11 http://permalink.gmane.org/gmane.ietf.ipv6/25910 <pre>ping? On 06/12/2013 07:55 PM, Fernando Gont wrote: </pre> Fernando Gont 2013-06-18T05:11:51 http://permalink.gmane.org/gmane.ietf.ipv6/25909 <pre> On Jun 14, 2013, at 6:31 PM, Doug Barton &lt;dougb&lt; at &gt;dougbarton.us&gt; wrote: Oh, well thank you. I appreciate this, and feel honored. W P.S: no sarcasm. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6&lt; at &gt;ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- </pre> Warren Kumari 2013-06-15T01:51:55 http://permalink.gmane.org/gmane.ietf.ipv6/25908 <pre> Yeah, you would be one of those "more knowledgeable" folks I was referring to. :) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6&lt; at &gt;ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- </pre> Doug Barton 2013-06-14T22:31:12 http://permalink.gmane.org/gmane.ietf.ipv6/25907 <pre> The problem with that approach is that for a very substantial fraction of Internet backbones, the real operational requirement is substantially *less* capable than what is written in RFC 2460 and than what you propose here. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6&lt; at &gt;ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- </pre> Lorenzo Colitti 2013-06-14T22:15:20 http://permalink.gmane.org/gmane.ietf.ipv6/25906 <pre> On Jun 14, 2013, at 2:56 PM, Doug Barton &lt;dougb&lt; at &gt;dougbarton.us&gt; wrote: I've already mentioned this in one of the N (where is is becoming distressingly large) threads on this, but we are planning on: A: adding something like this (you should be able to look N bytes / headers in the packet) to the long headers draft (RSN, promise!) and / or B: writing an advice to implementers draft. One of the co-authors (Ron) of the long-headers draft works for Juniper and has discussed this with their forwarding folk. We are also having discussions with other vendors on the same topic, and will hopefully have another author from at least one of the other large chappies… W -- Credo quia absurdum est. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6&lt; at &gt;ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- </pre> Warren Kumari 2013-06-14T22:00:32 http://permalink.gmane.org/gmane.ietf.ipv6/25905 <pre> The flip side of that is that if we don't stop changing the spec the protocol will never be deployed in a meaningful way. We cannot expect hardware vendors to do fast path for an effectively infinite number of bytes of EH. If you think that a number based on current limitations is too ... limiting, make your case for what the number should be. But "infinite" is not on the table. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6&lt; at &gt;ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- </pre> Doug Barton 2013-06-14T21:33:52 http://permalink.gmane.org/gmane.ietf.ipv6/25904 <pre> While guidance is useful to establish a consistent-behavior baseline across vendors and deployments, care must be taken to avoid the trap of precluding innovation and evolution. Well-meaning limits based on current hardware capabilities will become doctrine over time, and changing values to allow something new will become virtually impossible, as the utility of the new thing without a significant deployment base will never outdo the inertia of established practice. Particularly when there is a perception that the established practice has some 'security' value. I have no issue with requiring L4 in the first fragment, though what constitutes a fragment needs to change. It is long past time that 1500B packets should have been removed as a limiting factor, and if/when we ever do get to something larger, restricting header chains to 256B will look absurd. BCP -&gt; YES Hard byte count -&gt; NO (make that hell no) Focus on the real operational requirement (firewall functionality), then make sure that the cons</pre> Tony Hain 2013-06-14T21:19:03 http://permalink.gmane.org/gmane.ietf.ipv6/25903 <pre>... Exactly. Tunnels of any kind are considered very suspect, so I don't think this is part of the same problem. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6&lt; at &gt;ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- </pre> Brian E Carpenter 2013-06-14T20:25:03 http://permalink.gmane.org/gmane.ietf.ipv6/25902 <pre>Ray, On 15/06/2013 01:25, Ray Hunter wrote: ... Right, but that would be clearly pointless or some kind of attack, so dropping it would be fine. " This document uses a mechanism that tunnels Neighbor Discovery (ND) packets inside another IPv6 packet that uses a destination option (Line-ID option) to convey line-identification information..." In other words, only used in a local context where ND makes sense; not an issue for WAN traffic. Only used within a ROLL domain. I don't think cases like this are troublesome. Extension headers and options that need to be used over the WAN are the problem cases. That's why this is a SHOULD NOT and a health warning, not a MUST NOT. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6&lt; at &gt;ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- </pre> Brian E Carpenter 2013-06-14T20:21:42 http://permalink.gmane.org/gmane.ietf.ipv6/25901 <pre> Others (more knowledgeable than I) had already made that point, but for the record, yes, we should check with the hardware folks on this. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6&lt; at &gt;ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- </pre> Doug Barton 2013-06-14T18:56:54 http://permalink.gmane.org/gmane.ietf.ipv6/25900 <pre>What about nested Generic Packet Tunneling in IPv6 [rfc2473]? That'll add another 48 octets per nesting level. [fresh IPv6 tunnel header + destination options including IPv6 Tunnel Hop Limit] On the one hand I can see they'll be really useful, certainly during a transition period, to allow operators to bypass core devices that cannot cope with switching more complex header chains in hardware. On the other hand, their very ability to hide L4 headers and complex header chains will likely make them unlikely to survive traversing firewalls. regards, RayH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6&lt; at &gt;ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- </pre> Ray Hunter 2013-06-14T16:23:09 http://permalink.gmane.org/gmane.ietf.ipv6/25899 <pre>Best answer I can see is that the limit applies except for routers supporting specific features. Corollary is that not all routers will do so, and people defining such features should be aware of that. Tom Taylor -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6&lt; at &gt;ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- </pre> Tom Taylor 2013-06-14T15:06:47 http://permalink.gmane.org/gmane.ietf.ipv6/25898 <pre>FWIW I agree. But what would a standard limit of 256 octets on the header chain mean if one single option can be as long as the limit for the entire header chain? Is the limit only applicable across AS boundaries? On high speed devices only? YMMV? regards, RayH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6&lt; at &gt;ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- </pre> Ray Hunter 2013-06-14T14:21:41 http://permalink.gmane.org/gmane.ietf.ipv6/25897 <pre>... ... Neither of these should appear outside of limited domains. The Line Identification option passes from the Access Node in a broadband deployment to the edge router (BNG) and goes no further. The RPL option is used only inside of RPL networks. Tom Taylor -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6&lt; at &gt;ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- </pre> Tom Taylor 2013-06-14T13:58:03 http://permalink.gmane.org/gmane.ietf.ipv6/25896 <pre> Sander Steffann wrote: I've been trawling through various standards trying to identify sane extension header combinations myself. I've come across a couple of problematic standardised options already defined that don't appear to have individual length limits below the overall generic limit of 256 octets per option (derived from the "Opt Data Len" field being 1 octet), so limiting the overall header length to 256 octets could have direct impact on those. PadN (of course) The lineID option rfc6788. The Routing Protocol for Low-Power and Lossy Networks (RPL) Option rfc6553 regards, RayH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6&lt; at &gt;ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- </pre> Ray Hunter 2013-06-14T13:25:18 http://permalink.gmane.org/gmane.ietf.ipv6/25895 <pre> Yes. The proposal will be implemented. Regards, -sm -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6&lt; at &gt;ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- </pre> SM 2013-06-14T10:18:37 http://permalink.gmane.org/gmane.ietf.ipv6/25894 <pre>----- Original Message ----- From: "Doug Barton" &lt;dougb&lt; at &gt;dougbarton.us&gt; To: &lt;ipv6&lt; at &gt;ietf.org&gt; Sent: Thursday, June 13, 2013 9:23 PM than X, is it's a opposed I would like to check with current hardware designers that 256 is a good number for them, as opposed to 240, say. What I mean is that 256 is a nice round number, for us as for them, and so is a natural choice. But sometimes that has to include red tape, control information and such like, so what you get as a nice round number is a bit less when you pass it on to the next level of processing. Of course, with some hardware, that is built in, so that the hardware gets something greater and passes on a nice round number to its user (as with memory cards) but I have known occasions in the past when this was not the case and the choice of a nice round number caused problems. Apart from that 'detail', I agree with the approach. Tom Petch -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6&lt; at &gt;ietf.or</pre> t.petch 2013-06-14T08:39:10 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.ipv6