RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Brian, -Original Message- From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] Sent: Friday, October 11, 2013 3:42 PM To: Templin, Fred L Cc: Fernando Gont; Ray Hunter; 6man Mailing List; ietf@ietf.org Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard Fred, On 12/10/2013 08:56, Templin, Fred L wrote: Hi Brian, -Original Message- From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] Sent: Friday, October 11, 2013 12:50 PM To: Fernando Gont Cc: Templin, Fred L; Ray Hunter; 6man Mailing List; ietf@ietf.org Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain- 08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard On 12/10/2013 06:04, Fernando Gont wrote: ... P.S.: Reegarding enforcing a limit on the length of the header chain, I must say I symphatize with that (for instance, check the last individual version of this I-D, and you'll find exactly that). But the wg didn't want that in -- and I did raise the issue a few times. So what we have is what the 6man wg had consensus on. I agree that this was the WG consensus after considerable discussion, which included Fred, so I'm not sure why we're discussing it again during IETF LC. Technical matters should be discussed as they come to light; not dismissed because of some real or perceived deadline. That was what got us the 1280 MTU in the first place. Quoting from Steve Deering: We would like to get this issue settled as soon as possible, since this is the only thing holding up the publication of the updated Proposed Standard IPv6 spec (the version we expect to advance to Draft Standard), so let's see if we can come to a decision before the ID deadline at the end of next week (hoping there isn't any conflict between thoughtful analysis and let's decide quickly :-). So, it wasn't necessarily the case that 1280 was a product of thoughtful analysis so much as the fact that **they were rushing to get a spec out the door**. So now, 16 years later, we get to put it back on the 6man charter milestone list. We could have that discussion in 6man, sure, but I don't believe that it's relevant to the question of whether draft-ietf-6man-oversized-header- chain is ready. If it messes up tunnels, then it's not ready. This draft mitigates a known problem in terms of the current IPv6 standards. If that problem is also mitigated by a measure that does not mess up tunnels, then wouldn't that be worth considering before finalizing this publication. Thanks - Fred fred.l.temp...@boeing.com Brian
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Ron, -Original Message- From: Ronald Bonica [mailto:rbon...@juniper.net] Sent: Saturday, October 12, 2013 7:07 PM To: Brian E Carpenter; Templin, Fred L Cc: Fernando Gont; 6man Mailing List; ietf@ietf.org; Ray Hunter Subject: RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard +1 Is there a way to decouple this discussion from draft-ietf-6man- oversized-header-chain? I would be glad to discuss it in the context of a separate draft. I don't know if there is a way to decouple it. I believe I have shown a way to not mess up tunnels while at the same time not messing up your draft. That should be a win-win. In what way would imposing a 1K limit on the IPv6 header chain not satisfy the general case? Thanks - Fred fred.l.temp...@boeing.com Ron So, it wasn't necessarily the case that 1280 was a product of thoughtful analysis so much as the fact that **they were rushing to get a spec out the door**. So now, 16 years later, we get to put it back on the 6man charter milestone list. We could have that discussion in 6man, sure, but I don't believe that it's relevant to the question of whether draft-ietf-6man-oversized- header-chain is ready. This draft mitigates a known problem in terms of the current IPv6 standards.
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Brian, -Original Message- From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] Sent: Monday, October 14, 2013 12:34 PM To: Templin, Fred L Cc: Fernando Gont; Ray Hunter; 6man Mailing List; ietf@ietf.org Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard Fred, On 15/10/2013 06:38, Templin, Fred L wrote: ... We could have that discussion in 6man, sure, but I don't believe that it's relevant to the question of whether draft-ietf-6man-oversized- header- chain is ready. If it messes up tunnels, then it's not ready. That doesn't follow. See below. This draft mitigates a known problem in terms of the current IPv6 standards. If that problem is also mitigated by a measure that does not mess up tunnels, then wouldn't that be worth considering before finalizing this publication. The draft mitigates a known problem with communication paths that do not include nested tunnels requiring nested fragmentation, where the nested tunnel has to deal with an MTU 1280 *and* where the nested tunnel goes through a firewall that wants to analyse the complete header chain of the innermost packet. But tunnels - and tunnels within tunnels - need to be considered as part of the architecture. I have visibility into the network operations of a major multi-national corporation, and I can tell you that I see tunnels within tunnels in operational practice today. I also have visibility into civil aviation and DoD networks, and I see an emerging trend for mobile networks. Consider a mobile network B that comes onto a link offered by mobile network A. Then, mobile network C comes onto a link offered by B. Then, etc. Then, the next thing you know, it's turtles all the way down. Fragmentation is the tool that enables endless recursion. Or, at least, recursion up to some defined limit. At least for the first several levels of recursion, middleboxes should be able to see all host-inserted headers within the first fragment. Thanks - Fred fred.l.temp...@boeing.com No, I don't think it's worth considering that case before specifying this mitigation. Brian
RE: RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Ray, -Original Message- From: Ray Hunter [mailto:v6...@globis.net] Sent: Friday, October 11, 2013 12:49 AM To: Templin, Fred L; brian.e.carpen...@gmail.com Cc: ietf@ietf.org; 6man Mailing List Subject: Re: RE: Last Call: draft-ietf-6man-oversized-header-chain- 08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard Templin, Fred L wrote: Hi Brian, Responding in a slightly re-arranged order: The problem is that you are asserting that middleboxes that a tunnel passes through are expected to examine the complete header chain of the encapsulated packet even if the encapsulated packet is a fragment. Yes, but change are expected to to should be able to. I personally don't see this going anywhere. Unless you specifically define what is a tunnel and you specifically define a maximum depth of nesting. The term Upper-Layer Protocol (ULP) is also itself a vague term IMHO since the value of the IPv6 next header is taken from the same code space as the ULP header values, and there's no specific marker or header length field in IPv6 that explicitly marks a point as This is the end of the IPv6 header chain in all circumstances: stop header parsing here. Ok, there's a bunch of current code-points that are today considered as valid ULP's or next-header values, but that is neither time invariant nor exhaustive, so solving this issue via a registry means there will always be middlebox code in the wild that lags any updates. These middleboxes won't be able to differentiate between an unknown ULP, and an unknown IPv6 next-header. That potentially makes a default pass or drop decision awkward. If it's so important to be able to differentiate between what is an ULP and what is a next header, and we can't reliably do that today, maybe that's a fundamental flaw in IPv6 that should be addressed. I think that's an unreasonable expectation. A reasonable expectation is that middleboxes should identify the encapsulated packet as a payload that they cannot analyse, and let it go (unless they have a policy setting to drop tunnelled packets, which is a different discussion). But why? If headers beyond the first IPv6 encapsulation header are available in the clear, the middlebox should be able to parse them if it wants to. Wireshark already does exactly that - it keeps on parsing beyond the first encapsulation header up to and including the true ULP header. And, if Wireshark can do it, so can any other middlebox that believes security would be improved by continuing to parse the entire chain - whether or not there is a standard saying it must not do so. Because it leaves open the possibility for an attacker to apply the obfuscation we seek to limit. Parsing the additional headers beyond the first encapsulation header provides defense-in-depth. Perimeter middleboxes can then weed out the bad stuff without either allowing the bad stuff to penetrate more deeply into the organization or dropping good stuff that should be allowed through. There's also a myriad of tunneling technology out there. Again, what is an ULP? Where do you stop parsing? The middlebox stops parsing when it decides it has seen enough. With Wireshark at least, it blasts right through encapsulating IP headers and continues up to and including the ultimate TCP/UDP/ICMP etc. header inserted by the original host. The goal is to give the middlebox enough information so that it can parse as deeply into the headers as it wants to. Is GRE a tunnel or an ULP? (GRE can run over almost anything) Is SSH an ULP or a tunnel? (port tunneling) Is Teredo a tunnel or is it an ULP (UDP) or both? GRE/ LT2P over HTTP anyone? The notion of perimeter is moveable in the presence of such tunnels. We will want for middleboxes at outer perimeters to be able to parse as many headers as they want to before releasing the packet to middleboxes at inner perimenters. Otherwise, bad stuff can get past the outermost perimeters and waste bandwidth and/or cause havoc within the protected zone. Presumably there comes a point where the tunnel is terminated and the transported packet is de-encapsulated, and that IMHO forms another perimeter where you'd anyway have to apply further security checks. Nested tunnels give you perimeters within perimeters, yes. But, we will want the outer perimeters to be able to parse as deeply as they want to before passing on to an inner perimeter. I think the draft does what it can in a pragmatic manner, but might benefit from some acknowledgement that this security approach of applying parsing at a single perimeter can never ever catch all variants of transporting FOO over BAR. IMHO It's only at the moment of de-encapsulation that the full semantics of the payload are revealed in these modern times of everything transported over HTTP. Since the problem recurses as we tunnel tunnels, I don't see
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Fernando, -Original Message- From: Fernando Gont [mailto:fg...@si6networks.com] Sent: Friday, October 11, 2013 1:36 AM To: Ray Hunter; Templin, Fred L; brian.e.carpen...@gmail.com Cc: 6man Mailing List; ietf@ietf.org Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard On 10/11/2013 04:48 AM, Ray Hunter wrote: I think the draft does what it can in a pragmatic manner, but might benefit from some acknowledgement that this security approach of applying parsing at a single perimeter can never ever catch all variants of transporting FOO over BAR. FWIW, my idea of the I-D is that it says look, if you don't put all this info into the first fragment, it's extremely likely that your packets will be dropped. That doesn't mean that a middle-box may want to look further. But looking further might imply reassemble-inspect-and-refragment... or even reassemble the TCP stream (e.g. think about a SSL/TCP-based VPN...) We definitely don't want that. That is why we would prefer for the entire header chain (starting from the outermost IP header up to and including the headers inserted by the original host) to fit within the first fragment even if there are multiple encapsulations on the path. Thanks - Fred fred.l.temp...@boeing.com Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Ray, -Original Message- From: Ray Hunter [mailto:v6...@globis.net] Sent: Friday, October 11, 2013 9:59 AM To: Templin, Fred L Cc: brian.e.carpen...@gmail.com; ietf@ietf.org; 6man Mailing List Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard Templin, Fred L mailto:fred.l.temp...@boeing.com 11 October 2013 17:33 Hi Ray, -Original Message- From: Ray Hunter [mailto:v6...@globis.net] Sent: Friday, October 11, 2013 12:49 AM To: Templin, Fred L; brian.e.carpen...@gmail.com Cc: ietf@ietf.org; 6man Mailing List Subject: Re: RE: Last Call: draft-ietf-6man-oversized-header-chain- 08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard Templin, Fred L wrote: Hi Brian, Responding in a slightly re-arranged order: The problem is that you are asserting that middleboxes that a tunnel passes through are expected to examine the complete header chain of the encapsulated packet even if the encapsulated packet is a fragment. Yes, but change are expected to to should be able to. I personally don't see this going anywhere. Unless you specifically define what is a tunnel and you specifically define a maximum depth of nesting. The term Upper-Layer Protocol (ULP) is also itself a vague term IMHO since the value of the IPv6 next header is taken from the same code space as the ULP header values, and there's no specific marker or header length field in IPv6 that explicitly marks a point as This is the end of the IPv6 header chain in all circumstances: stop header parsing here. Ok, there's a bunch of current code-points that are today considered as valid ULP's or next-header values, but that is neither time invariant nor exhaustive, so solving this issue via a registry means there will always be middlebox code in the wild that lags any updates. These middleboxes won't be able to differentiate between an unknown ULP, and an unknown IPv6 next-header. That potentially makes a default pass or drop decision awkward. If it's so important to be able to differentiate between what is an ULP and what is a next header, and we can't reliably do that today, maybe that's a fundamental flaw in IPv6 that should be addressed. I think that's an unreasonable expectation. A reasonable expectation is that middleboxes should identify the encapsulated packet as a payload that they cannot analyse, and let it go (unless they have a policy setting to drop tunnelled packets, which is a different discussion). But why? If headers beyond the first IPv6 encapsulation header are available in the clear, the middlebox should be able to parse them if it wants to. Wireshark already does exactly that - it keeps on parsing beyond the first encapsulation header up to and including the true ULP header. And, if Wireshark can do it, so can any other middlebox that believes security would be improved by continuing to parse the entire chain - whether or not there is a standard saying it must not do so. Because it leaves open the possibility for an attacker to apply the obfuscation we seek to limit. Parsing the additional headers beyond the first encapsulation header provides defense-in-depth. Perimeter middleboxes can then weed out the bad stuff without either allowing the bad stuff to penetrate more deeply into the organization or dropping good stuff that should be allowed through. There's also a myriad of tunneling technology out there. Again, what is an ULP? Where do you stop parsing? The middlebox stops parsing when it decides it has seen enough. Which AFAIK is undefined in practical terms. Especially in the presence of jumbo payload extension headers or fragments. Middleboxes should be able to parse as far as they want to without hitting a hard stop as is the case if the header chain extends into multiple packets. So are you saying the current draft has no value? I am saying that it is unfriendly to tunnels that fragment, and a simple fix is for the host to limit its header chain length to 1024 bytes. With Wireshark at least, it blasts right through encapsulating IP headers and continues up to and including the ultimate TCP/UDP/ICMP etc. header inserted by the original host. I like wireshark. But how would that parsing model work in a live network without maintaining state between frames (and leaving your middlebox open to DoS or other resource depletion abuse)? I don't understand the maintaining state between frames. I am talking about examining individual header chains within a single packet independently of any other packets. We may not yet know how smart middleboxes may become in this regards. But, they will certainly never become smart enough if they don't have the entire header chain in the first fragment. IMHO ultimate TCP/UDP/ICMP etc
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Fernando, -Original Message- From: Fernando Gont [mailto:fg...@si6networks.com] Sent: Friday, October 11, 2013 10:04 AM To: Templin, Fred L; Ray Hunter; brian.e.carpen...@gmail.com Cc: 6man Mailing List; ietf@ietf.org Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard On 10/11/2013 12:36 PM, Templin, Fred L wrote: FWIW, my idea of the I-D is that it says look, if you don't put all this info into the first fragment, it's extremely likely that your packets will be dropped. That doesn't mean that a middle-box may want to look further. But looking further might imply reassemble-inspect-and-refragment... or even reassemble the TCP stream (e.g. think about a SSL/TCP-based VPN...) We definitely don't want that. That is why we would prefer for the entire header chain (starting from the outermost IP header up to and including the headers inserted by the original host) to fit within the first fragment even if there are multiple encapsulations on the path. The problem is that if you have multiple encapsulations, you can always hit the MTU limit and fail to comply with this requirement. Yes you can, which is what I just said to Ray. But, I am not talking about a *requirement* - I am talking about a best practice that works in most cases. The question is how many layers of encapsulation do you need? Let's say you want 5 layers of encapsulation. That would still allow enough room for all of the hosts headers to fit in the first fragment if the host limits its header chain to 1024 bytes. But, now let's say that you want 10 layers of encapsulation. That means that the first 5 middleboxes that examine the outermost encapsulations will not be able to see the entire header chain, but the last 5 middleboxes that examine the innermost encapsulations will. So, there is a limit to the levels of defense-in-depth. But, that limit is greater than 1. Remember also that the 1280/1500 also assumed that there would be just a few layers of nested encapsulations. What I am suggesting allows for endless recursion but limited (and reasonable) defense in depth. That's why this I-D says what it says. I'm not sure this discussion was taken into account, and what the draft says now is not friendly to tunnels. P.S.: Reegarding enforcing a limit on the length of the header chain, I must say I symphatize with that (for instance, check the last individual version of this I-D, and you'll find exactly that). But the wg didn't want that in -- and I did raise the issue a few times. So what we have is what the 6man wg had consensus on. It is not too late to get this right, and to give reasonable treatment to tunnels that the current draft does not give. Thanks - Fred fred.l.temp...@boeing.com Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Brian, -Original Message- From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] Sent: Friday, October 11, 2013 12:50 PM To: Fernando Gont Cc: Templin, Fred L; Ray Hunter; 6man Mailing List; ietf@ietf.org Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard On 12/10/2013 06:04, Fernando Gont wrote: ... P.S.: Reegarding enforcing a limit on the length of the header chain, I must say I symphatize with that (for instance, check the last individual version of this I-D, and you'll find exactly that). But the wg didn't want that in -- and I did raise the issue a few times. So what we have is what the 6man wg had consensus on. I agree that this was the WG consensus after considerable discussion, which included Fred, so I'm not sure why we're discussing it again during IETF LC. Technical matters should be discussed as they come to light; not dismissed because of some real or perceived deadline. That was what got us the 1280 MTU in the first place. Quoting from Steve Deering: We would like to get this issue settled as soon as possible, since this is the only thing holding up the publication of the updated Proposed Standard IPv6 spec (the version we expect to advance to Draft Standard), so let's see if we can come to a decision before the ID deadline at the end of next week (hoping there isn't any conflict between thoughtful analysis and let's decide quickly :-). So, it wasn't necessarily the case that 1280 was a product of thoughtful analysis so much as the fact that **they were rushing to get a spec out the door**. So now, 16 years later, we get to put it back on the 6man charter milestone list. Thanks - Fred fred.l.temp...@boeing.com
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
-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. Thanks - Fred fred.l.temp...@boeing.com Ron -Original Message- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Ole Troan Sent: Tuesday, October 08, 2013 12:17 PM To: Templin, Fred L Cc: i...@ietf.org; ietf@ietf.org; IETF-Announce Subject: 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
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Ole, -Original Message- From: Ole Troan [mailto:otr...@employees.org] Sent: Wednesday, October 09, 2013 9:54 AM To: Templin, Fred L Cc: Ronald Bonica; 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 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. Thanks - Fred fred.l.temp...@boeing.com cheers, Ole
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Ole, -Original Message- From: Ole Troan [mailto:otr...@employees.org] Sent: Wednesday, October 09, 2013 10:31 AM To: Templin, Fred L Cc: Ronald Bonica; 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 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. :-) You know I have an interest in alternative c), but that does not address the issue of splitting the header chain across multiple fragments. So, my choice is: d) limit the size of the IPv6 header chain so that the chain will fit within the first fragment by having the host limit the chain to the MTU size minus 256 bytes. Actually, I would be even happier if we just asked the host to limit the size of the header chain to 1024 bytes regardless of the path MTU. Thanks - Fred fred.l.temp...@boeing.com cheers, Ole
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Brian, Responding in a slightly re-arranged order: The problem is that you are asserting that middleboxes that a tunnel passes through are expected to examine the complete header chain of the encapsulated packet even if the encapsulated packet is a fragment. Yes, but change are expected to to should be able to. I think that's an unreasonable expectation. A reasonable expectation is that middleboxes should identify the encapsulated packet as a payload that they cannot analyse, and let it go (unless they have a policy setting to drop tunnelled packets, which is a different discussion). But why? If headers beyond the first IPv6 encapsulation header are available in the clear, the middlebox should be able to parse them if it wants to. Wireshark already does exactly that - it keeps on parsing beyond the first encapsulation header up to and including the true ULP header. And, if Wireshark can do it, so can any other middlebox that believes security would be improved by continuing to parse the entire chain - whether or not there is a standard saying it must not do so. Parsing the additional headers beyond the first encapsulation header provides defense-in-depth. Perimeter middleboxes can then weed out the bad stuff without either allowing the bad stuff to penetrate more deeply into the organization or dropping good stuff that should be allowed through. Since the problem recurses as we tunnel tunnels, I don't see how any finite limit can solve the problem. 1280 itself is a pragmatic choice of a bit shorter than 1500. The 1280 is assuming that all links in the path have a 1500 MTU and so RFC2460 allowed (1500 - 1280) = 220 bytes for additional IPv6 headers added by nested tunnels without incurring fragmentation. I am asserting instead that we have to allow for paths that include links with a 1280 MTU and so tunnels will have to fragment over such paths. That means that the first fragmenting tunnel would have room for 1240 in the first fragment, the second fragmenting tunnel would have room for 1200 in the first fragment, etc. That is why I would prefer that hosts limit the size of their header chains to 1024; so that nested tunnels that fragment will still be highly likely to have the entire header chain in the first fragment. I understood that to be the basis on which the WG reached consensus. Maybe the WG didn't understand that such a consensus would make tunnels less reliable and less secure. Thanks - Fred fred.l.temp...@boeing.com Brian
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi Ole, -Original Message- From: Ole Troan [mailto:otr...@employees.org] Sent: Tuesday, October 08, 2013 9:17 AM To: Templin, Fred L Cc: ietf@ietf.org; IETF-Announce; i...@ietf.org Subject: 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. It is kind of like that, but what I am concerned about is tunnels in the path that fragment either because they cannot meet the IPv6 minimum MTU without doing so, or because they are trying to allow a larger-sized MTU when the path doesn't support it due to the addition of the encapsulating headers. Take the simplest case when the host assumes a path MTU of 1280. If there is a tunnel in the path that crosses another 1280 link, then the tunnel has to fragment, and the header chain might not all fit within the first fragment if the host does not allow headspace room. If the host limits the size of its header chain to 1280 - 512 = 1024 bytes, then the entire chain should fit within the first fragment even if there are multiple nested tunnel ingresses on the path and each one of them fragments. That said, I am wondering how this document relates to the discussions we had earlier and the resulting draft from Mark Andrews on what to do when the header chain spans multiple fragments? Are we trying to keep the header chain all within the first fragment or not? Thanks - Fred fred.l.temp...@boeing.com cheers, Ole
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
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. Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Templin, Fred L Sent: Friday, October 04, 2013 1:42 PM To: ietf@ietf.org; IETF-Announce Cc: i...@ietf.org Subject: RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard Hi, I have a concern about this document. In the definition of IPv6 Header Chain, it says: However, if a second IPv6 header appears in the header chain, as is the case when IPv6 is tunneled over IPv6, the second IPv6 header is considered to be an upper-layer header and terminates the header chain. This means that stateless firewalls are being directed to discontinue extension header parsing when a first encapsulated IPv6 header is encountered - even though there may be many more parsable (inner) headers that follow. As a result, the firewall would either have to drop or forward the packet without examining the true upper layer header. This may result in an incorrect perception that tunneled traffic is either less reliable or more dangerous than non-tunneled traffic. Here are my suggested changes to address this issue: 1) Section 3, under IPv6 Header Chain, change: However, if a second IPv6 header appears in the header chain, as is the case when IPv6 is tunneled over IPv6, the second IPv6 header is considered to be an upper-layer header and terminates the header chain. to: However, if a second IPv6 header appears in the header chain, as is the case when IPv6 is tunneled over IPv6, the second IPv6 header is optionally considered to be either an upper-layer header that terminates the header chain or another extension header that continues the chain. 2) Section 3, under Upper-layer Header, change: In the general case, the upper-layer header is the first member of the header chain that is neither an IPv6 header nor an IPv6 extension header. to: In the general case, the upper-layer header is the first member of the header chain that is not considered to be an extension header. 3) Section 3, under Upper-layer Header, delete the following sentence: However, if either an ESP header, or a second IPv6 header occur in the header chain, they are considered to be upper layer headers and they terminate the header chain. 4) Section 5, change the final paragraph to: As a result of the above mentioned requirements, a packet's header chain length cannot exceed 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 limit the header chain length to 1024 bytes. Limiting the header chain length to 1024 bytes ensures that the header chain length does not exceed the IPv6 minimum MTU [RFC2460] even if additional encapsulation headers are inserted by tunnels on the path. Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of The IESG Sent: Wednesday, October 02, 2013 11:55 AM To: IETF-Announce Cc: i...@ietf.org Subject: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'Implications of Oversized IPv6 Header Chains' draft-ietf-6man-oversized-header-chain-08.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-10-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The IPv6 specification allows IPv6 header chains of an arbitrary size. The specification also allows options which can in turn extend each of the headers. In those scenarios in which the IPv6
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi, I have a concern about this document. In the definition of IPv6 Header Chain, it says: However, if a second IPv6 header appears in the header chain, as is the case when IPv6 is tunneled over IPv6, the second IPv6 header is considered to be an upper-layer header and terminates the header chain. This means that stateless firewalls are being directed to discontinue extension header parsing when a first encapsulated IPv6 header is encountered - even though there may be many more parsable (inner) headers that follow. As a result, the firewall would either have to drop or forward the packet without examining the true upper layer header. This may result in an incorrect perception that tunneled traffic is either less reliable or more dangerous than non-tunneled traffic. Here are my suggested changes to address this issue: 1) Section 3, under IPv6 Header Chain, change: However, if a second IPv6 header appears in the header chain, as is the case when IPv6 is tunneled over IPv6, the second IPv6 header is considered to be an upper-layer header and terminates the header chain. to: However, if a second IPv6 header appears in the header chain, as is the case when IPv6 is tunneled over IPv6, the second IPv6 header is optionally considered to be either an upper-layer header that terminates the header chain or another extension header that continues the chain. 2) Section 3, under Upper-layer Header, change: In the general case, the upper-layer header is the first member of the header chain that is neither an IPv6 header nor an IPv6 extension header. to: In the general case, the upper-layer header is the first member of the header chain that is not considered to be an extension header. 3) Section 3, under Upper-layer Header, delete the following sentence: However, if either an ESP header, or a second IPv6 header occur in the header chain, they are considered to be upper layer headers and they terminate the header chain. 4) Section 5, change the final paragraph to: As a result of the above mentioned requirements, a packet's header chain length cannot exceed 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 limit the header chain length to 1024 bytes. Limiting the header chain length to 1024 bytes ensures that the header chain length does not exceed the IPv6 minimum MTU [RFC2460] even if additional encapsulation headers are inserted by tunnels on the path. Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of The IESG Sent: Wednesday, October 02, 2013 11:55 AM To: IETF-Announce Cc: i...@ietf.org Subject: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'Implications of Oversized IPv6 Header Chains' draft-ietf-6man-oversized-header-chain-08.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-10-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The IPv6 specification allows IPv6 header chains of an arbitrary size. The specification also allows options which can in turn extend each of the headers. In those scenarios in which the IPv6 header chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the first fragment of a packet may fail to include the entire IPv6 header chain. This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that the first fragment of a packet is required to contain the entire IPv6 header chain. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header-chain/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header- chain/ballot/ No IPR declarations have been submitted directly on this I-D. IETF IPv6 working group mailing list i...@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
RE: LISP is not a Loc-ID Separation protocol
Noel and others, Let's say we have an end system with as many ISP connections as you like - each with its own locator address. Let's say the end system also has multiple loopback interfaces - say it has two, for example. The end system connects to a first VPN and receives the endpoint address A, which it assigns to the first loopback interface. The end system also connects to a second VPN and receives the address B, which it assigns to the second loopback interface. Which one (A or B) is the end system's identity? Thanks - Fred fred.l.temp...@boeing.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: LISP is not a Loc-ID Separation protocol
Noel, -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Noel Chiappa Sent: Thursday, November 03, 2011 7:08 AM To: ietf@ietf.org Cc: j...@mercury.lcs.mit.edu Subject: RE: LISP is not a Loc-ID Separation protocol From: Templin, Fred L fred.l.temp...@boeing.com Let's say the end system also has multiple loopback interfaces - say it has two, for example. Why? What does that buy you? The multiple loopback interfaces (or, more generally, the multiple internal virtual interfaces) are in one to one correspondence with the end system's multiple VPN connections. The internal virtual interfaces keep the VPNs separate. Which one (A or B) is the end system's identity? Suppose I assign two endpoint identifiers to a host. Which is the host's identity? Neither - that's the point. The host's identify is not bound to any one or multiple IP addresses. Thanks - Fred fred.l.temp...@boeing.com Noel ___ 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: LISP is not a Loc-ID Separation protocol
Hi Noel, -Original Message- From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu] Sent: Thursday, November 03, 2011 7:43 AM To: ietf@ietf.org Cc: j...@mercury.lcs.mit.edu Subject: RE: LISP is not a Loc-ID Separation protocol From: Templin, Fred L fred.l.temp...@boeing.com one to one correspondence with the end system's multiple VPN connections. The internal virtual interfaces keep the VPNs separate. As logically separate sources for incoming/outbound packets, they are just like multiple real interfaces. The name used for neither is really the 'identity' of the host, the names applied to those things just identify sources/sinks of packets. Suppose I assign two endpoint identifiers to a host. Which is the host's identity? Neither - that's the point. The host's identify is not bound to any one or multiple IP addresses. I said endpoint identifiers (under whatever definition of that term one wishes to use), not addresses. OK, so then let's consider a related analogy. It is not uncommon for a person (e.g., John Doe) to have dual citizenship with countries A and B, i.e, John interfaces with both countries. John would receive a separate taxpayer identifier from each of A and B, which has relevance only within the respective country's routing system. But, John's identity is neither A nor B; John's identity is John. So, a single host can have multiple identities (whether one does so via multiple interfaces/interface addresses, or endpoint identifiers). So? No; not multiple identities. One identity; multiple interfaces and multiple addresses. Same as for the taxpayer ID analogy. Thanks - Fred fred.l.temp...@boeing.com Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: LISP is not a Loc-ID Separation protocol
Hi Noel, But I must confess I'm kind of confused as to why any of this matters? I mean, it's fun philosophical debate (well, for some people, I guess :-), but so what? It just circles back again to the fact that what LISP calls EID is something that names an interface; not an end system. See the subject line for the implications. I suggested a long time ago that the LISP team rename EID as Endpoint Interface iDentifier, but they balked at the suggestion. I do however believe that that expansion is more closely aligned with the truth. Thanks - Fred fred.l.temp...@boeing.com Noel ___ 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: LISP is not a Loc-ID Separation protocol
Hi Noel, -Original Message- From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu] Sent: Thursday, November 03, 2011 8:28 AM To: ietf@ietf.org Cc: j...@mercury.lcs.mit.edu Subject: RE: LISP is not a Loc-ID Separation protocol From: Templin, Fred L fred.l.temp...@boeing.com It just circles back again to the fact that what LISP calls EID is something that names an interface; not an end system. And I keep pointing out that an LEID which is assigned to a virtual interface, one which is created _solely_ as a place to hold the system's identity, walks like a EID duck, quacks like a EID duck, etc, etc. I mean, here we have a name which i) is purely identity, ii) has no location info of any kind in it, iii) cannot be used for forwarding anywhere, etc, etc. Where in that list is any difference from a 'real' EID (in the sense of 'name for an end system')? (For those on this list who missed the previous N repetitions of this debate, you can now see why there have been N+1 of them.) That you have chosen to re-enter the loop again does not prove your point. My point is proven by the analogy I gave in the previous iteration: https://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=933k2=60357tid=1320334244 Thanks - Fred fred.l.temp...@boeing.com Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: LISP is not a Loc-ID Separation protocol
Noel, -Original Message- From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu] Sent: Thursday, November 03, 2011 8:40 AM To: ietf@ietf.org Cc: j...@mercury.lcs.mit.edu Subject: RE: LISP is not a Loc-ID Separation protocol From: Templin, Fred L fred.l.temp...@boeing.com .. an LEID which is assigned to a virtual interface, one which is created _solely_ as a place to hold the system's identity .. ... .. a name which i) is purely identity, ii) has no location info of any kind in it, iii) cannot be used for forwarding anywhere, etc, etc. Where in that list is any difference from a 'real' EID (in the sense of 'name for an end system')? My point is proven by the analogy I gave in the previous iteration I am still interested to hear if there is any effective difference you can point to? You can't just refuse to engage in my analogy: https://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=933k2=60357tid=1320334244 and then demand that I engage in yours. Thanks - Fred fred.l.temp...@boeing.com Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: LISP is not a Loc-ID Separation protocol
Thankfully, I missed most of the earlier threads related to this. But, on the subject of identifiers, Robin is right. What the IETF protocol known as LISP calls identifiers are actually IP addresses. And, IP addresses name *interfaces*; they do not name *end systems*. Same is true also of IRON. Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Robin Whittle Sent: Tuesday, November 01, 2011 10:34 AM To: ietf@ietf.org Subject: Re: LISP is not a Loc-ID Separation protocol I wrote another explanation of why the LISP protocol does not involve a separate namespace for Identifiers - and so why it is not a Loc-ID Separation protocol. http://www.firstpr.com.au/ip/ivip/namespace/lisp-not-loc-id/ This is a longer version of my arguments earlier in this thread because it assumes no knowledge of the LISP protocol or of the IRTF Routing Research Group work in recent years on scalable routing. Its good that the LISP protocol, Ivip and Iron are not Locator - Identifier Separation protocols: Overloading of Loc ID functions is good for hosts and should be maintained2010-06-22 http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html - Robin ___ 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: 6to4v2 (as in ripv2)?
Christian, -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Christian Huitema Sent: Friday, July 29, 2011 12:17 PM To: Michel Py; Rémi Després Cc: ietf@ietf.org; Keith Moore Subject: RE: 6to4v2 (as in ripv2)? 6rd addresses a different problem than 6to4. 6to4 is a global solution, that relies on pretty much every native IPv6 provider deploying 6to4 relays. If these relays were really well deployed and reliable, 6to4 would allow any router with a native IPv4 address to provide IPv6 connectivity to its local users. That is, 6to4 relies on the kindness of strangers and allows uncoordinated deployments by end-users. 6rd is a local solution, that can be used by providers to easily deploy IPv6 tunnels over their existing IPv4 infrastructure. The provider controls the IPv6 prefix, which effectively defines a specific 6rd subnet. The provider also controls the deployment of relays between the 6rd subnet and the native Internet. There is no need to rely on the kindness of strangers. I think this is well said. Another way of saying the same thing is that 6to4 is an inter-site solution while 6rd is an intra-site solution when considering the provider network as a site. With extensions, ISATAP can also satisfy this provider network intra-site requirement (see draft-templin-isupdate) while enabling the desired IPv6 services for end-user sites. Thanks - Fred fred.l.temp...@boeing.com In a sense, 6rd is very similar to a tunnel broker deployment, with a key improvement and an important limitation. The key improvement is the ability for 6rd routers in the same domain to send traffic directly at each other. Local traffic stays local, does not need to be relayed by the tunnel servers or the 6rd relays. The key limitation is that 6rd assumes direct IPv4 connectivity between the participating 6rd routers, i.e. no NAT. 6rd is a very good solution for its intended usage, rapid deployment of IPv6 by IPv4 providers. But 6rd is not a replacement for the global, uncoordinated 6to4 deployment. Hosts that really need this kind of uncoordinated global solution will have to rely on Teredo if they cannot use 6to4. Whether that's a good thing is clearly a matter of debate. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Michel Py Sent: Friday, July 29, 2011 11:38 AM To: Rémi Després Cc: ietf@ietf.org; Keith Moore Subject: RE: 6to4v2 (as in ripv2)? Rémi Després wrote: 6rd is designed to offer native IPv6 prefixes across IPv4-only routing domains. There is a word for that: oxymoron. In French: oxymore. If it stops working when IPv4 is broken, it is not native. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-ietf-v6ops-6to4-to-historic (yet again)
Ron, I believe 'draft-ietf-v6ops-6to4-advisory' is both necessary and sufficient regardless of whether historic is an appropriate characterization. So, I don't think we need this document. Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Ronald Bonica Sent: Monday, July 25, 2011 7:31 AM To: ietf@ietf.org Subject: draft-ietf-v6ops-6to4-to-historic (yet again) 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: Another look at 6to4 (and other IPv6 transition issues)
Hi Joel, ipv4 is becoming less usable and it's taking autotunnels with it, nobody here has a proposal that changes that. As far as I can tell, IPv4 is not becoming less usable within my organization's network. Thanks - Fred fred.l.temp...@boeing.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] Another look at 6to4 (and other IPv6 transition issues)
-Original Message- From: Ted Lemon [mailto:ted.le...@nominum.com] Sent: Friday, July 15, 2011 12:43 PM To: Templin, Fred L Cc: v6...@ietf.org Operations; IETF Discussion Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues) On Jul 15, 2011, at 3:37 PM, Templin, Fred L wrote: ipv4 is becoming less usable and it's taking autotunnels with it, nobody here has a proposal that changes that. As far as I can tell, IPv4 is not becoming less usable within my organization's network. You realize that you have not contradicted what Joel said, right? The IETF's business isn't making sure that Boeing's networks are functional, much as we might collectively wish you well in that regard. If the IETF wishes organizations such as ours well, then they should be willing to provide operational guidance. RFCs 4057 and 4852 were a small step in that direction, while 'draft-templin-v6ops-isops' provides actionable information. Fred ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] 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
You cannot expect something to be configured correctly if it is simply turned on without a) being managed by someone or b) detection mechanisms to see if it's working. Sadly, anycasted 6to4 meets neither of these conditions. ISATAP meets both of these conditions: http://tools.ietf.org/html/draft-templin-v6ops-isops Fred ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Provider-Aggregated vs Provider-Independent IPv6 addressing
During the IPv6 panel at the plenary last night, representatives of several major service providers discussed their experiences with IPv6. It became clear that many of their experiments involve technologies that delegate Provider-Aggregated (PA) IPv6 prefixes to the customer instead of Provider-Independent (PI) ones. This fact did not seem to be at the forefront of the service providers' use case considerations, and perhaps needs to be brought to a level of awareness in the community. Many years ago, there was an extended debate on this list regarding PA vs. PI. Emotions ran high, and in the end there seemed to be a consensus favoring PI. Have we forgotten about that? Is it time to re-open the debate? Thanks - Fred fred.l.temp...@boeing.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: jim bound
I'll add my voice as another former DEC colleague who was saddened by this news. Jim never shied away from a challenging or contentious job. For example, the work on enterprise networks in RFCs 4852, 4057 could only have been done by someone with Jim's fortitude. I believe we are all better off for having known Jim, and I will miss him. Fred fred.l.temp...@boeing.com -Original Message- From: Paul Vixie [mailto:vi...@isc.org] Sent: Friday, March 06, 2009 11:25 PM To: ietf@ietf.org Subject: jim bound i shared the news with some coworkers from DEC (where jim and i both worked back in the early 1990's). one of them said: Wow, sorry to hear it. Jim treated networking like he was still in 'Nam and beauracracy was Charlie. He always took the hill. another added: I would only add that he never left any behind. jim will be missed, both sorely and otherwise, by me and by many others. ___ 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
