RE: DHCPv6 authentication
Hi, the question is simply whether anyone is using, or knows of any use of) DHCPv6 Authentication. Does it work? What is the operational experience? Thanks - Fred fred.l.temp...@boeing.com
DHCPv6 authentication
Hi - does anyone know if DHCPv6 authentication is commonly used in operational networks? If so, what has been the experience in terms of DHCPv6 servers being able to discern legitimate clients from rogue clients? Thanks - Fred fred.l.temp...@boeing.com
RE: DHCPv6 authentication
Hi Jared, I am assuming 802.1x (or equivalent) security at L2, but the link between my DHCPv6 client and server is actually a tunnel that may travel over many network layer hops. So, it is possible for legitimate client A to have its leases canceled by rogue client B unless DHCPv6 auth or something similar is used. Yes, rogue client B would also have to be authenticated to connect to the network the same as legitimate client A, but it could be an insider attack (e.g., where B is a disgruntled employee trying to get back at a corporate adversary A). Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: Jared Mauch [mailto:ja...@puck.nether.net] Sent: Wednesday, August 20, 2014 5:14 PM To: Templin, Fred L Cc: nanog list Subject: Re: DHCPv6 authentication If you are already connected to the network you are going to be deemed as authenticated. I'm unaware of anyone doing dhcp authentication. Jared Mauch On Aug 20, 2014, at 6:45 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi - does anyone know if DHCPv6 authentication is commonly used in operational networks? If so, what has been the experience in terms of DHCPv6 servers being able to discern legitimate clients from rogue clients? Thanks - Fred fred.l.temp...@boeing.com
RE: IP tunnel MTU
Hi Chris, -Original Message- From: Chris Woodfield [mailto:rek...@semihuman.com] Sent: Monday, October 29, 2012 4:40 PM To: Templin, Fred L Cc: William Herrin; Ray Soucy; NANOG list Subject: Re: IP tunnel MTU True, but it could be used as an alternative PMTUD algorithm - raise the segment size and wait for the I got this as fragments option to show up... Yes; it is a very attractive option on the surface. Steve Deering called it Report Fragmentation (RF) when he first proposed it back in 1988, but it didn't gain sufficient traction and what we got instead was RFC1191. As I mentioned, SEAL does this already but in a best effort fashion. SEAL will work over paths that don't conform well to the RF model, but will derive some useful benefit from paths that do. Of course, this only works for IPv4. IPv6 users are SOL if something in the middle is dropping ICMPv6. Sad, but true. Thanks - Fred fred.l.temp...@boeing.com -C On Oct 29, 2012, at 4:02 PM, Templin, Fred L wrote: Hi Bill, Maybe something as simple as clearing the don't fragment flag and adding a TCP option to report receipt of a fragmented packet along with the fragment sizes back to the sender so he can adjust his mss to avoid fragmentation. That is in fact what SEAL is doing, but there is no guarantee that the size of the largest fragment is going to be an accurate reflection of the true path MTU. RFC1812 made sure of that when it more or less gave IPv4 routers permission to fragment packets pretty much any way they want. Thanks - Fred fred.l.temp...@boeing.com
RE: IP tunnel MTU
Hi Ray, MSS rewriting has been well known and broadly applied for a long time now, but only applies to TCP. The subject of MSS rewriting comes up all the time in the IETF wg discussions, but has failed to reach consensus as a long-term alternative. Plus, MSS rewriting does no good for tunnels-within-tunnels. If the innermost tunnel rewrites MSS to a value that *it* thinks is safe there is no guarantee that the packets will fit within any outer tunnels that occur further down the line. What I want to get to is an indefinite tunnel MTU; i.e., admit any packet into the tunnel regardless of its size then make any necessary adaptations from within the tunnel. That is exactly what SEAL does: https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: Ray Soucy [mailto:r...@maine.edu] Sent: Monday, October 29, 2012 7:55 AM To: Templin, Fred L Cc: Dobbins, Roland; NANOG list Subject: Re: IP tunnel MTU The core issue here is TCP MSS. PMTUD is a dynamic process for adjusting MSS, but requires that ICMP be permitted to negotiate the connection. The realistic alternative, in a world that filters all ICMP traffic, is to manually rewrite the MSS. In IOS this can be achieved via ip tcp adjust-mss and on Linux-based systems, netfilter can be used to adjust MSS for example. Keep in mind that the MSS will be smaller than your MTU. Consider the following example: ip mtu 1480 ip tcp adjust-mss 1440 tunnel mode ipip IP packets have 20 bytes of overhead, leaving 1480 bytes for data. So for an IP-in-IP tunnel, you'd set your MTU of your tunnel interface to 1480. Subtract another 20 bytes for the tunneled IP header and 20 bytes (typical) for your TCP header and you're left with 1440 bytes for data in a TCP connection. So in this case we write the MSS as 1440. I use IP-in-IP as an example because it's simple. GRE tunnels can be a little more complex. While the GRE header is typically 4 bytes, it can grow up to 16 bytes depending on options used. So for a typical GRE tunnel (4 byte header), you would subtract 20 bytes for the IP header and 4 bytes for the GRE header from your base MTU of 1500. This would mean an MTU of 1476, and a TCP MMS of 1436. Keep in mind that a TCP header can be up to 60 bytes in length, so you may want to go higher than the typical 20 bytes for your MSS if you're seeing problems. On Tue, Oct 23, 2012 at 10:07 AM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Roland, -Original Message- From: Dobbins, Roland [mailto:rdobb...@arbor.net] Sent: Monday, October 22, 2012 6:49 PM To: NANOG list Subject: Re: IP tunnel MTU On Oct 23, 2012, at 5:24 AM, Templin, Fred L wrote: Since tunnels always reduce the effective MTU seen by data packets due to the encapsulation overhead, the only two ways to accommodate the tunnel MTU is either through the use of path MTU discovery or through fragmentation and reassembly. Actually, you can set your tunnel MTU manually. For example, the typical MTU folks set for a GRE tunnel is 1476. Yes; I was aware of this. But, what I want to get to is setting the tunnel MTU to infinity. This isn't a new issue; it's been around ever since tunneling technologies have been around, and tons have been written on this topic. Look at your various router/switch vendor Web sites, archives of this list and others, etc. Sure. I've written a fair amount about it too over the span of the last ten years. What is new is that there is now a solution near at hand. So, it's been known about, dealt with, and documented for a long time. In terms of doing something about it, the answer there is a) to allow the requisite ICMP for PMTU-D to work to/through any networks within your span of administrative control and b) That does you no good if there is some other network further beyond your span of administrative control that does not allow the ICMP PTBs through. And, studies have shown this to be the case in a non-trivial number of instances. b) adjusting your own tunnel MTUs to appropriate values based upon experimentation. Adjust it down to what? 1280? Then, if your tunnel with the adjusted MTU enters another tunnel with its own adjusted MTU there is an MTU underflow that might not get reported if the ICMP PTB messages are lost. An alternative is to use IP fragmentation, but recent studies have shown that more and more operators are unconditionally dropping IPv6 fragments and IPv4 fragmentation is not an option due to wrapping IDs at high data rates. Nested tunnels-within-tunnels occur in operational scenarios more and more, and adjusting the MTU for only one tunnel in the nesting does you no good if there are other tunnels that adjust their own MTUs. Enterprise endpoint networks are notorious for blocking *all* ICMP (as well
RE: IP tunnel MTU
I wish you luck in getting your host IP stacks to work properly without ICMP, especially as you deploy IPv6. From what I've heard, ICMPv6 is already being filtered, including PTBs. I have also heard that IPv6 fragments are also being dropped unconditionally along some paths. So, if neither ICMPv6 PTB nor IPv6 fragmentation works then the tunnel endpoints have to take matters into their own hands. That's where SEAL comes in. Thanks - Fred fred.l.temp...@boeing.com - Jared
RE: IP tunnel MTU
Hi Bill, Maybe something as simple as clearing the don't fragment flag and adding a TCP option to report receipt of a fragmented packet along with the fragment sizes back to the sender so he can adjust his mss to avoid fragmentation. That is in fact what SEAL is doing, but there is no guarantee that the size of the largest fragment is going to be an accurate reflection of the true path MTU. RFC1812 made sure of that when it more or less gave IPv4 routers permission to fragment packets pretty much any way they want. Thanks - Fred fred.l.temp...@boeing.com
RE: IP tunnel MTU
Hi Roland, -Original Message- From: Dobbins, Roland [mailto:rdobb...@arbor.net] Sent: Monday, October 22, 2012 6:49 PM To: NANOG list Subject: Re: IP tunnel MTU On Oct 23, 2012, at 5:24 AM, Templin, Fred L wrote: Since tunnels always reduce the effective MTU seen by data packets due to the encapsulation overhead, the only two ways to accommodate the tunnel MTU is either through the use of path MTU discovery or through fragmentation and reassembly. Actually, you can set your tunnel MTU manually. For example, the typical MTU folks set for a GRE tunnel is 1476. Yes; I was aware of this. But, what I want to get to is setting the tunnel MTU to infinity. This isn't a new issue; it's been around ever since tunneling technologies have been around, and tons have been written on this topic. Look at your various router/switch vendor Web sites, archives of this list and others, etc. Sure. I've written a fair amount about it too over the span of the last ten years. What is new is that there is now a solution near at hand. So, it's been known about, dealt with, and documented for a long time. In terms of doing something about it, the answer there is a) to allow the requisite ICMP for PMTU-D to work to/through any networks within your span of administrative control and b) That does you no good if there is some other network further beyond your span of administrative control that does not allow the ICMP PTBs through. And, studies have shown this to be the case in a non-trivial number of instances. b) adjusting your own tunnel MTUs to appropriate values based upon experimentation. Adjust it down to what? 1280? Then, if your tunnel with the adjusted MTU enters another tunnel with its own adjusted MTU there is an MTU underflow that might not get reported if the ICMP PTB messages are lost. An alternative is to use IP fragmentation, but recent studies have shown that more and more operators are unconditionally dropping IPv6 fragments and IPv4 fragmentation is not an option due to wrapping IDs at high data rates. Nested tunnels-within-tunnels occur in operational scenarios more and more, and adjusting the MTU for only one tunnel in the nesting does you no good if there are other tunnels that adjust their own MTUs. Enterprise endpoint networks are notorious for blocking *all* ICMP (as well as TCP/53 DNS) at their edges due to 'security' misinformation propagated by Confused Information Systems Security Professionals and their ilk. Be sure that your own network policies aren't part of the problem affecting your userbase, as well as anyone else with a need to communicate with properties on your network via tunnels. Again, all an operator can control is that which is within their own administrative domain. That does no good for ICMPs that are lost beyond their administrative domain. Thanks - Fred fred.l.temp...@boeing.com --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
RE: IRON vs. BGP (was Re: BGPttH. Neustar can do it, why can't we?)
I realize that this is reaching way back, but you may want to have a look at the latest version of IRON: http://www.ietf.org/id/draft-templin-ironbis-12.txt IRON manages the internal routing systems for large virtual service provider networks. It deals with deaggregation and churn due to mobility internally, and does not expose the deaggregation and churn to the interdomain routing system. IRON is therefore an intradomain routing overlay network system, and can be used in conjunction with any interdomain routing system - including BGP and LISP. Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: Wes Felter [mailto:w...@felter.org] Sent: Tuesday, August 07, 2012 10:51 AM To: nanog@nanog.org Subject: IRON vs. BGP (was Re: BGPttH. Neustar can do it, why can't we?) On 8/6/12 8:04 PM, Owen DeLong wrote: The goal here was to make this as simple and cost-effective as the NAT- based IPv4 solution currently in common use. There's no reason it can't be exactly that. It does provide advantages over the NAT-based solution (sessions can survive failover). What do people think about Fred Templin's IRON multihomed tunneling approach (or LISP, I guess it can do it)? IRON should give you multihoming with stable IPv4 and IPv6 PA prefixes, even for incoming traffic. It's less reliable than BGP in theory since you'd be virtually single-homed to your IRON provider but that might be a worthwhile tradeoff since staying up is pretty much their purpose in life. You'd have to pay a third provider to terminate your tunnels, but that might be cheaper than paying an extra BGP tax to both of your physical providers. IRON appears to require much less configuration than BGP and it can also provide IPv6 over v4-only providers (good luck finding *two* broadband providers in the same location that provide IPv6 and BGP). -- Wes Felter IBM Research - Austin
IP tunnel MTU
Hello, Several months ago, there was discussion on the list regarding IP tunnel maximum transmission unit (MTU). Since that time, it has been brought to my attention by members of my company's network operations staff that tunnel MTU is a very real problem they need to cope with on a daily basis - especially with the growing need to depend on both tunnels and tunnels-within-tunnels to track mobile devices. Since tunnels always reduce the effective MTU seen by data packets due to the encapsulation overhead, the only two ways to accommodate the tunnel MTU is either through the use of path MTU discovery or through fragmentation and reassembly. Unfortunately, both are known to be problematic in a non-trivial number of cases. The discussions on NANOG from back in the June timeframe resulted in Operational Issues with Tunnel Maximum transmission Unit: https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ I would like to ask this group to now give this document a look and post your comments/thoughts/experiences. For example, has the tunnel MTU problem crept into daily operational considerations to the point that we should now at least be documenting it and preferably trying to do something about it? From talking to our staff, I believe the answer is yes but it would be good to have confirmation from others. Thanks in advance for your thoughts, Fred fred.l.temp...@boeing.com
RE: IPv6 day and tunnels
-Original Message- From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp] Sent: Tuesday, June 19, 2012 6:10 AM To: Templin, Fred L Cc: Owen DeLong; nanog@nanog.org Subject: Re: IPv6 day and tunnels Templin, Fred L wrote: Not necessarily, as IPv4 can take care of itself and IPv6 is hopeless. IPv4 can take care of it how - with broken PMTUD or As you know, RFC1191 style PMTUD is broken both for IPv4 and IPv6. Unfortunately, there is evidence that this is the case. with broken fragmentation/reassembly? Fragmentation is fine, especially with RFC4821 style PMTUD, even though RFC4821 tries to make people believe it is broken, because accidental ID match is negligibly rare even with IPv4. The 16-bit IP ID, plus the 120sec MSL, limits the rate for fragmentable packets to 6.4Mbps for a 1500 MTU. Exceeding this rate leads to the possibility of fragment misassociations (RFC4963). This would not be a problem if there were some stronger integrity check than just the Internet checksum, but with the current system we don't have that. And, you won't get any argument from me that IPv6 has been stuck for years for good reasons - but MTU failures can soon be taken off the list. Now, it's time for you to return v6-ops to defend your draft from Joe Touch. Note that there is no point for IPv6 forbid fragmentation by intermediate routers. I wasn't there when the decision was made, but based on my findings I don't disagree. Fred fred.l.temp...@boeing.com Masataka Ohta
RE: IPv6 day and tunnels
-Original Message- From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp] Sent: Tuesday, June 12, 2012 4:47 AM To: Templin, Fred L Cc: Owen DeLong; nanog@nanog.org Subject: Re: IPv6 day and tunnels Templin, Fred L wrote: If you wish, you can also consider Alternate 3 for 9kB: 72us@1Gbps, 7.2us@10Gbps, .72us@100Gbps, .072us@1Tbps. So? Have you learned enough about Moore's law that, at 10Gbps era, 72us of delay is often significant? I frankly haven't thought about it any further. You say 1280+ belongs in ITU, and I say 1280- belongs in ATM. Larger packets means fewer interrupts and fewer packets in flight, which is good Moore's law or no. Accommodation of MTU diversity is what matters. Fred fred.l.temp...@boeing.com Masataka Ohta
RE: IPv6 day and tunnels
As I already said, 9KB is fine for me. Then you will agree that accommodation of MTU diversity is a MUST (my point). Fred
RE: IPv6 day and tunnels
-Original Message- From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp] Sent: Tuesday, June 12, 2012 2:12 PM To: Templin, Fred L Cc: Owen DeLong; nanog@nanog.org Subject: Re: IPv6 day and tunnels Templin, Fred L wrote: As I already said, 9KB is fine for me. Then you will agree that accommodation of MTU diversity is a MUST (my point). Not necessarily, as IPv4 can take care of itself and IPv6 is hopeless. IPv4 can take care of it how - with broken PMTUD or with broken fragmentation/reassembly? And, you won't get any argument from me that IPv6 has been stuck for years for good reasons - but MTU failures can soon be taken off the list. Fred fred.l.temp...@boeing.com
RE: IPv6 day and tunnels
Here is Matt's full table and descriptive text: Note that there is no specific reason to require any particular MTU at any particular rate. As a general principle, we prefer declining packet times (and declining worst case jitter) as you go to higher rates. Actual Vision Alternate 1 Alternate 2 Rate MTU TimeMTU Time MTU TimeMTU Time 10 Mb/s 1.5kB 1200uS 100 Mb/s 1.5kB 120uS12kB 960uS9kB 720uS 4.3kB 433uS 1 Gb/s 1.5kB12uS96kB 768uS 64kB 512uS9kB72uS 10 Gb/s 1.5kB 1.2uS 750kB 600uS 150kB 120uS 64kB 51.2uS 100 Gb/s6MB 480uS 1.5MB 120uS 64kB 5.12uS 1 Tb/s 50MB 400uS 15MB 120uS 64kB 0.512uS The above numbers are very speculative about what MTUs might make sense in the market. We keep updating them as we learn more about how MTU affects the balance between switching costs and end-system costs vs. end-to-end performance. If you wish, you can also consider Alternate 3 for 9kB: 72us@1Gbps, 7.2us@10Gbps, .72us@100Gbps, .072us@1Tbps. Fred fred.l.temp...@boeing.com
RE: IPv6 day and tunnels
A few more words on MTU. What we are after is accommodation of MTU diversity - not any one specific size. Practical limit is (2^32 - 1) for IPv6, but we expect smaller sizes for the near term. Operators know how to configure MTUs appropriate for their links. 1280 is too small, and turns the IPv6 Internet into ATM. In order to support MTU diversity, PMTUD must be made to work. This means working to eliminate all network blockage of ICMPv6 PTBs, while at the same time provisioning hosts and tunnels with mechanisms that work even if no PTBs are delivered. For hosts, that requires RFC4821. For tunnels, that requires fragmentation. From an earlier message: 9000B may still be acceptable. True, but what we need is not any one fixed Internet cell size but rather full support for MTU diversity. Fred fred.l.temp...@boeing.com
RE: IPv6 day and tunnels
A quick comment on probes. Making the tunnel ingress probe is tempting but fraught with difficulties; believe me, I have tried. So, having the tunnel ingress fragment when necessary in conjunction with the original source probing is the way forward, and we should advocate both approaches. RFC4821 specifies how the original source can probe with or without tunnels in the path. It does not have any RTT delays, because it starts small and then tries for larger sizes in parallel with getting the valuable data through without loss. Thanks - Fred fred.l.temp...@boeing.com
RE: IPv6 day and tunnels
-Original Message- From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp] Sent: Monday, June 04, 2012 4:40 PM To: Templin, Fred L; nanog@nanog.org Subject: Re: IPv6 day and tunnels Templin, Fred L wrote: I'm not sure that a randomly-chosen skip value is even necessary. It is not necessary, because, for ID uniqueness fundamentalists, single event is bad enough and for most operators, slight possibility is acceptable. Outer fragmentation cooks the tunnel egresses at high data rates. Have egresses with proper performance. That's the proper operation. How many core routers would be happy to reassemble at line rates without a forklift upgrade and/or strong administrative tuning? End systems are expected and required to reassemble on their own behalf. That is not a proper operation of tunnels. Why not? Thus, don't insist on having unique IDs so much. Non-overlapping fragments are disallowed for IPv6, but I think are still allowed for IPv4. So, IPv4 still needs the unique IDs by virtue of rate limiting. Even though there is no well defined value of MSL? MSL is well defined. For TCP, it is defined in RFC793. For IPv4 reassembly, it is defined in RFC1122. For IPv6 reassembly, it is defined in RFC2460. I'm talking about not protocol recommendation but proper operation. I don't see any operational guidance recommending the tunnel ingress to configure an MRU of 1520 or larger. I'm talking about not operation guidance but proper operation. The tunnel ingress cannot count on administrative tuning on the egress - all it can count on is reassembly of 1500 or smaller and it can't count on good performance even at those levels. Proper operators can, without any guidance, perform proper operation. No amount of proper operation can fix a platform that does not have adequate performance. And, there is no way for the tunnel ingress to tell what, if any, mitigations have been applied at the egress. Thanks - Fred fred.l.temp...@boeing.com Masataka Ohta
RE: IPv6 day and tunnels
The proper solution is to have a field in IPv7 header to measure PMTU. It can be a 8 bit field, if fragment granularity is 256B. We tried that for IPv4 and it didn't work very well [RFC1063]. You are welcome to try again in IPv7 when we have a green field. Fred fred.l.temp...@boeing.com
RE: IPv6 day and tunnels
-Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Tuesday, June 05, 2012 7:55 AM To: Templin, Fred L Cc: Owen DeLong; Jimmy Hess; nanog@nanog.org Subject: Re: IPv6 day and tunnels In message E1829B60731D1740BB7A0626B4FAF0A65D374A86CB@XCH-NW- 01V.nw.nos.boeing .com, Templin, Fred L writes: A quick comment on probes. Making the tunnel ingress probe is tempting but fraught with difficulties; believe me, I have tried. So, having the tunnel ingress fragment when necessary in conjunction with the original source probing is the way forward, and we should advocate both approaches. RFC4821 specifies how the original source can probe with or without tunnels in the path. It does not have any RTT delays, because it starts small and then tries for larger sizes in parallel with getting the valuable data through without loss. It's useful for TCP but it is not a general solution. PTB should not be being blocked and for some applications one should just force minimum mtu use. Any packetization layer that is capable of getting duplicate ACKs from the peer can do it. Plus, support for just TCP is all that is needed for the vast majority of end systems at the current time. Thanks - Fred fred.l.temp...@boeing.com Thanks - Fred fred.l.temp...@boeing.com -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
RE: IPv6 day and tunnels
-Original Message- From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp] Sent: Tuesday, June 05, 2012 9:37 AM To: Templin, Fred L Cc: nanog@nanog.org Subject: Re: IPv6 day and tunnels Templin, Fred L wrote: Have egresses with proper performance. That's the proper operation. How many core routers would be happy to reassemble at line rates without a forklift upgrade and/or strong administrative tuning? You don't have to do it with core routers. Tunnel endpoints can be located either nearer the edges or nearer the middle. Tunnel endpoints that are located nearer the edges might be able to do reassembly at nominal data rates, but there is no assurance of a maximum MRU greater than 1500 (which is too small to reassemble a 1500+20 packet). Tunnel endpoints that are located nearer the middle can be swamped trying to keep up with reassembly at high data rates - again, with no MRU assurances. End systems are expected and required to reassemble on their own behalf. That is not a proper operation of tunnels. Why not? Lack of transparency. Huh? Even though there is no well defined value of MSL? MSL is well defined. For TCP, it is defined in RFC793. For IPv4 reassembly, it is defined in RFC1122. For IPv6 reassembly, it is defined in RFC2460. As you can see, they are different values. RFC793 sets MSL to 120 seconds. RFC1122 uses MSL as the upper bound for reassembly buffer timeouts. IPv6 doesn't reference MSL but sets reassembly buffer timeouts to 60 seconds. Personally, I can't imagine a reassembly that takes even as long as 30seconds being of any use to the final destination even if it were to finally complete. But, if we set 60 sec as the reassembly timeout value for IPv* I'm sure we'd be OK. I'm talking about not operation guidance but proper operation. The tunnel ingress cannot count on administrative tuning on the egress I'm afraid you don't understand tunnel operation at all. I don't? Are you sure? No amount of proper operation can fix a platform that does not have adequate performance. Choosing a proper platform is a part of proper operation. This is getting tiresome. Fred fred.l.tem...@boeing.com Masataka Ohta
RE: IPv6 day and tunnels
-Original Message- From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp] Sent: Tuesday, June 05, 2012 11:36 AM To: Templin, Fred L; nanog@nanog.org Subject: Re: IPv6 day and tunnels Templin, Fred L wrote: You don't have to do it with core routers. Tunnel endpoints can be located either nearer the edges or nearer the middle. Tunnel endpoints that are located nearer the edges might be able to do reassembly at nominal data rates, but there is no assurance of a maximum MRU greater than 1500 (which is too small to reassemble a 1500+20 packet). Tunnel endpoints that are located nearer the middle can be swamped trying to keep up with reassembly at high data rates - again, with no MRU assurances. As operators know outer fragmentation is used to carry inner 1500B packets, the proper operation is to have equipments with large enough MRU. As core routers may be good at fragmentation but not particularly good at reassembly, operators do not have to insist on using core routers. I am making a general statement that applies to all tunnels everywhere. For those, specs say that all that is required for MRU is 1500 and not 1500+20. *Unless there is some explicit pre-arrangement between the tunnel endpoints*, the ingress has no way of knowing whether the egress can do better than 1500 outer packet (meaning 1480 inner packet). That is certainly the case for point-to-multipoint automatic tunnels as many of these IPv6 transition technologies are. Fred fred.l.temp...@boeing.com I'm afraid you don't understand tunnel operation at all. I don't? Are you sure? See above. Masataka Ohta
RE: IPv6 day and tunnels
-Original Message- From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp] Sent: Tuesday, June 05, 2012 12:42 PM To: Templin, Fred L Cc: nanog@nanog.org Subject: Re: IPv6 day and tunnels Templin, Fred L wrote: I am making a general statement that applies to all tunnels everywhere. General statement? General statement for IPv6-in-IPv4 tunneling, yes. But inner fragmentation applies equally for *-in-* tunneling. Even though you assume tunnel MTU 1500B What I am after is a tunnel MTU of infinity. 1500 is the minimum packet size that MUST get through. 1501+ packets are admitted into the tunnel unconditionally in hopes that they MIGHT get through. and tunnel overhead 20B? The size 20 represents the size of the IPv4 encaps header. The size 40 would represent the size of an IPv6 encaps header. The size foo would represent the size of some other encapsulation overhead, e.g., for IPsec tunnels, IP/UDP tunnels, etc. So, let the size of the encaps header(s) be X, substitute X for 20 everywhere and you will see that the approach is fully generally applicable. For those, specs say that all that is required for MRU is 1500 and not 1500+20. That is a requirement for hosts with Ethernet interface, which is, by no means, general and has nothing to do with tunnels. RFC2460 says the MinMRU for IPv6 nodes is 1500. RFC1122 says that IPv4 hosts should reassemble as much as their connected interfaces (1500 for Ethernet). RFC1812 says the MinMRU for IPv4 routers is 576. For the general argument on tunnels, see, for example, RFC2473 Generic Packet Tunneling in IPv6, where there is no requirement of 1500. Note that the RFC uses outer fragmentation: (b) if the original IPv6 packet is equal or smaller than the IPv6 minimum link MTU, the tunnel entry-point node encapsulates the original packet, and subsequently fragments the resulting IPv6 tunnel packet into IPv6 fragments that do not exceed the Path MTU to the tunnel exit-point. Wow - that is an interesting quote out of context. The text you quoted is describing the limiting condition to make sure that 1280 and smaller get through even if the path MTU is deficient. In that case alone, outer fragmentation is needed. My document also allows for outer fragmentation on the inner fragments. But, like the RFC4213-derived IPv6 transition mechanisms treats outer fragmentation as an anomalous condition to be avoided if possible - not a steady state operational approach. See Section 3.2 of RFC4213. Thanks - Fred fred.l.temp...@boeing.com Masataka Ohta
RE: IPv6 day and tunnels
-Original Message- From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp] Sent: Tuesday, June 05, 2012 2:44 PM To: Templin, Fred L; nanog@nanog.org Subject: Re: IPv6 day and tunnels Templin, Fred L wrote: General statement for IPv6-in-IPv4 tunneling, yes. But inner fragmentation applies equally for *-in-* tunneling. Even though you assume tunnel MTU 1500B What I am after is a tunnel MTU of infinity. 1500 is the minimum packet size that MUST get through. 1501+ packets are admitted into the tunnel unconditionally in hopes that they MIGHT get through. Infinity? You can't carry 65516B in an IPv4 packet. I should qualify that by saying: 1) For tunnels over IPv4, let infinity equal (2^16 - 1) minus the length of the encapsulation headers 2) For tunnels over IPv6, let infinity equal (2^32 - 1) minus the length of the encapsulation headers My document also allows for outer fragmentation on the inner fragments. But, like the RFC4213-derived IPv6 transition mechanisms treats outer fragmentation as an anomalous condition to be avoided if possible - not a steady state operational approach. See Section 3.2 of RFC4213. Instead, see the last two lines in second last slide of: http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf It is a common condition. Are you interested in only supporting tinygrams? IMHO, go big or go home! Fred fred.l.temp...@boeing.com Masataka Ohta
RE: IPv6 day and tunnels
-Original Message- From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp] Sent: Tuesday, June 05, 2012 3:41 PM To: Templin, Fred L Cc: nanog@nanog.org Subject: Re: IPv6 day and tunnels Templin, Fred L wrote: Infinity? You can't carry 65516B in an IPv4 packet. 2) For tunnels over IPv6, let infinity equal (2^32 - 1) You can't carry a 65516B IPv6 packet in an IPv4 packet. No, but you can carry a ((2^32 - 1) - X) IPv6 packet in an IPv6 packet. Just insert a jumbogram extension header. Instead, see the last two lines in second last slide of: http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf It is a common condition. Are you interested in only supporting tinygrams? IMHO, go big or go home! Bigger packets makes it rather circuit switching than packet switching. The way to lose. Faster is the way to go. Why only fast when you can have both big *and* fast? See Matt's pages on raising the Internet MTU: http://staff.psc.edu/mathis/MTU/ Time on the wire is what matters, and on a 100Gbps wire you can push 6MB in 480usec. That seems more like packet switching latency rather than circuit switching latency. Fred fred.l.temp...@boeing.com Masataka Ohta
RE: IPv6 day and tunnels
Hi, There was quite a bit discussion on IPv6 PMTUD on the v6ops list within the past couple of weeks. Studies have shown that PTB messages can be dropped due to filtering even for ICMPv6. There was also concern for the one (or more) RTTs required for PMTUD to work, and for dealing with bogus PTB messages. The concerns were explicitly linked to IPv6 tunnels, so I drafted a proposed solution: https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ In this proposal the tunnel ingress performs the following treatment of packets of various sizes: 1) For IPv6 packets no larger than 1280, admit the packet into the tunnel w/o fragmentation. Assumption is that all IPv6 links have to support a 1280 MinMTU, so the packet will get through. 2) For IPv6 packets larger than 1500, admit the packet into the tunnel w/o fragmentation. Assumption is that the sender would only send a 1501+ packet if it has some way of policing the PMTU on its own, e.g. through the use of RC4821. 3) For IPv6 packets between 1281-1500, break the packet into two (roughly) equal-sized pieces and admit each piece into the tunnel. (In other words, intentionally violate the IPv6 deprecation of router fragmentation.) Assumption is that the final destination can reassemble at least 1500, and that the 32-bit Identification value inserted by the tunnel provides sufficient assurance against reassembly mis-associations. I presume no one here would object to clauses 1) and 2). Clause 3) is obviously a bit more controversial - but, what harm would it cause from an operational standpoint? Thanks - Fred fred.l.temp...@boeing.com
RE: IPv6 day and tunnels
Hi Brett, -Original Message- From: Brett Frankenberger [mailto:rbf+na...@panix.com] Sent: Monday, June 04, 2012 9:35 AM To: Templin, Fred L Cc: nanog@nanog.org Subject: Re: IPv6 day and tunnels On Mon, Jun 04, 2012 at 07:39:58AM -0700, Templin, Fred L wrote: https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ 3) For IPv6 packets between 1281-1500, break the packet into two (roughly) equal-sized pieces and admit each piece into the tunnel. (In other words, intentionally violate the IPv6 deprecation of router fragmentation.) Assumption is that the final destination can reassemble at least 1500, and that the 32-bit Identification value inserted by the tunnel provides sufficient assurance against reassembly mis-associations. Fragmenting the outer packet, rather than the inner packet, gets around the problem of router fragmentation of packets. The outer packet is a new packet and there's nothing wrong with the originator of that packet fragmenting it. Of course, that forces reassembly on the other tunnel endpoint, rather than on the ultimate end system, which might be problematic with some endpoints and traffic volumes. There are a number of issues with fragmenting the outer packet. First, as you say, fragmenting the outer packet requires the tunnel egress to perform reassembly. This may be difficult for tunnel egresses that are configured on core routers. Also, when IPv4 is used as the outer encapsulation layer, the 16-bit ID field can result in reassembly errors at high data rates [RFC4963]. Additionally, encapsulating a 1500 inner packet in an outer IP header results in a 1500+ outer packet - and the ingress has no way of knowing whether the egress is capable of reassembling larger than 1500. (With IPv4 in IPv4 tunnels, this is what I've always done. 1500 byte MTU on the tunnel, fragment the outer packet, let the other end of the tunnel do the reassembly. Not providing 1500 byte end-to-end (at least with in the network I control) for IPv4 has proven to consume lots of troubleshooting time; fragmenting the inner packet doesn't work unless you ignore the DF bit that is typically set by TCP endpoints who want to do PMTU discovery.) Ignoring the (explicit) DF bit for IPv4 and ignoring the (implicit) DF bit for IPv6 is what I am suggesting. Thanks - Fred fred.l.temp...@boeing.com I presume no one here would object to clauses 1) and 2). Clause 3) is obviously a bit more controversial - but, what harm would it cause from an operational standpoint? -- Brett
RE: IPv6 day and tunnels
-Original Message- From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp] Sent: Monday, June 04, 2012 12:06 PM To: nanog@nanog.org Subject: Re: IPv6 day and tunnels Templin, Fred L wrote: Also, when IPv4 is used as the outer encapsulation layer, the 16-bit ID field can result in reassembly errors at high data rates [RFC4963]. As your proposal, too, gives up to have unique IDs, does that matter? This is taken care of by rate limiting at the tunnel ingress. For IPv4-in-(foo) tunnels, rate limit is 11Mbps which may be a bit limiting for some applications. For IPv6-in-(foo) tunnels, rate limit is 733Gbps which should be acceptable for most applications. Note that, with your draft, a route change between two tunnels with same C may cause block corruption. There are several built-in mitigations for this. First, the tunnel ingress does not assign Identification values sequentially but rather skips around to avoid synchronizing with some other node that is sending fragments to the same (src,dst) pair. Secondly, the ingress chooses random fragment sizes for the A and B portions of the packet so that the A portion of packet 1 does not match up properly with the B portion of packet 2 and hence will be dropped. Finally, even if the A portion of packet 1 somehow matches up with the B portion of packet 2 the Internet checksum provides an additional line of defense. Additionally, encapsulating a 1500 inner packet in an outer IP header results in a 1500+ outer packet - and the ingress has no way of knowing whether the egress is capable of reassembling larger than 1500. Operators are responsible to have tunnel end points with sufficient capabilities. It is recommended that IPv4 nodes be able to reassemble as much as their connected interface MTUs. In the vast majority of cases that means that the nodes should be able to reassemble 1500. But, there is no assurance of anything more! Thanks - Fred fred.l.temp...@boeing.com (With IPv4 in IPv4 tunnels, this is what I've always done. 1500 byte MTU on the tunnel, fragment the outer packet, let the other end of the tunnel do the reassembly. Not providing 1500 byte end-to-end (at least with in the network I control) for IPv4 has proven to consume lots of troubleshooting time; fragmenting the inner packet doesn't work unless you ignore the DF bit that is typically set by TCP endpoints who want to do PMTU discovery.) Ignoring the (explicit) DF bit for IPv4 and ignoring the (implicit) DF bit for IPv6 is what I am suggesting. Thanks - Fred fred.l.temp...@boeing.com I presume no one here would object to clauses 1) and 2). Clause 3) is obviously a bit more controversial - but, what harm would it cause from an operational standpoint? -- Brett
RE: IPv6 day and tunnels
-Original Message- From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp] Sent: Monday, June 04, 2012 1:08 PM To: Templin, Fred L; nanog@nanog.org Subject: Re: IPv6 day and tunnels Templin, Fred L wrote: As your proposal, too, gives up to have unique IDs, does that matter? This is taken care of by rate limiting at the tunnel No, I'm talking about: Note that a possible conflict exists when IP fragmentation has already been performed by a source host before the fragments arrive at the tunnel ingress. Note that, with your draft, a route change between two tunnels with same C may cause block corruption. There are several built-in mitigations for this. First, the tunnel ingress does not assign Identification values sequentially but rather skips around to avoid synchronizing with some other node that is sending fragments to the same I'm talking about two tunnels with same skip value. There are several factors to consider. First, each tunnel ingress chooses its initial Identification value (or values) randomly and independent of all other tunnel ingresses. Secondly, the packet arrival rates at the various tunnel ingresses are completely independent and in no way correlated. So, while an occasional reassembly collision is possible the 32-bit Identification value would make it extremely rare. And the variability of packet arrivals between the tunnel endpoints would make it such that a string of consecutive collisions would never happen. So, I'm not sure that a randomly-chosen skip value is even necessary. Secondly, the ingress chooses random fragment sizes for the A and B portions of the packet so that the A portion of packet 1 does not match up properly with the B portion of packet 2 and hence will be dropped. You can do so with outer fragment, too. Moreover, it does not have to be random but regular, which effectively extend ID length. Outer fragmentation cooks the tunnel egresses at high data rates. End systems are expected and required to reassemble on their own behalf. Finally, even if the A portion of packet 1 somehow matches up with the B portion of packet 2 the Internet checksum provides an additional line of defense. Thus, don't insist on having unique IDs so much. Non-overlapping fragments are disallowed for IPv6, but I think are still allowed for IPv4. So, IPv4 still needs the unique IDs by virtue of rate limiting. It is recommended that IPv4 nodes be able to reassemble as much as their connected interface MTUs. In the vast majority of cases that means that the nodes should be able to reassemble 1500. But, there is no assurance of anything more! I'm talking about not protocol recommendation but proper operation. I don't see any operational guidance recommending the tunnel ingress to configure an MRU of 1520 or larger. Thanks - Fred fred.l.temp...@boeing.com Masataka Ohta
RE: IPv6 day and tunnels
I just want to know if we can expect IPv6 to devolve into 1280 standard mtu and at what gigabit rates. The vast majority of hosts will still expect 1500, so we need to find a way to get them at least that much. Fred fred.l.temp...@boeing.com
RE: IPv6 day and tunnels
I just want to know if we can expect IPv6 to devolve into 1280 standard mtu and at what gigabit rates. 1280 is the minimum IPv6 MTU. If people allow pMTU to work, aka accept and process ICMPv6 Packet-Too-Big messages everything will just work. This whole thread is about people who cannot be bothered to know what they are filtering and that they might just randomly block PtB as they are doing with IPv4 today. Yes, in that case their network breaks if the packets are suddenly larger than a link somewhere else, that is the same as in IPv4 ;) But, it is not necessarily the person that filters the PTBs that suffers the breakage. It is the original source that may be many IP hops further down the line, who would have no way of knowing that the filtering is even happening. Thanks - Fred fred.l.temp...@boeing.com Greets, Jeroen
RE: IPv6 day and tunnels
PMTU-d probing, as recently standardizes seems a more likely solution. Having CPE capable of TCP mss adjustment on v6 is another one. Being able to fragment when you want to is another good one as well. I'll take a) and c), but don't care so much for b). About fragmenting, any tunnel ingress (VPNs included) can do inner fragmentation today independently of all other ingresses and with no changes necessary on the egress. It's just that they need to take precautions to avoid messing up the final destination's reassembly buffers. Fred fred.l.temp...@boeing.com
RE: IPv6 day and tunnels
Hi Owen, I am 100% with you on wanting to see an end to filtering of ICMPv6 PTBs. But, tunnels can take matters into their own hands today to make sure that 1500 and smaller gets through no matter if PTBs are delivered or not. There doesn't really even need to be a spec as long as each tunnel takes the necessary precautions to avoid messing up the final destination. The next thing is to convince the hosts to implement RFC4821... Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: Owen DeLong [mailto:o...@delong.com] Sent: Monday, June 04, 2012 4:00 PM To: Joe Maimon Cc: nanog@nanog.org Subject: Re: IPv6 day and tunnels On Jun 4, 2012, at 3:34 PM, Joe Maimon wrote: Owen DeLong wrote: Fail. What, exactly are you saying is a failure? The single word here even in context is very ambiguous. The failure is that even now, when tunnels are critical to transition, a proper solution that improves on the IPv4 problems does not exist A proper solution does exist... Stop blocking PTB messages. That's the proper solution. It was the proper solution in IPv4 and it is the proper solution in IPv6. And if tunnels do become less prevalent there will be even less impetus than now to make things work better. True, perhaps, but, I don't buy that tunnels are the only sub-1500 octet MTU out there, so, I think your premise here is somewhat flawed. Today, most people cant even get IPv6 without tunnels. Anyone can get IPv6 without a tunnel if they are willing to bring a circuit to the right place. Today most people cant even get IPv6 without tunnels, or without paying excessively more for their internet connection, or without having their pool of vendors shrink dramatically, sometimes to the point of none. It never shrinks to none, but, yes, the cost can go up dramatically. You can, generally, get a circuit to somewhere that HE has presence from almost anywhere in the world if you are willing to pay for it. Any excessive costs would be what the circuit vendor charges. HE sells transit pretty cheap and everywhere we sell, it's dual-stack native. Sure, we wish we could magically have POPs everywhere and serve every customer with a short local loop. Unfortunately, that's not economically viable at this time, so, we build out where we can when there is sufficient demand to cover our costs. Pretty much like any other provider, I would imagine. Difference is, we've been building everything native dual stack for years. IPv6 is what we do. We're also pretty good at IPv4, so we deliver legacy connectivity to those that want it as well. Breaking PMTU-D is bad. People should stop doing so. Blocking PTB messages is bad in IPv4 and worse in IPv6. It has always been bad and people have not stopped doing it. And intentional blocking is not the sole cause of pmtud breaking. I guess that depends on how you define the term intentional. I don't care whether it was the administrators intent, or a default intentionally placed there by the firewall vendor or what, it was someone's intent, therefore, yes, it is intentional. If you can cite an actual case of accidental dropping of PTB messages that was not the result of SOMEONE's intent, then, OK. However, at least on IPv6, I believe that intentional blocking (regardless of whose intent) is, in fact, the only source of PMTUD breakage at this point. In IPv4, there is some breakage in older software that didn't do PMTUD right even if it received the correct packets, but, that's not relevant to IPv6. If you have a useful alternative solution to propose, put it forth and let's discuss the merits. PMTU-d probing, as recently standardizes seems a more likely solution. Having CPE capable of TCP mss adjustment on v6 is another one. Being able to fragment when you want to is another good one as well. Fragments are horrible from a security perspective and worse from a network processing perspective. Having a way to signal path MTU is much better. Probing is fine, but, it's not a complete solution and doesn't completely compensate for the lack of PTB message transparency. I hope not. I hope that IPv6 will cause people to actually re-evaluate their behavior WRT PMTU-D and correct the actual problem. Working PMTU-D allows not only 1500, but also 1280, and 9000 and9000 octet datagrams to be possible and segments that support1500 work almost as well as segments that support jumbo frames. Where jumbo frames offer an end-to-end advantage, that advantage can be realized. Where there is a segment with a 1280 MTU, that can also work with a relatively small performance penalty. Where PMTU-D is broken, nothing works unless the MTU end-to-end happens to coincide with the smallest MTU. For links that carry tunnels and clear traffic, life gets interesting if one of them is the one with the smallest MTU regardless of the MTU value chosen. Owen
