Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Fred, -Original Message- From: Ronald Bonica [mailto:rbon...@juniper.net] Sent: Tuesday, October 08, 2013 5:46 PM To: Ole Troan; Templin, Fred L Cc: i...@ietf.org; ietf@ietf.org Subject: RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard I agree with Ole. How so? A tunnel that crosses a 1280 MTU link MUST fragment in order to satisfy the IPv6 minMTU. If it must fragment, then an MTU-length IPv6 header chain would not fit within the first fragment, and we have opened an attack vector against tunnels. This is not a matter to be agreed or disagreed with - it is a simple fact. right, and RFC2460 has this to say about it: IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Fred, -Original Message- From: Ronald Bonica [mailto:rbon...@juniper.net] Sent: Tuesday, October 08, 2013 5:46 PM To: Ole Troan; Templin, Fred L Cc: i...@ietf.org; ietf@ietf.org Subject: RE: Last Call: draft-ietf-6man-oversized-header-chain- 08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard I agree with Ole. How so? A tunnel that crosses a 1280 MTU link MUST fragment in order to satisfy the IPv6 minMTU. If it must fragment, then an MTU-length IPv6 header chain would not fit within the first fragment, and we have opened an attack vector against tunnels. This is not a matter to be agreed or disagreed with - it is a simple fact. right, and RFC2460 has this to say about it: IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6. Very true. In this case, the link is the tunnel and the link-specific fragmentation is IPv6 fragmentation. Which places the first part of an MTU-length IPv6 header chain in the first fragment and the remainder of the header chain in the second fragment. indeed. which would violate the MUST in oversized-header-chain. what do we do? a) ignore this particular corner case b) suggest the tunnel head end to drop the packet c) develop a new tunnel segmentations scheme that doesn't depend on IPv6 fragmentation. :-) cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Fred, Hi, I would like to make a small amendment to what I said in my previous message as follows: 4) Section 5, change the final paragraph to: As a result of the above mentioned requirements, a packet's header chain length MUST fit within the Path MTU associated with its destination. Hosts MAY discover the Path MTU, using procedures such as those defined in [RFC1981] and [RFC4821]. However, if a host does not discover the Path MTU, it MUST assume the IPv6 minumum MTU of 1280 bytes [RFC2460]. The host MUST then limit each packet's header chain length to the Path MTU minus 256 bytes in case additional encapsulation headers are inserted by tunnels on the path. I would claim that additional encapsulation headers are already considered in the 1280 minimum MTU. as in: 1500 - 1280. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail
Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06
Further to that, ifindexes of tunnels and PPP sessions can change dynamically as the bearer connection goes up and down, even if the interface has the same name and authenticated identity. That raises the interesting question of whether even the interface name is stable, as on many systems it is pure chance if the same name-identity mapping repeats itself. If you want a stable address, you want to use something that actually has the exact stability properties you require, and interface indexes and names are seldom what you actually need. could we simplify the hash to only include the prefix, cookie and DAD counter: RID = F(Prefix, secret_key, DAD_Counter) an implementation that wants a stable address for cases where DAD_Counter 0, must keep state. e.g. maintain a table of prefix, dad_counter or list of previous addresses. cheers, Ole
Re: IPv6 traffic distribution
Michel, Joel Jaeggli wrote: 6rd is global unicast... there's nothing to discriminate it from any other native range. No. there is nothing in the current classification algorithm to discriminate from any other native range. But it's not native, as it has, among other things, the same reliance on IPv4 and the same MTU issues than 6to4 as the core mechanism is based on 6to4 tunneling, or encapsulation, or whatever else you want to call it. the 6rd MTU is under control of a single provider. the transport layer MTU can be set large enough to provide a 1500 byte MTU for IPv6. I presume you are arguing that MPLS (6PE) is not native either? cheers, Ole ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-v6ops-6to4-to-historic (yet again)
I'm in favor of the proposed action and the clarification of historic, suggested in the new section. (I could be in _strong_ favour to nullify Keith's 'vote', although I hope we're not counting. ;-)), . cheers, Ole On Jul 25, 2011, at 10:30 , Ronald Bonica wrote: Folks, After some discussion, the IESG is attempting to determine whether there is IETF consensus to do the following: - add a new section to draft-ietf-v6ops-6to4-to-historic - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and convert their status to HISTORIC. It will also contain a new section describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. The new section will say that: - 6-to-4 should not be configured by default on any implementation (hosts, cpe routers, other) - vendors will decide whether/when 6-to-4 will be removed from implementations. Likewise, operators will decide whether/when 6-to-4 relays will be removed from their networks. The status of RFCs 3056 and 3068 should not be interpreted as a recommendation to remove 6-to-4 at any particular time. draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it clarifies the meaning of HISTORIC in this particular case, it does not set a precedent for any future case. Please post your views on this course of action by August 8, 2011. Ron Bonica speaking as OPS Area AD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-v6ops-6to4-to-historic
Roger, Guess I should clearify something, the thing I am considering are to drop all 2002::/16 addresses hard, of course preferable return a correct error messages to. wonder how many find 6to4 usable when ISPs start doing that? Nuclear winter or not may follow. took me a while to warm up to PMT, but now I think that's a perfectly valid solution to rescue the set of innocent victims of 6to4. http://tools.ietf.org/html/draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02 wouldn't be surprised if there already are commercial products that can do that. cheers, Ole --- Roger J --- On Sun, Jul 3, 2011 at 9:32 PM, Roger Jørgensen rog...@gmail.com wrote: A bit late since this threat will be moderated soon. But I strongly object to this delay of needed action. I guess the other way the problem, which will hurt muchmuch more is maybe to considering a filter of 6to4 on isp level? I will suggest it when we start deploying native ipv6. --- Roger J. --- On Jul 2, 2011 6:39 PM, Ronald Bonica rbon...@juniper.net wrote: Folks, Whereas there has been considerable controversy regarding draft-ietf-v6ops-6to4-to-historic, the v6ops chairs and document author have agreed to the following course of action: - the V6OPS WG will withdraw its request to publish draft-ietf-v6ops-6to4-to-historic - The author will introduce a new draft, intended for standards track publication. The new draft will update RFCs 3056 and 3068. It will say that if 6-to-4 is implemented, it must be turned off by default. - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Ron Speaking as OPS Area AD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 to Experimental? (was: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic)
Keith, The alternative that I proposed to IESG and to the chairs (and never received any feedback about) was to reclassify 6to4 as Experimental. Experimental seems completely appropriate for a protocol that is useful, but only in corner cases. And I think it's also appropriate and useful to try to learn from the experience with 6to4, even if we realize that 6to4 will never be a generally applicable IPv6 transition solution again. And maybe, just maybe, Experimental will be enough of a slap at 6to4 to mollify the kill it yesterday crowd. For one thing, it clearly indicates that 6to4 is no longer a standard. But in order to quieten down the discussion here, I suggest that people reply to me privately if they can't live with this. If I get lots of those replies, I'll know that it's not worth pursuing. Experimental is certainly better than: - nothing - spending months on hold as appeals are processed. cheers, Ole ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
Noel, it seems that a lot of the issues could be mitigated by simple connectivity test. Well, IPv6 Neighbour Discovery is just the thing. I gather it's turned off on 6to4 links, which in retrospect was probably a mistake. I would recommend that it be turned on, but apparently the WG decided against making that recommendation in the '6to4 fixes' document? IPv6 Neighbour Discovery requires a multicast capable link and support for link-local addresses. a 6to4 link doesn't support either. NUD could be made to work, but I don't think NUD is any better than any other connectivity test. e.g. a BFD echo style one as specified for 6rd. cheers, Ole ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC Review of draft-ietf-v6ops-6to4-to-historic-04
Ben, splendid comments! I've tried to incorporate all of them, and will either issue a new revision or make the changes during AUTH48 depending on other LC feedback. cheers, Ole I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-v6ops-6to4-to-historic-04 Reviewer: Ben Campbell Review Date: 2011-06-17 IETF LC End Date: 2011-06-20 IESG Telechat date: 2011-06-23 Summary: The draft is essentially ready for publication as an informational RFC. I have a few editorial comments that may be worth considering prior to final publication. Major issues: None Minor issues: None Nits/editorial comments: -- general: Idnits reports some potential issues. please check. -- abstract: The headers say this draft obsoletes these RFCs. Does moving to historical obsolete then in that sense? Perhaps the abstract should say something like obsoletes, and moves to historical -- section 1, 2nd paragraph: ...designed to help transitioning the Internet... Help transition, help in transitioning, or help the transition of -- section 1, last paragraph: Please expand 6rd on first mention. Also, Is this meant as an explicit recommendation of 6rd as an alternative? -- section 3, third paragraph: ...same operational burden has manually configured tunnels... s/has/as -- section 3, first bullet: ... and in the case the relay is overloaded packet loss. overloaded, packet loss. -- section 3, third bullet: ...customer relationship or... ... customer relationship between the end-user and the relay operator, or... -- section 3, 4th bullet: In case of the reverse path 6to4 relay and the anycast forward 6to4 relay, these have to be open for any address. Only limited by the scope of the routing advertisement. Awkward sentence followed by a sentence fragment. Can these be reworded? -- section 3, 5th bullet: black hole Please define black hole in this context, or use a more descriptive (I.e. less jargony) term. -- section 4, 2nd paragraph: It is expected that disabling 6to4 in the IPv6 Internet will take some time. Who expects it? The IETF? v6ops? The authors? (or can we just drop It is expected that) ...deploy native IPv6 service. s/service/services -- section 4, numbered list: It's not clear to me why this is a numbered list rather than an ordinary paragraph ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
Michel, making 6to4 historic does not affect 6rd. I think the draft says that much too. I don't think we are saying that native necessarily is better than tunnels. we are saying unmanaged tunnels crossing the Internet is bad. 6rd is managed and contained within a single SP's network. cheers, Ole According to this: http://blogs.cisco.com/sp/france-is-famous-for-fine-wine-cheese-and-now- ipv6/ and some more recent direct talks in French, about half of worldwide IPv6 traffic is French. The bulk of it comes from a single ISP (Free, AS12322) and their IPv6 is 6RD (RFC5569, RFC5969), a variant of 6to4. Given the constant references in 6RD to 6to4, I will point out that making 6to4 historic somehow reduces the likeliness of another extremely successful ISP implementation based on it. Although Google (in http://www.pam2010.ethz.ch/papers/full-length/15.pdf) and other measurements classify AS12322's traffic as native, it is 6RD behind the scenes. If the argument is that IPv6 native should be the preferred solution over tunneled, it does not hold water. If you were to remove 6to4 and 6RD from the picture, that would set us back 10 years ago in terms of IPv6 adoption. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
Keith, I'm loathe to go through this discussion again. let me just respond to some of the points you make, and then agree that we disagree. I strongly object to the proposed reclassification of these documents as Historic. 6to4 still has many valid use cases, and there is not a suitable replacement for it that has been deployed. Until there is a suitable replacement, or until there is widespread ISP support for native IPv6, reclassification of this document to Historic is premature. (6rd is not a suitable replacement for 6to4, as it is intended for very different use cases than 6to4.) (It could be argued that reclassification of RFC 3068 (by itself) to Historic is appropriate, but that would require a separate document and last call.) In addition, this document is misleading and perhaps even vituperative. For instance: There would appear to be no evidence of any substantial deployment of the variant of 6to4 described in [RFC3056]. This statement is blatantly false. 6to4 is supported by every major desktop and server platfrom that is shipping today, and has been supported for several years. incorrect. there is no evidence that the _managed_ model of 6to4 described in rfc3056 has any deployment. that's the model where relay operators advertise what parts of the 6to4 space they are routing. with BGP neighborships between managed and participating relays. _deployment_ not _support_. The IETF sees no evolutionary future for the mechanism and it is not recommended to include this mechanism in new implementations. 6to4 never was intended to have an evolutionary future. It was always intended as a near-term solution to allow consenting hosts and networks to interchange IPv6 traffic without prior support from the IPv4 networks that carry the traffic. It is premature to recommend that 6to4 be removed from implementations. We do not know how long it will take ISPs to universally deploy IPv6. Until they do, there will be a need for individuals and enterprises using IPv6-based applications to be able to exchange IPv6 traffic with hosts that only have IPv4 connectivity. All of the criticisms in section 3 have to do with the use of relays to exchange traffic between 6to4 and native IPv6. In many cases the criticisms are overbroad. Not all uses of 6to4 involve relays. For some of those that do need to use relays, it is not necessarily the case that the relay is operated by an unknown third-party. The fact that some firewalls block protocol 41 traffic causes problems for many tunneling solutions, not just 6to4; yet this document appears to recommend some tunneling solutions while trashing 6to4. it is the unmanaged aspect of 6to4 deployment that exhibits the most problems. a manually configured managed point to point tunnel may also be blocked in a firewall, but then the operator will have to sort that out. 6to4 has no operator. Teredo is similar in many aspects to 6to4, but there is little evidence that it causes the same problems. largely because it is the choice of last resort in implementations and it hasn't/can't be enabled by default in CPEs. The recommendations to treat 6to4 as a service of last resort will do harm to users and applications using it. A better recommendation is for hosts to disable 6to4 by default. This document appears to make the mistake of assuming that the purpose of applications using IPv6 is to interoperate with the existing Internet. I have maintained for many years that it is new applications, or existing applications that can't tolerate widespread deployment of IPv4 NAT, that will drive use of IPv6. I therefore believe that it is inappropriate to judge 6to4 merely by how well it works in scenarios where it is being used to talk to applications that work well over IPv4 NAT such as HTTP. The Internet is much more diverse than that, and will become even more diverse as IPv6 enjoys wider deployment. 6to4 does not work through IPv4 NATs. It is also premature to remove references to 6to4 from RFC 5156bis, for IANA to mark the prefix and DNS zones as deprecated. This will only cause confusion and difficulty for legitimate continued uses of 6to4. the purpose of the text in the document is to ensure that the deprecated prefixes are not reused before 6to4 has been phased out. cheers, Ole ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-gundavelli-v6ops-l2-unicast
Bernard, thanks for a very thorough review. [I didn't see this before the IESG raised a DISCUSS, it must be useful for the authors / wg to see these reviews too?] [...] In the abstract, the draft correctly states that it is not mandatory that the link layer destination of an IP multicast packet be a link layer multicast address. However, the document does not state what the functional requirement is, namely that the IP multicast packet be delivered to all potential subscribers. In some situations (such as a point-to-point link), this requirement can be met by sending the frame to a unicast destination link-layer address. In other situations (such as a WLAN), to meet that requirement it would be necessary to either send the frame to a multicast link-layer destination address *or* to send the frame to multiple unicast link-layer destination addresses. we specifically didn't want to go into the use cases for this functionality. e.g. one use case being N:1 VLANs (which are point to point upstream and multi-access downstream), where one wants to send a different multicast message to each user. everyone listens to the same multicast address (e.g. IPv6 all routers), but the message sent to each is different, and that requires (in that deployment) unicast L2 addresses. basically making the link appear like a point to point link. what the functional requirement is, depends. so I'd very much like to keep that out of the document, which only purpose is to clarify that it is valid to map a L3 IPv6 multicast address into a L2 unicast address. The draft does not state the fundamental requirement, and is not sufficiently precise about the circumstances in which a unicast link-layer address can be used. For example, Section 3 states: o An IPv6 sender node in some special cases and specifically when the link-layer address of the target node is known, MAY choose to transmit an IPv6 multicast message as a link-layer unicast message to that node. In this case, the destination address in the IPv6 header will be a multicast group address, but the destination address in the link-layer header will be an unicast address. The problem is that the above paragraph does not adequately define the meaning of the term sender or the special cases in which the MAY applies. indeed. the same argument as above applies. with regards to sender, I've looked through a few multicast RFCs and none of them define the term sender. to me, although a non-native English speaker, the term is not ambiguous. could you clarify what you mean? Certainly if we are talking about a point-to-point link then a sender can know that there is only one potential subscriber on the other end. indeed. I would imagine many of the use cases are for such deployments, point to point links, or where one try to make a multi-access link look like it is point to point, where this mapping is done for link-local multicast packets. e.g. ND RAs. Also, if the sender is a device such as a switch or AP, then it will have knowledge of the potential endpoints that are potential targets. However, if the sender is a host, then the question is how a sender can know the link-layer address of all the target nodes. Hosts don't normally keep track of multicast subscriptions. In some situations, that may not even be possible -- if we are talking about a multicast group that is not link-scope, and the target node is known but is not on the link, the host won't be able to obtain this knowledge and in any case, sending the frame to the target's link layer address doesn't make sense, since it could result in the frame not being delivered. I haven't seen any use case where a host would use this. but, if there was one, it would have to know the L2 address by some other means. again, we do not want to go into details on how this could be used. just state that the alternative mapping is valid. So I think that the term sender needs to be defined and this paragraph needs to be re-written to make it very clear when a unicast link-layer address can be used by the sender, and in what circumstances this is not safe. this document is being referenced by BBF and also by some work in PMIP(?). in any case I'd like those documents to have the restrictions. on the other hand I see your point. we don't want 'random' multicast senders to optimize and use this mapping. the introduction states that this applies when there is _one_ receiver. if we also added that restriction to the above paragraph, would that make it clearer? o An IPv6 receiver node SHOULD NOT drop a received IPv6 multicast message only for the one specific reason that the received IPv6 message has a multicast destination address in the IPv6 header while the link-layer header has a unicast address. Such a validity check comparing the address types in the IP header and the link-layer header is
Re: site local addresses
Except of those 14 some seven(?) are RFC3041 addresses, which break a number of applications... so there are some clouds in the sky. 3041 may be next on the hit-list. Pretty soon it truly will be nothing but bigger addresses. lets shoot down those 128 bit addresses too, 64 must be enough. /ot
