From cpignata@cisco.com Sun Jun 2 12:23:48 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4003A21F9260 for ; Sun, 2 Jun 2013 12:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.74 X-Spam-Level: X-Spam-Status: No, score=-108.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZAAj6chUK1m for ; Sun, 2 Jun 2013 12:23:43 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 189E221F923B for ; Sun, 2 Jun 2013 12:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14056; q=dns/txt; s=iport; t=1370201023; x=1371410623; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SrOn5r79sFQ6h0+RR71uXToZ1BW+qHl1HFXHqqQY8Mk=; b=lIw7ivJgdZ9SPIfFkuPrcEftoE1j14QhJUnrtLn8GiaDd1BZssxfigm4 D6uxrJGLa1vIGH0hjHH2hUWKY8gNV+PJ0Ji4evI3siqyycF4+aPNFDb/k /X3IP114LvveYWSHSGs7RURKcIHvnOFTkM4a7eUaUd6CetrUoZ2wyGR4o 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FACGbq1GtJXG9/2dsb2JhbABQCoMJML8BfxZ0giMBAQEDAQEBATc0CQIFBwQCAQgOAwQBAQsUCQcnCxQJCAIEDgUIAYd+Bgy6RY1rgQkCMQcGgnFhA5NthHqQF4MPgWgHOA X-IronPort-AV: E=Sophos;i="4.87,789,1363132800"; d="scan'208";a="217796346" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 02 Jun 2013 19:23:42 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r52JNgvl008792 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 2 Jun 2013 19:23:42 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Sun, 2 Jun 2013 14:23:42 -0500 From: "Carlos Pignataro (cpignata)" To: Ronald Bonica Thread-Topic: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt Thread-Index: AQHOX8awPeG/0+o4VkKc1yduzQ1WPg== Date: Sun, 2 Jun 2013 19:22:30 +0000 Message-ID: <95067C434CE250468B77282634C96ED322BD8926@xmb-aln-x02.cisco.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.81.8.9] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Internet Area Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 19:23:48 -0000 Hi Ron, Thanks for writing this, and for sending it for review to this list. Please find my review below, which includes sets of comments and suggestion= s organized as more substantive / more editorial and prefaced with "CMP:". = Hope these are clear and useful, and glad to iterate on them. More Substantive: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Generic Routing Encapsulation (GRE) Fragmentation Strategy Abstract This memo documents a GRE fragmentation strategy upon which many vendors have converged. Specifically, it defines procedures to be executed by GRE ingress routers. It is published so that those ... CMP: The focus of this document is only point-to-point GRE tunnels, CMP: and does not include any type of Multipoint GRE tunnels. As such, CMP: I would make this focus explicit in the Abstract, Intro, and in CMP: the document title. 1. Problem Statement ... However, implementors and network operators have discovered that some fragmentation strategies work better than others. A poorly chosen fragmentation strategy can cause operational issues, including black- holing, packet reassembly on GRE egress routers and unexpected interactions with Path MTU Discovery [RFC1191] [RFC1981]. CMP: A big part of a generic discussion of this takes place in RFC 4459. CMP: That's an informational document, that would make of a great CMP: Informational pointer since Section 3 of RFC 4459 contrasts=20 CMP: different approaches. 1.1. How To Use This Document This memo is presented in sections. Section 2 enumerates design goals. Section 3 defines procedures that all GRE ingress routers must execute. CMP: The impact of this "must" is not clear to me; please see below the CMP: comments on that section. 1.2. Terminology The following terms are specific MTU discovery: o link MTU (LMTU) - the maximum transmission unit, i.e., maximum packet size in octets, that can be conveyed over a link without fragmentation o path MTU (PMTU) - the minimum LMTU of all the links in a path between a source node and a destination node CMP: There are two specific clarifications that are important here, I CMP: believe: i. PMTU is unidirectional, and on a per-direction. So CMP: in this case is the LMTU from source to destination. ii. there CMP: is not necessarily "a path", but likely there are multi-paths. CMP: so given ECMP, this needs to clarify it is of all paths from=20 CMP: source to sink (and not *the* path *between* source and sink). 3.2. Tunnel MTU (TMTU) Discovery Implementations MUST maintain a local data structure that reflects the TMTU of each GRE tunnel that originates on the node. The TMTU MUST be equal to the PMTU associated with the path between the tunnel ingress and the tunnel egress, minus the GRE overhead. CMP: This "MUST" is only applicable when PMTUD is in effect, which is CMP: not a MUST for this scenario. I would condition the MUST to "when=20 CMP: PMTUD is being used for the tunnel". For completeness, an editorial: CMP: The way the first sentence is written appears to be too restrictive CMP: of how to implement TMTU. The TMTU can be kept as an element in the CMP: existing data structures hosting tunnel endpoint state.=20 By default, implementations MUST discover the PMTU associated with the path between the tunnel ingress and the tunnel egress. PMTU discovery procedures defined in [RFC1191] and [RFC1981] and will never permit the PMTU to exceed the LMTU associated with the first IP hop in the path to the tunnel egress. CMP: This MUST seems too strict to me. For example, for cases in which CMP: ICMPs are blocked between the source and destination of the GRE CMP: tunnel, this requirement can lead to black-holing (instead of=20 CMP: suboptimal performance at the destination GRE endpoint), and the=20 CMP: medicine would be worst than the sickness. Or put a different way, CMP: PMTUD MUST work for this to be a MUST -- however, it is impossible CMP: to ensure PMTUD MUST work if ICMP 3/4s are blocked. And there is=20 CMP: no (to my knowledge) PL-PMTUD defined for GRE -- only for TCP. CMP: CMP: A nit as well: This is not necessarily a LMTU, but in the case of CMP: ECMP in the first hop, this is the smallest of the LMTUs associated CMP: with the paths... However, implementations MUST include a configuration option that disables PMTU Discovery for GRE tunnels. This configuration option may be required to mitigate certain denial of service attacks (see Section 7). When PMTU discovery for GRE tunnels is disabled, the TMTU for a tunnel MUST default to the LMTU associated with the first IP hop in the path to the tunnel egress, minus the GRE overhead. However, implementations MAY include a configuration option through which the TMTU can be set to another value, which is likely to be lower. CMP: This is good for the case of a single GRE tunnel, but it changes CMP: if the GRE tunnel is protected with IPsec -- unless, the IPsec CMP: overhead is somehow counted towards the "GRE Delivery Header". CMP: I believe there is another key requirement for TMTUD for IPv4: the CMP: configurability of how to set the DF-bit in the Delivery Header. CMP: Specifically, the DF can be copied from the tunneled packet (if v4) CMP: or it can always be set. RFC 2003 (which should also be an Info CMP: pointer) allows for both. A discussion on why setting DF helps=20 CMP: speed up the convergence of PMTUD (and consequently of TMTUD) CMP: would also operators. And a requirement needs to exist for the CMP: ability to configure this behavior. CMP: Actually, on third important point as well :-) For PMTUD for GRE CMP: and TMTUD, when the GRE Tunnel uses GRE Keys, then the Key=20 CMP: included in the embedded packet of the ICMP PTB should be checked CMP: against the configured/used Key in the GRE Tunnel (like with TCP). CMP: This needs to be called out also in the Security Considerations. 4.1. Tunneling GRE Over IPv4 When the GRE ingress router tunnels an IPv4 payload over IPv4, and the DF Bit in the payload header is set to 0 (May Fragment), by default, the GRE ingress router MUST set the DF bit in the delivery header to 1. However, implementations MAY include a configuration option that allows the DF bit to be copied from the payload header to the delivery header. CMP: Wouldn't this be updating RFC 2003? It seems to me that a MUST is CMP: too strong of a requirement. I can see providing a RECOMMENDED, CMP: perhaps. The GRE ingress router MUST NOT emit a delivery header in which the MF bit is set to 1 (More Fragments). CMP: Similarly, this MUST NOT seems too limiting (as per the explanation CMP: above). It seems to me that the success of PMTUD with ICMP being=20 CMP: best effort delivery is not one to underpin this hard requirement. 5.1. IPv4 Payloads If the DF bit in the payload header is set to 1 (Don't Fragment), the GRE ingress router MUST discard the packet and sent an ICMPv4 [RFC0792] Destination Unreachable message to the payload source, with type equal to 4 (fragmentation needed and DF set). The ICMP Destination Unreachable message MUST contain an Next-hop MTU (as specified by [RFC1191]) and the next-hop MTU MUST be equal to the TMTU associated with the tunnel. CMP: This is perfect, but for the case in which PMTUD and TMTUD are on. CMP: This section should condition the requirements to that (because CMP: it is assuming it is always on). CMP: I do believe strongly that this is doing the right thing, BTW. I CMP: am not sure, though, if we can always REQUIRE this. 5.3. MPLS Payloads The GRE ingress router MUST discard the packet. As it is impossible to reliably identify the payload source, the GRE ingress router MUST NOT attempt to send an ICMPv4 Destination Unreachable message or an ICMPv6 Packet Too Big message to the payload source. CMP: This is a most serious concern, because mandating PMTUD/TMTUD ( CMP: the MUST in Section 3.2, 5.1, etc.) without a way to fragment, CMP: and without a way to signal to the source (e.g., ICMP PTB for IP), CMP: since in the MPLS case there is no source with merging, then this CMP: "MUST" effectively creates a permanent black-hole for MPLS over GRE. CMP:=20 CMP: Also, I would change this to say something like: if it can be CMP: reliably determined that the payload of the MPLS packet is IPv4,=20 CMP: then it can be prefragged and copy the MPLS header to all fragments, CMP: quite efficiently.=20 7. Security Considerations CMP: see comment about about the security consideration of ICMP spoofing. CMP: This attack is such that makes it hard to justify a "MUST have PMTUD=20 CMP: enabled by default" in this document. 7.2. Attacks Against PMTU Discovery PMTU Discovery is vulnerable to two denial of service attacks (see Section 8 of [RFC1191] for details). Both attacks are based upon on a malicious party sending forged ICMPv4 Destination Unreachable or ICMPv6 Packet Too Big messages to a host. In the first attack, the forged message indicates an inordinately small PMTU. In the second attack, the forged message indicates an inordinately large MTU. In both cases, throughput is adversely affected. On order to mitigate such attacks, GRE implementations MUST include a configuration option to disable PMTU discovery on GRE tunnels. CMP: Lastly, in addition (and better sometimes) than just disable PMTUD, CMP: a tunnel endpoint should provide the configuration option to set=20 CMP: the minimum TMTU that can be set as a result to ICMP PTB. This CMP: is to protect against the case of an ICMP PTB with too small MTU. More Editorial: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Abstract This memo documents a GRE fragmentation strategy upon which many vendors have converged. CMP: This is not "GRE fragmentation" (i.e., which strictly is having=20 CMP: things like "B" and "E" fragmentation bits in the GRE header.=20 CMP: THis is a nit, but just for clarity (given that this topic can be=20 CMP: confusing), I'd use something like "fragmentation in GRE point-to- CMP: point tunnel scenarios". 1. Problem Statement ... However, implementors and network operators have discovered that some fragmentation strategies work better than others. A poorly chosen fragmentation strategy can cause operational issues, including black- holing, packet reassembly on GRE egress routers and unexpected interactions with Path MTU Discovery [RFC1191] [RFC1981]. CMP: I would add here a pointer to the discussion in Section 4.1.4 of CMP: RFC 3931 as part of the discussion there is applicable to other=20 CMP: p2p tunnels. This is an Informational pointer. 1.1. How To Use This Document Section 4 defines procedures affecting generation of the GRE delivery header. It is divided into two subsections. Section 4.1 is applicable when GRE is tunneled over IPv4[RFC0791] and Section 4.2 is applicable when GRE is tunneled over IPv6 [RFC2460]. CMP: Another nit, since the rest of the doc does such a good job at=20 CMP: being precise with terminology: GRE is not "tunneled" over IP. It CMP: is "delivered". 1.2. Terminology The following terms are specific to GRE and are taken from [RFC2784]: o GRE delivery header - an IPv4 or IPv6 header whose source address is that of the GRE tunnel ingress and whose destination address is that of the GRE tunnel egress. The GRE delivery header encapsulates a GRE header. CMP: This, again, describes a p2p GRE tunnel. Multipoint flavors should=20 CMP: be explicitly out of scope. o GRE payload - a network layer packet that is encapsulated by the GRE header. The GRE payload can be IPv4, IPv6 or MPLS. CMP: ... "or other. This document only covers IPv4, IPv6, and MPLS only." Thanks! -- Carlos. On May 29, 2013, at 9:36 AM, Ronald Bonica wrote: > Folks, >=20 > If you get a chance, please provide a sanity check on this document. It i= s very short, so it won't take much time to review. >=20 > Ron >=20 >=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Wednesday, May 29, 2013 9:34 AM >> To: Ronald Bonica >> Subject: New Version Notification for draft-bonica-intarea-gre-mtu- >> 00.txt >>=20 >>=20 >> A new version of I-D, draft-bonica-intarea-gre-mtu-00.txt >> has been successfully submitted by Ron Bonica and posted to the IETF >> repository. >>=20 >> Filename: draft-bonica-intarea-gre-mtu >> Revision: 00 >> Title: Generic Routing Encapsulation (GRE) Fragmentation >> Strategy >> Creation date: 2013-05-29 >> Group: Individual Submission >> Number of pages: 8 >> URL: http://www.ietf.org/internet-drafts/draft-bonica- >> intarea-gre-mtu-00.txt >> Status: http://datatracker.ietf.org/doc/draft-bonica-intarea- >> gre-mtu >> Htmlized: http://tools.ietf.org/html/draft-bonica-intarea-gre- >> mtu-00 >>=20 >>=20 >> Abstract: >> This memo documents a GRE fragmentation strategy upon which many >> vendors have converged. Specifically, it defines procedures to be >> executed by GRE ingress routers. It is published so that those >> building new implementations will be aware of best common practice. >> It is also published so that those building applications over GRE >> will understand how GRE works. >>=20 >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >=20 From cpignata@cisco.com Sun Jun 2 12:23:49 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1238021F9260 for ; Sun, 2 Jun 2013 12:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.669 X-Spam-Level: X-Spam-Status: No, score=-109.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGd9ZH3xpC-H for ; Sun, 2 Jun 2013 12:23:44 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E5A0121F925A for ; Sun, 2 Jun 2013 12:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9571; q=dns/txt; s=iport; t=1370201024; x=1371410624; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=laycNRokoV9I89J50AzqmQST7PmDq2ifzq1kvguwuzI=; b=ErexQ24rHf1pNIvgX2keerWzrG95SWKQ+VNM6HTvsAZEEPQ0kUDX724P fglUDxcb3Nt3ojFTIfwuSa+3zeFRqA7gD8k5d/2kjIevpJhgnvY+0Jt1l zJUGqbLtQYTAHsg2wUtjYEb/etiB4YCpm4PVzpmKDUbqVjl9M6e5bmZ9Y o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FACGbq1GtJXG+/2dsb2JhbABaDoJ7ML8BfxZ0giQBAQQBAQFrCQIQAgEIIh0HJwsUEQIEDgUIiAUMukEEjnYxB4J3YQOofoJRPoIn X-IronPort-AV: E=Sophos;i="4.87,789,1363132800"; d="scan'208,217";a="217796350" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 02 Jun 2013 19:23:43 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r52JNhSW030218 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 2 Jun 2013 19:23:43 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Sun, 2 Jun 2013 14:23:43 -0500 From: "Carlos Pignataro (cpignata)" To: Joe Touch Thread-Topic: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt Thread-Index: AQHOX8axN2crkzwOWkm+N/eD/MSFQQ== Date: Sun, 2 Jun 2013 19:22:31 +0000 Message-ID: <95067C434CE250468B77282634C96ED322BD8932@xmb-aln-x02.cisco.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645B3615C@dfweml509-mbx.china.huawei.com> <51A665B1.40507@isi.edu> In-Reply-To: <51A665B1.40507@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.81.8.9] Content-Type: multipart/alternative; boundary="_000_95067C434CE250468B77282634C96ED322BD8932xmbalnx02ciscoc_" MIME-Version: 1.0 Cc: Ronald Bonica , Internet Area Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 19:23:49 -0000 --_000_95067C434CE250468B77282634C96ED322BD8932xmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joe, On May 29, 2013, at 4:31 PM, Joe Touch = > wrote: On 5/29/2013 1:06 PM, Linda Dunbar wrote: Ron, I do have a few questions and suggestion about the practices documented in = the draft: - Section 4.1, second paragraph: why DF bit "MUST" set to 1 when the payload header has "0"? I would think = default should be same as the "payload" DF setting. DF in a tunnel header should be set to match the capability of that tunnel = mechanism. Either the tunnel wants to find the MTU and match it or not; in = the former case, it has to set DF=3D1 all the time. For this doc, whether to set or copy the DF bit depends on whether PMTUD is= supported on a given tunnel. If it is (whether PMTUD or PLMTUD), then set = DF; otherwise, I agree - copy DF. - Section 5.1, last sentence: "The GRE egree router will forward the payload fragments to their ultimate destination where there will be reassembled" The GRE egress router should reassemble the fragmented payloads before sending to the destination. In general, the network outside the Egress router should be same as the network before entering the Ingress router. If the data frame size is less than then MTU of the network before entering the Ingress router, the decapsulated frame size should be less than the MTU of the network outside the Egress router. I agree; my general recommendation has always been "the egress should alway= s clean up any mess created by an ingress" - which means using "outer" frag= mentation rather than "inner". Why do you characterize this as a "mess"? Thinking of the tunnel as a logic= al link with its own logical link MTU (LMTU), and this link is unwilling/in= capable of performing fragmentation and reassembly at its "data-link", then= the appropriate behavior would be: * If the incoming IPv4 datagram has DF=3D1, drop and send a PTB back; a= nd * if the incoming IPv4 datagram has DF=3D0, then fragment it and send i= t over the link. What's different? Yes, this can cause repeated frag/reassembly, but the alternative is to shi= ft work to the end host, which I think is inappropriate. I do not understand why it is "inappropriate" -- when thinking of the tunne= l as a link. There is also a potential mischaracterization when you say "shift work to t= he end host", because that can lead to assumptions that there is "a single"= end host (singular). In the case of a p2p tunnel, the challenge is that th= ere is a single pair of endpoints in the tunnel, but a multitude of hosts b= ehind and before them. A different view would be that it's more efficient t= o distribute reassembly to many endpoints instead of attacking the tunnel t= ailend and making it work on behalf of many hosts/ Thanks, -- Carlos. Further, this sort of clean-up is required by IPv6 and for IPv4 when when D= F=3D1 on the inner packet anyway. In addition, it is the Ingress node split the frame, the final destination may not be aware of how to reassemble the data frame. This is a spurious point; the information is there if the inner packet was = fragmentable. - There should be two options when the encapsulated data frame exceeds MTU: a) split the data frame to two smaller frames, with each frame being encapsulated; b) truncate the frame if the Egress node needs to receive the data frame but doesn't have the capability to reassemble split frames. There are two viable options: - fragment and reassemble (same as your option "a)" above) - drop the packet (and presumably send a signal upstream) Sending a truncated frame serves no useful purpose. Joe _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area --_000_95067C434CE250468B77282634C96ED322BD8932xmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Joe,

On May 29, 2013, at 4:31 PM, Joe Touch <touch@isi.edu> wrote:



On 5/29/2013 1:06 PM, Linda Dunbar wrote:
Ron,

I do have a few questions and suggestion about the practices documented in = the draft:

- Section 4.1, second paragraph:
why DF bit "MUST" set to 1  when the payload header has &quo= t;0"? I would think default should be same as the "payload" = DF setting.

DF in a tunnel header should be set to match the capability of that tunnel = mechanism. Either the tunnel wants to find the MTU and match it or not; in = the former case, it has to set DF=3D1 all the time.

For this doc, whether to set or copy the DF bit depends on whether PMTUD is= supported on a given tunnel. If it is (whether PMTUD or PLMTUD), then set = DF; otherwise, I agree - copy DF.

- Section 5.1, last sentence: "The GRE egree= router will forward the
payload fragments to their ultimate destination where there will be
reassembled"

The GRE egress router should reassemble the fragmented payloads
before sending to the destination. In general, the network outside
the Egress router should be same as the network before entering the
Ingress router. If the data frame size is less than then MTU of the
network before entering the Ingress router, the decapsulated frame
size should be less than the MTU of the network outside the Egress
router.

I agree; my general recommendation has always been "the egress should = always clean up any mess created by an ingress" - which means using &q= uot;outer" fragmentation rather than "inner".

Why do you characterize this as a "mess"? Thinking of the tu= nnel as a logical link with its own logical link MTU (LMTU), and this = link is unwilling/incapable of performing fragmentation and reassembly at i= ts "data-link", then the appropriate behavior would be:
  • If the incoming IPv4 datagram has DF=3D1, drop and send a PTB back; and=
  • if the incoming IPv4 datagram has DF=3D0, then fragment it and sen= d it over the link.

What's different?


Yes, this can cause repeated frag/reassembly, but the alternative is to shi= ft work to the end host, which I think is inappropriate.

I do not understand why it is "inappropriate" -- when thinki= ng of the tunnel as a link. 

There is also a potential mischaracterization when you say "shift= work to the end host", because that can lead to assumptions that ther= e is "a single" end host (singular). In the case of a p2p tunnel,= the challenge is that there is a single pair of endpoints in the tunnel, but a multitude of hosts behind and before them. A differen= t view would be that it's more efficient to distribute reassembly to many e= ndpoints instead of attacking the tunnel tailend and making it work on beha= lf of many hosts/

Thanks,

-- Carlos.

Further, this sort of clean-up is required by IPv= 6 and for IPv4 when when DF=3D1 on the inner packet anyway.

In addition, it is the Ingress node split the fra= me, the final
destination may not be aware of how to reassemble the data frame.

This is a spurious point; the information is there if the inner packet was = fragmentable.

- There should be two options when the encapsulat= ed data frame
exceeds MTU: a) split the data frame to two smaller frames, with each
frame being encapsulated; b) truncate the frame if the Egress node
needs to receive the data frame but doesn't have the capability to
reassemble split frames.

There are two viable options:

- fragment = and reassemble (same as your option "a)" above)

- drop the = packet (and presumably send a signal upstream)

Sending a truncated frame serves no useful purpose.

Joe


_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


--_000_95067C434CE250468B77282634C96ED322BD8932xmbalnx02ciscoc_-- From touch@isi.edu Mon Jun 3 10:47:45 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF0521F86AE for ; Mon, 3 Jun 2013 10:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+CorjtNoYW2 for ; Mon, 3 Jun 2013 10:47:30 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 6A03D21F86CA for ; Mon, 3 Jun 2013 10:44:40 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r53Hi4bK016578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Jun 2013 10:44:04 -0700 (PDT) Message-ID: <51ACD5DF.7040800@isi.edu> Date: Mon, 03 Jun 2013 10:43:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645B3615C@dfweml509-mbx.china.huawei.com> <51A665B1.40507@isi.edu> <95067C434CE250468B77282634C96ED322BD8932@xmb-aln-x02.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED322BD8932@xmb-aln-x02.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Ronald Bonica , Internet Area Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 17:47:45 -0000 Hi, Carlos, On 6/2/2013 12:22 PM, Carlos Pignataro (cpignata) wrote: > Joe, > > On May 29, 2013, at 4:31 PM, Joe Touch > wrote: > ... >> I agree; my general recommendation has always been "the egress should >> always clean up any mess created by an ingress" - which means using >> "outer" fragmentation rather than "inner". > > Why do you characterize this as a "mess"? The ingress is creating a situation that takes work to correct (the "mess" I refer to). A. Using outer fragmentation places that work at the egress. B. Using inner fragmentation pushes that work to the destination. Note that fragmentation is a lot cheaper (less work) than reassembly. So (A) makes it easy for routers to support GRE more cost-effectively, but drains things like my iPhone battery as a result. I don't like that optimization. If you make a mess, IMO you should clean it up. > Thinking of the tunnel as a > logical link with its own logical link MTU (LMTU), and this link is > unwilling/incapable of performing fragmentation and reassembly at its > "data-link", There's a *big* difference between incapable and unwilling. Incapable is fine - drop and send the ICMP. Unwilling isn't a reason to skip the hard work. > then the appropriate behavior would be: > > * If the incoming IPv4 datagram has DF=1, drop and send a PTB back; and > * if the incoming IPv4 datagram has DF=0, then fragment it and send it > over the link. > > What's different? It's exactly the difference between incapable and unwilling. Here's the difference for GRE: - GRE adds N bytes total (GRE header + IP header) - GRE over IP supports 65536-byte packets So if a packet arrives that is smaller than 65536-N, IMO GRE ought to fragment and reassemble it. If a packet arrives that is larger than that, then GRE *cannot* tunnel it, and *MUST* drop it and sent a PTB. I.e., only 65536 is "too big". Everything else is just whining about "bigger than I want it to be" ;-) >> Yes, this can cause repeated frag/reassembly, but the alternative is >> to shift work to the end host, which I think is inappropriate. > > I do not understand why it is "inappropriate" -- when thinking of the > tunnel as a link. See above. > There is also a potential mischaracterization when you say "shift work > to the end host", because that can lead to assumptions that there is "a > single" end host (singular). In the case of a p2p tunnel, the challenge > is that there is a single pair of endpoints in the tunnel, but a > multitude of hosts behind and before them. A different view would be > that it's more efficient to distribute reassembly to many endpoints > instead of attacking the tunnel tailend and making it work on behalf of > many hosts/ It would be an attack, except that you're talking about a tunnel. A tunnel is an ingress and an egress. Are you suggesting that making an egress do its job is an "attack"? Joe > From touch@isi.edu Mon Jun 3 11:36:57 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A8821F93BA for ; Mon, 3 Jun 2013 11:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.739 X-Spam-Level: X-Spam-Status: No, score=-103.739 tagged_above=-999 required=5 tests=[AWL=-1.140, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nI8jTlcjwwoe for ; Mon, 3 Jun 2013 11:36:32 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBFB21F86BB for ; Mon, 3 Jun 2013 11:36:00 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r53IZcBN003078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Jun 2013 11:35:38 -0700 (PDT) Message-ID: <51ACE1F5.2050207@isi.edu> Date: Mon, 03 Jun 2013 11:35:33 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Linda Dunbar References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645B3615C@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B3615C@dfweml509-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Ronald Bonica , Internet Area Subject: Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 18:36:57 -0000 On 5/29/2013 1:06 PM, Linda Dunbar wrote: > Ron, > > I do have a few questions and suggestion about the practices documented in the draft: > > - Section 4.1, second paragraph: > why DF bit "MUST" set to 1 when the payload header has "0"? I would think default should be same as the "payload" DF setting. It depends on the goal: The current mechanism always sets DF=1 so it (GRE) can discover the tunnel MTU. Setting it to match would expose the endpoint to the overall path MTU, but comes at a risk. If a packet is too big somewhere inside the tunnel, that router will send an ICMP that goes back to the tunnel ingress -- which might not have enough information to relay an ICMP back to the source. This was discussed here: http://tools.ietf.org/html/draft-ietf-intarea-tunnels (this is still a WG doc, but we didn't get much feedback on the issues back in 2010 - maybe it's time to revive and complete it??) ... > - There should be two options when the encapsulated data frame > exceeds MTU: a) split the data frame to two smaller frames, with each > frame being encapsulated; FWIW, fragmentation rarely splits things into equal sizes; it's more typical to split into "max that fits" and "leftover". Joe From cpignata@cisco.com Mon Jun 3 17:01:08 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B0321F8F41 for ; Mon, 3 Jun 2013 17:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJz3AyAifK2t for ; Mon, 3 Jun 2013 17:00:03 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C111721E8092 for ; Mon, 3 Jun 2013 16:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5721; q=dns/txt; s=iport; t=1370303253; x=1371512853; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wbUQigVp8CsU1vZjKrjeCWwNQPfDmjEKypN/ZIEOtAk=; b=NhQpilzvxiUm2qaEeqtgNOf1ZpvJG6+arW5h5iFebYt+JpuNkUNkl82E qNf4Ijp/mS05mQbuwLUy102n8LEWfcAd2Ae+8ZQcJFBoc7xwOBOaVkokk wPI5Cp+59cf10Y5EN5P7hwmIGaCjYT+y1KxKPkq26sBpbGoGXKqjWxlJr w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAMEqrVGtJV2d/2dsb2JhbABZDoJ7ML8IgQgWdIIjAQEBAwEnUAIFCwIBCBgKHQcyFBECBA4FCId/Bgy8YY1fgRUCMQeCd2EDiGiPf5AXglE+gic X-IronPort-AV: E=Sophos;i="4.87,796,1363132800"; d="scan'208";a="218310479" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 03 Jun 2013 23:47:21 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r53NlL21016779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 23:47:21 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 18:47:20 -0500 From: "Carlos Pignataro (cpignata)" To: Joe Touch Thread-Topic: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt Thread-Index: AQHOYIIMa1mBCKLTbEayE5IJHrB8Epkk/CuA Date: Mon, 3 Jun 2013 23:46:03 +0000 Message-ID: <95067C434CE250468B77282634C96ED322BDF244@xmb-aln-x02.cisco.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645B3615C@dfweml509-mbx.china.huawei.com> <51A665B1.40507@isi.edu> <95067C434CE250468B77282634C96ED322BD8932@xmb-aln-x02.cisco.com> <51ACD5DF.7040800@isi.edu> In-Reply-To: <51ACD5DF.7040800@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.53] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8AA4777BF3FF5C479434468ECA4BA34B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ronald Bonica , Internet Area Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 00:01:09 -0000 Hi, Joe, On Jun 3, 2013, at 1:43 PM, Joe Touch wrote: > Hi, Carlos, >=20 > On 6/2/2013 12:22 PM, Carlos Pignataro (cpignata) wrote: >> Joe, >>=20 >> On May 29, 2013, at 4:31 PM, Joe Touch > > wrote: >>=20 > ... >>> I agree; my general recommendation has always been "the egress should >>> always clean up any mess created by an ingress" - which means using >>> "outer" fragmentation rather than "inner". >>=20 >> Why do you characterize this as a "mess"? >=20 > The ingress is creating a situation that takes work to correct (the "mess= " I refer to). >=20 > A. Using outer fragmentation places that work at the egress. >=20 > B. Using inner fragmentation pushes that work to the destination. >=20 > Note that fragmentation is a lot cheaper (less work) than reassembly. So = (A) makes it easy for routers to support GRE more cost-effectively, but dra= ins things like my iPhone battery as a result. >=20 [I think you mean (B) and not (A) in the sentence above] A different way of looking at it is that a Host is generally more optimized= to perform this function than a router. Or, if you prefer the view that tu= nnel endpoints act as hosts for the Tunnel (delivery), then a "host" is mor= e "host" than a router for reassembly. Frankly, for the case of draining smartphone battery, you could just use IP= v6 or set DF. > I don't like that optimization. If you make a mess, IMO you should clean = it up. >=20 I understand you have a preference and you do not like it. On the other han= d, it is still a valid case. It is documented, for example, in the second p= ara of S4.1.4 of RFC 3931 http://tools.ietf.org/html/rfc3931#section-4.1.4 > > Thinking of the tunnel as a >> logical link with its own logical link MTU (LMTU), and this link is >> unwilling/incapable of performing fragmentation and reassembly at its >> "data-link", >=20 > There's a *big* difference between incapable and unwilling. >=20 > Incapable is fine - drop and send the ICMP. >=20 > Unwilling isn't a reason to skip the hard work. >=20 >> then the appropriate behavior would be: >>=20 >> * If the incoming IPv4 datagram has DF=3D1, drop and send a PTB back; a= nd >> * if the incoming IPv4 datagram has DF=3D0, then fragment it and send i= t >> over the link. >>=20 >> What's different? >=20 > It's exactly the difference between incapable and unwilling. >=20 > Here's the difference for GRE: >=20 > - GRE adds N bytes total (GRE header + IP header) >=20 > - GRE over IP supports 65536-byte packets >=20 > So if a packet arrives that is smaller than 65536-N, IMO GRE ought to fra= gment and reassemble it. >=20 > If a packet arrives that is larger than that, then GRE *cannot* tunnel it= , and *MUST* drop it and sent a PTB. >=20 > I.e., only 65536 is "too big". Everything else is just whining about "big= ger than I want it to be" ;-) [For scope, this is an IPv4 discussion; with IPv4, the mechanism for this i= s to set DF.] If DF is not set, which specification defines that a packet cannot be fragm= ented? It really is a trade-off; and as such, IMHO, there is not one-size-f= its-all but there are deployment decisions and practices. >=20 >>> Yes, this can cause repeated frag/reassembly, but the alternative is >>> to shift work to the end host, which I think is inappropriate. >>=20 >> I do not understand why it is "inappropriate" -- when thinking of the >> tunnel as a link. >=20 > See above. I am still not sure how "inappropriate" is a technical term. I do understan= d your preference and I do follow the logic. My point is that it does not s= eem to be a mandated behavior by a spec., and seems to be a trade-off to be= documented with pros and cons for this case. Let me try a different example, and let me know which step you disagree wit= h :-) 0. GRE Tunnel between R1 and R2, tunneling IPv4 from end hosts. 1. The delivery (encapsulating) header sets DF (as allowed by RFC791, for e= xample because R2 does not have sufficient resources to reassemble internet= fragments.) 2. The GRE Tunnel is realized as a logical interface. 3. A 2000 octet IPv4 datagram from an end host has the GRE tunnel as the ne= xt-hop; R1 encapsulates in GRE, then IPv4 with DF set, and then when trying= to send the datagram sees that it is larger than the physical MTU of the o= ut interface. 4. R1 sends an ICMPv4 PTB to itself and drops the datagram, and the tunnel = learns its MTU. 5. Another datagram is received for the tunnel, with the DF bit clear, what= should R1 do? -> fragment the encapsulated packet and encapsulate it. >=20 >> There is also a potential mischaracterization when you say "shift work >> to the end host", because that can lead to assumptions that there is "a >> single" end host (singular). In the case of a p2p tunnel, the challenge >> is that there is a single pair of endpoints in the tunnel, but a >> multitude of hosts behind and before them. A different view would be >> that it's more efficient to distribute reassembly to many endpoints >> instead of attacking the tunnel tailend and making it work on behalf of >> many hosts/ >=20 > It would be an attack, except that you're talking about a tunnel. A tunne= l is an ingress and an egress. Are you suggesting that making an egress do = its job is an "attack"? A different perspective: If the tunnel is a link in a logical topology, the= n this preference would be equivalent to asking every link to perform data-= link-level fragmentation and reassembly and allow any size packets. Thanks, -- Carlos. >=20 > Joe >=20 >>=20 >=20 From touch@isi.edu Mon Jun 3 18:42:50 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790DF11E8161 for ; Mon, 3 Jun 2013 18:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.728 X-Spam-Level: X-Spam-Status: No, score=-102.728 tagged_above=-999 required=5 tests=[AWL=-1.329, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_54=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aG2fhNGmm0zU for ; Mon, 3 Jun 2013 18:42:36 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2B821E809D for ; Mon, 3 Jun 2013 17:11:40 -0700 (PDT) Received: from [128.9.184.186] ([128.9.184.186]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r540AY9n002594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Jun 2013 17:10:34 -0700 (PDT) Message-ID: <51AD307D.1070007@isi.edu> Date: Mon, 03 Jun 2013 17:10:37 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645B3615C@dfweml509-mbx.china.huawei.com> <51A665B1.40507@isi.edu> <95067C434CE250468B77282634C96ED322BD8932@xmb-aln-x02.cisco.com> <51ACD5DF.7040800@isi.edu> <95067C434CE250468B77282634C96ED322BDF244@xmb-aln-x02.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED322BDF244@xmb-aln-x02.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Ronald Bonica , Internet Area Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 01:42:50 -0000 On 6/3/2013 4:46 PM, Carlos Pignataro (cpignata) wrote: > Hi, Joe, > > On Jun 3, 2013, at 1:43 PM, Joe Touch wrote: > >> Hi, Carlos, >> >> On 6/2/2013 12:22 PM, Carlos Pignataro (cpignata) wrote: >>> Joe, >>> >>> On May 29, 2013, at 4:31 PM, Joe Touch >> > wrote: >>> >> ... >>>> I agree; my general recommendation has always been "the egress should >>>> always clean up any mess created by an ingress" - which means using >>>> "outer" fragmentation rather than "inner". >>> >>> Why do you characterize this as a "mess"? >> >> The ingress is creating a situation that takes work to correct (the "mess" I refer to). >> >> A. Using outer fragmentation places that work at the egress. >> >> B. Using inner fragmentation pushes that work to the destination. >> >> Note that fragmentation is a lot cheaper (less work) than reassembly. So (A) makes it easy for routers to support GRE more cost-effectively, but drains things like my iPhone battery as a result. >> > > [I think you mean (B) and not (A) in the sentence above] Yup. > A different way of looking at it is that a Host is generally more > optimized to perform this function than a router. Some host are; others (like my phone) do this at a heft cost (to me). Some routers can do this (ones that are designed well); others cannot (like ones that claim they support GRE but really don't because they don't implement at-rate reassembly). > Or, if you prefer the > view that tunnel endpoints act as hosts for the Tunnel (delivery), then > a "host" is more "host" than a router for reassembly. I disagree; the router liked being a host when it encapsulated the packets. That includes generating unique IPv4 IDs (if DF=0), generating checksums, etc. - that part it's OK with. If it wants to play host there, it can play host at the egress too. > Frankly, for the case of draining smartphone battery, you could just use IPv6 or set DF. I can't set DF for incoming packets, nor can I force use of IPv6 unless I disable my IPv4 address. >> I don't like that optimization. If you make a mess, IMO you should clean it up. > > I understand you have a preference and you do not like it. On the > other hand, it is still a valid case. It is documented, for example, in > the second para of S4.1.4 of RFC 3931 > http://tools.ietf.org/html/rfc3931#section-4.1.4 There are lots of things documented in many IETF protocols that aren't always the best way to do things. This may be just another good example of that. ... ... >> Here's the difference for GRE: >> >> - GRE adds N bytes total (GRE header + IP header) >> >> - GRE over IP supports 65536-byte packets >> >> So if a packet arrives that is smaller than 65536-N, IMO GRE ought to fragment and reassemble it. >> >> If a packet arrives that is larger than that, then GRE *cannot* tunnel it, and *MUST* drop it and sent a PTB. >> >> I.e., only 65536 is "too big". Everything else is just whining about "bigger than I want it to be" ;-) > > [For scope, this is an IPv4 discussion; with IPv4, the mechanism for this is to set DF.] DF means "don't fragment this packet and deliver the fragments". It's always the choice of a capable link layer to fragment and then reassemble packets. E.g., DF=1 can go over ATM cells just fine; ATM fragments and reassembles the packet within ATM. A tunnel ought to behave the same way. The exception is when the tunnel - or link - cannot fragment and reassemble. That's when the source should drop and send PTB. > If DF is not set, which specification defines that a packet cannot > befragmented? Nothing says you cannot; I claim that you should not unless you HAVE to. Tunnels like GRE don't have to. > It really is a trade-off; and as such, IMHO, there is not > one-size-fits-all but there are deployment decisions and practices. > >>>> Yes, this can cause repeated frag/reassembly, but the alternative is >>>> to shift work to the end host, which I think is inappropriate. >>> >>> I do not understand why it is "inappropriate" -- when thinking of the >>> tunnel as a link. >> >> See above. > > I am still not sure how "inappropriate" is a technical term. I do > understand your preference and I do follow the logic. My point is that > it does not seem to be a mandated behavior by a spec., and seems to be a > trade-off to be documented with pros and cons for this case. The spec for DF behavior has a purpose - when DF=1, it's to help endpoints discover ways to adjust their MTU so packets can traverse links that *cannot* otherwise be traversed by larger packets. When DF=0, it's to help endpoints traverse paths by allowing a packet that *cannot* traverse a link to be broken down and reassembled at the destination. Nothing about DF says "hey, fragment anytime you feel like it". RFC1812 in specific says you're not supposed to fragment unless you have to. (that's the relevant RFC from the viewpoint of the traversing packet - the tunnel looks like a link to a router). My complaint for GRE is that there are two different MTUs - a 'native' MTU that may describe efficiency but does NOT limit traversal, and an true MTU (payload - N, where N is the size of the GRE+IP header). Using the latter is the only one that complies with RFC1812. > Let me try a different example, and let me know which step you disagree with :-) > > 0. GRE Tunnel between R1 and R2, tunneling IPv4 from end hosts. OK. > 1. The delivery (encapsulating) header sets DF (as allowed by > RFC791,for example because R2 does not have sufficient resources to reassemble > internet fragments.) This is the incorrect step; either DF=0 for IPv4 in general, or DF=1 and you run PLMTUD so you can generate (outer) fragments that will traverse the path correctly (e.g., as would be needed for IPv6, but would also be useful for IPv4). > 2. The GRE Tunnel is realized as a logical interface. Sure. > 3. A 2000 octet IPv4 datagram from an end host has the GRE tunnel as > the next-hop; R1 encapsulates in GRE, then IPv4 with DF set, and then > when trying to send the datagram sees that it is larger than the > physical MTU of the out interface. There are two cases: - you are running PLMTUD in background, at which point you already knew this was going to happen at the GRE ingress, and you should have fragmented correctly at the ingress (IPv6-like situation) or - your ingress should have set DF=0 > 4. R1 sends an ICMPv4 PTB to itself and drops the datagram, and the tunnel learns its MTU. Only if the ICMP error is correctly received. > 5. Another datagram is received for the tunnel, with the DF bit > clear,what should R1 do? -> fragment the encapsulated packet and encapsulate it. It should have done the same thing with both packets. >>> There is also a potential mischaracterization when you say "shift work >>> to the end host", because that can lead to assumptions that there is "a >>> single" end host (singular). In the case of a p2p tunnel, the challenge >>> is that there is a single pair of endpoints in the tunnel, but a >>> multitude of hosts behind and before them. A different view would be >>> that it's more efficient to distribute reassembly to many endpoints >>> instead of attacking the tunnel tailend and making it work on behalf of >>> many hosts/ >> >> It would be an attack, except that you're talking about a tunnel. >> Atunnel is an ingress and an egress. Are you suggesting that making an >> egress do its job is an "attack"? > > A different perspective: If the tunnel is a link in a logical > topology, then this preference would be equivalent to asking every link > to perform data-link-level fragmentation and reassembly and allow any > size packets. Up to the size it *cannot* handle as payload, yes. Joe From rbonica@juniper.net Wed Jun 5 10:01:13 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2D921F9A1A for ; Wed, 5 Jun 2013 10:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.467 X-Spam-Level: X-Spam-Status: No, score=-100.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTspcGpab82Q for ; Wed, 5 Jun 2013 10:01:07 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB1E21F9A3C for ; Wed, 5 Jun 2013 10:01:07 -0700 (PDT) Received: from mail70-ch1-R.bigfish.com (10.43.68.235) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Wed, 5 Jun 2013 17:01:05 +0000 Received: from mail70-ch1 (localhost [127.0.0.1]) by mail70-ch1-R.bigfish.com (Postfix) with ESMTP id 401844800F0 for ; Wed, 5 Jun 2013 17:01:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: PS-29(zz98dI9371I936eI103dK148cI542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275ch1033IL17326ah8275dhz31h2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: softfail (mail70-ch1: transitioning domain of juniper.net does not designate 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=rbonica@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail70-ch1 (localhost.localdomain [127.0.0.1]) by mail70-ch1 (MessageSwitch) id 1370451662622769_10151; Wed, 5 Jun 2013 17:01:02 +0000 (UTC) Received: from CH1EHSMHS018.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.226]) by mail70-ch1.bigfish.com (Postfix) with ESMTP id 9427F80440 for ; Wed, 5 Jun 2013 17:01:02 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.50) by CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 5 Jun 2013 17:01:02 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 5 Jun 2013 10:01:02 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 5 Jun 2013 10:01:01 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.188) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 5 Jun 2013 10:12:37 -0700 Received: from mail128-co1-R.bigfish.com (10.243.78.240) by CO1EHSOBE030.bigfish.com (10.243.66.95) with Microsoft SMTP Server id 14.1.225.23; Wed, 5 Jun 2013 17:01:00 +0000 Received: from mail128-co1 (localhost [127.0.0.1]) by mail128-co1-R.bigfish.com (Postfix) with ESMTP id 6BEB63E0439 for ; Wed, 5 Jun 2013 17:01:00 +0000 (UTC) Received: from mail128-co1 (localhost.localdomain [127.0.0.1]) by mail128-co1 (MessageSwitch) id 1370451658474499_18718; Wed, 5 Jun 2013 17:00:58 +0000 (UTC) Received: from CO1EHSMHS007.bigfish.com (unknown [10.243.78.242]) by mail128-co1.bigfish.com (Postfix) with ESMTP id 677E574004D; Wed, 5 Jun 2013 17:00:58 +0000 (UTC) Received: from BY2PRD0512HT004.namprd05.prod.outlook.com (157.56.238.5) by CO1EHSMHS007.bigfish.com (10.243.66.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 5 Jun 2013 17:00:55 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.27]) by BY2PRD0512HT004.namprd05.prod.outlook.com ([10.255.243.37]) with mapi id 14.16.0311.000; Wed, 5 Jun 2013 17:00:55 +0000 From: Ronald Bonica To: "Carlos Pignataro (cpignata)" Thread-Topic: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt Thread-Index: AQHOX8a3wS1s6Fkp8ki4KgulZKiiupknXJGw Date: Wed, 5 Jun 2013 17:00:55 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2509F3F16A@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> <95067C434CE250468B77282634C96ED322BD8926@xmb-aln-x02.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED322BD8926@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: Internet Area Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 17:01:13 -0000 Carlos, Thanks for this thoughtful review. All comments accepted. Expect an updated= version of the draft next week. Ron > -----Original Message----- > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > Sent: Sunday, June 02, 2013 3:23 PM > To: Ronald Bonica > Cc: Internet Area > Subject: Re: [Int-area] New Version Notification for draft-bonica- > intarea-gre-mtu-00.txt >=20 > Hi Ron, >=20 > Thanks for writing this, and for sending it for review to this list. >=20 > Please find my review below, which includes sets of comments and > suggestions organized as more substantive / more editorial and prefaced > with "CMP:". Hope these are clear and useful, and glad to iterate on > them. >=20 >=20 > More Substantive: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Generic Routing Encapsulation (GRE) Fragmentation Strategy >=20 > Abstract >=20 > This memo documents a GRE fragmentation strategy upon which many > vendors have converged. Specifically, it defines procedures to be > executed by GRE ingress routers. It is published so that those > ... >=20 > CMP: The focus of this document is only point-to-point GRE tunnels, > CMP: and does not include any type of Multipoint GRE tunnels. As such, > CMP: I would make this focus explicit in the Abstract, Intro, and in > CMP: the document title. >=20 > 1. Problem Statement > ... > However, implementors and network operators have discovered that > some > fragmentation strategies work better than others. A poorly chosen > fragmentation strategy can cause operational issues, including > black- > holing, packet reassembly on GRE egress routers and unexpected > interactions with Path MTU Discovery [RFC1191] [RFC1981]. >=20 > CMP: A big part of a generic discussion of this takes place in RFC > 4459. > CMP: That's an informational document, that would make of a great > CMP: Informational pointer since Section 3 of RFC 4459 contrasts > CMP: different approaches. >=20 > 1.1. How To Use This Document >=20 > This memo is presented in sections. Section 2 enumerates design > goals. Section 3 defines procedures that all GRE ingress routers > must execute. >=20 > CMP: The impact of this "must" is not clear to me; please see below the > CMP: comments on that section. >=20 > 1.2. Terminology >=20 > The following terms are specific MTU discovery: >=20 > o link MTU (LMTU) - the maximum transmission unit, i.e., maximum > packet size in octets, that can be conveyed over a link without > fragmentation >=20 > o path MTU (PMTU) - the minimum LMTU of all the links in a path > between a source node and a destination node >=20 > CMP: There are two specific clarifications that are important here, I > CMP: believe: i. PMTU is unidirectional, and on a per-direction. So > CMP: in this case is the LMTU from source to destination. ii. there > CMP: is not necessarily "a path", but likely there are multi-paths. > CMP: so given ECMP, this needs to clarify it is of all paths from > CMP: source to sink (and not *the* path *between* source and sink). >=20 >=20 > 3.2. Tunnel MTU (TMTU) Discovery >=20 > Implementations MUST maintain a local data structure that reflects > the TMTU of each GRE tunnel that originates on the node. The TMTU > MUST be equal to the PMTU associated with the path between the > tunnel > ingress and the tunnel egress, minus the GRE overhead. >=20 > CMP: This "MUST" is only applicable when PMTUD is in effect, which is > CMP: not a MUST for this scenario. I would condition the MUST to "when > CMP: PMTUD is being used for the tunnel". For completeness, an > editorial: > CMP: The way the first sentence is written appears to be too > restrictive > CMP: of how to implement TMTU. The TMTU can be kept as an element in > the > CMP: existing data structures hosting tunnel endpoint state. >=20 > By default, implementations MUST discover the PMTU associated with > the path between the tunnel ingress and the tunnel egress. PMTU > discovery procedures defined in [RFC1191] and [RFC1981] and will > never permit the PMTU to exceed the LMTU associated with the first > IP > hop in the path to the tunnel egress. >=20 > CMP: This MUST seems too strict to me. For example, for cases in which > CMP: ICMPs are blocked between the source and destination of the GRE > CMP: tunnel, this requirement can lead to black-holing (instead of > CMP: suboptimal performance at the destination GRE endpoint), and the > CMP: medicine would be worst than the sickness. Or put a different way, > CMP: PMTUD MUST work for this to be a MUST -- however, it is impossible > CMP: to ensure PMTUD MUST work if ICMP 3/4s are blocked. And there is > CMP: no (to my knowledge) PL-PMTUD defined for GRE -- only for TCP. > CMP: > CMP: A nit as well: This is not necessarily a LMTU, but in the case of > CMP: ECMP in the first hop, this is the smallest of the LMTUs > associated > CMP: with the paths... >=20 > However, implementations MUST include a configuration option that > disables PMTU Discovery for GRE tunnels. This configuration option > may be required to mitigate certain denial of service attacks (see > Section 7). When PMTU discovery for GRE tunnels is disabled, the > TMTU for a tunnel MUST default to the LMTU associated with the first > IP hop in the path to the tunnel egress, minus the GRE overhead. > However, implementations MAY include a configuration option through > which the TMTU can be set to another value, which is likely to be > lower. >=20 > CMP: This is good for the case of a single GRE tunnel, but it changes > CMP: if the GRE tunnel is protected with IPsec -- unless, the IPsec > CMP: overhead is somehow counted towards the "GRE Delivery Header". >=20 > CMP: I believe there is another key requirement for TMTUD for IPv4: the > CMP: configurability of how to set the DF-bit in the Delivery Header. > CMP: Specifically, the DF can be copied from the tunneled packet (if > v4) > CMP: or it can always be set. RFC 2003 (which should also be an Info > CMP: pointer) allows for both. A discussion on why setting DF helps > CMP: speed up the convergence of PMTUD (and consequently of TMTUD) > CMP: would also operators. And a requirement needs to exist for the > CMP: ability to configure this behavior. >=20 > CMP: Actually, on third important point as well :-) For PMTUD for GRE > CMP: and TMTUD, when the GRE Tunnel uses GRE Keys, then the Key > CMP: included in the embedded packet of the ICMP PTB should be checked > CMP: against the configured/used Key in the GRE Tunnel (like with TCP). > CMP: This needs to be called out also in the Security Considerations. >=20 >=20 > 4.1. Tunneling GRE Over IPv4 >=20 >=20 > When the GRE ingress router tunnels an IPv4 payload over IPv4, and > the DF Bit in the payload header is set to 0 (May Fragment), by > default, the GRE ingress router MUST set the DF bit in the delivery > header to 1. However, implementations MAY include a configuration > option that allows the DF bit to be copied from the payload header > to > the delivery header. >=20 > CMP: Wouldn't this be updating RFC 2003? It seems to me that a MUST is > CMP: too strong of a requirement. I can see providing a RECOMMENDED, > CMP: perhaps. >=20 > The GRE ingress router MUST NOT emit a delivery header in which the > MF bit is set to 1 (More Fragments). >=20 >=20 > CMP: Similarly, this MUST NOT seems too limiting (as per the > explanation > CMP: above). It seems to me that the success of PMTUD with ICMP being > CMP: best effort delivery is not one to underpin this hard requirement. >=20 >=20 > 5.1. IPv4 Payloads >=20 > If the DF bit in the payload header is set to 1 (Don't Fragment), > the > GRE ingress router MUST discard the packet and sent an ICMPv4 > [RFC0792] Destination Unreachable message to the payload source, > with > type equal to 4 (fragmentation needed and DF set). The ICMP > Destination Unreachable message MUST contain an Next-hop MTU (as > specified by [RFC1191]) and the next-hop MTU MUST be equal to the > TMTU associated with the tunnel. >=20 > CMP: This is perfect, but for the case in which PMTUD and TMTUD are on. > CMP: This section should condition the requirements to that (because > CMP: it is assuming it is always on). > CMP: I do believe strongly that this is doing the right thing, BTW. I > CMP: am not sure, though, if we can always REQUIRE this. >=20 >=20 > 5.3. MPLS Payloads >=20 > The GRE ingress router MUST discard the packet. As it is impossible > to reliably identify the payload source, the GRE ingress router MUST > NOT attempt to send an ICMPv4 Destination Unreachable message or an > ICMPv6 Packet Too Big message to the payload source. >=20 > CMP: This is a most serious concern, because mandating PMTUD/TMTUD ( > CMP: the MUST in Section 3.2, 5.1, etc.) without a way to fragment, > CMP: and without a way to signal to the source (e.g., ICMP PTB for IP), > CMP: since in the MPLS case there is no source with merging, then this > CMP: "MUST" effectively creates a permanent black-hole for MPLS over > GRE. > CMP: > CMP: Also, I would change this to say something like: if it can be > CMP: reliably determined that the payload of the MPLS packet is IPv4, > CMP: then it can be prefragged and copy the MPLS header to all > fragments, > CMP: quite efficiently. >=20 > 7. Security Considerations >=20 > CMP: see comment about about the security consideration of ICMP > spoofing. > CMP: This attack is such that makes it hard to justify a "MUST have > PMTUD > CMP: enabled by default" in this document. >=20 >=20 > 7.2. Attacks Against PMTU Discovery >=20 > PMTU Discovery is vulnerable to two denial of service attacks (see > Section 8 of [RFC1191] for details). Both attacks are based upon on > a malicious party sending forged ICMPv4 Destination Unreachable or > ICMPv6 Packet Too Big messages to a host. In the first attack, the > forged message indicates an inordinately small PMTU. In the second > attack, the forged message indicates an inordinately large MTU. In > both cases, throughput is adversely affected. On order to mitigate > such attacks, GRE implementations MUST include a configuration option > to disable PMTU discovery on GRE tunnels. >=20 > CMP: Lastly, in addition (and better sometimes) than just disable > PMTUD, > CMP: a tunnel endpoint should provide the configuration option to set > CMP: the minimum TMTU that can be set as a result to ICMP PTB. This > CMP: is to protect against the case of an ICMP PTB with too small MTU. >=20 >=20 > More Editorial: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Abstract >=20 > This memo documents a GRE fragmentation strategy upon which many > vendors have converged. >=20 > CMP: This is not "GRE fragmentation" (i.e., which strictly is having > CMP: things like "B" and "E" fragmentation bits in the GRE header. > CMP: THis is a nit, but just for clarity (given that this topic can be > CMP: confusing), I'd use something like "fragmentation in GRE point-to- > CMP: point tunnel scenarios". >=20 > 1. Problem Statement > ... > However, implementors and network operators have discovered that > some > fragmentation strategies work better than others. A poorly chosen > fragmentation strategy can cause operational issues, including > black- > holing, packet reassembly on GRE egress routers and unexpected > interactions with Path MTU Discovery [RFC1191] [RFC1981]. >=20 > CMP: I would add here a pointer to the discussion in Section 4.1.4 of > CMP: RFC 3931 as part of the discussion there is applicable to other > CMP: p2p tunnels. This is an Informational pointer. >=20 >=20 > 1.1. How To Use This Document >=20 > Section 4 defines procedures affecting generation of the GRE > delivery > header. It is divided into two subsections. Section 4.1 is > applicable when GRE is tunneled over IPv4[RFC0791] and Section 4.2 > is > applicable when GRE is tunneled over IPv6 [RFC2460]. >=20 > CMP: Another nit, since the rest of the doc does such a good job at > CMP: being precise with terminology: GRE is not "tunneled" over IP. It > CMP: is "delivered". >=20 >=20 > 1.2. Terminology >=20 > The following terms are specific to GRE and are taken from > [RFC2784]: >=20 > o GRE delivery header - an IPv4 or IPv6 header whose source address > is that of the GRE tunnel ingress and whose destination address > is > that of the GRE tunnel egress. The GRE delivery header > encapsulates a GRE header. >=20 > CMP: This, again, describes a p2p GRE tunnel. Multipoint flavors should > CMP: be explicitly out of scope. >=20 > o GRE payload - a network layer packet that is encapsulated by the > GRE header. The GRE payload can be IPv4, IPv6 or MPLS. >=20 > CMP: ... "or other. This document only covers IPv4, IPv6, and MPLS > only." >=20 >=20 >=20 >=20 > Thanks! >=20 > -- Carlos. >=20 > On May 29, 2013, at 9:36 AM, Ronald Bonica wrote: >=20 > > Folks, > > > > If you get a chance, please provide a sanity check on this document. > It is very short, so it won't take much time to review. > > > > Ron > > > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Wednesday, May 29, 2013 9:34 AM > >> To: Ronald Bonica > >> Subject: New Version Notification for draft-bonica-intarea-gre-mtu- > >> 00.txt > >> > >> > >> A new version of I-D, draft-bonica-intarea-gre-mtu-00.txt > >> has been successfully submitted by Ron Bonica and posted to the IETF > >> repository. > >> > >> Filename: draft-bonica-intarea-gre-mtu > >> Revision: 00 > >> Title: Generic Routing Encapsulation (GRE) Fragmentation > >> Strategy > >> Creation date: 2013-05-29 > >> Group: Individual Submission > >> Number of pages: 8 > >> URL: http://www.ietf.org/internet-drafts/draft-bonica- > >> intarea-gre-mtu-00.txt > >> Status: http://datatracker.ietf.org/doc/draft-bonica- > intarea- > >> gre-mtu > >> Htmlized: http://tools.ietf.org/html/draft-bonica-intarea- > gre- > >> mtu-00 > >> > >> > >> Abstract: > >> This memo documents a GRE fragmentation strategy upon which many > >> vendors have converged. Specifically, it defines procedures to be > >> executed by GRE ingress routers. It is published so that those > >> building new implementations will be aware of best common > practice. > >> It is also published so that those building applications over GRE > >> will understand how GRE works. > >> > >> > >> > >> > >> > >> The IETF Secretariat > >> > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > >=20 >=20 From mohamed.boucadair@orange.com Fri Jun 7 05:49:08 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DECD21F9248; Fri, 7 Jun 2013 05:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFHAmVBuNCpR; Fri, 7 Jun 2013 05:49:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB9321F8667; Fri, 7 Jun 2013 05:49:04 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 7F4FA324618; Fri, 7 Jun 2013 14:49:03 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 5E92A35C055; Fri, 7 Jun 2013 14:49:03 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Fri, 7 Jun 2013 14:49:03 +0200 From: To: "Dirk.von-Hugo@telekom.de" , "jshire@hyduke.com" , "fmc@ietf.org" , "int-area@ietf.org" Date: Fri, 7 Jun 2013 14:49:02 +0200 Thread-Topic: draft-boucadair-intarea-host-identifier-scenarios Thread-Index: Ac5LMjyqGqkODLucTvmk2Pl+E8NMBwRSW5PQAcA/rRA= Message-ID: <94C682931C08B048B7A8645303FDC9F36ED58ED02C@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36ECE1436BE@PUEXCB1B.nanterre.francetelecom.fr> <05C81A773E48DD49B181B04BA21A342A2BBFB11613@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2BBFB11613@HE113484.emea1.cds.t-internal.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Cc: "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" Subject: Re: [Int-area] draft-boucadair-intarea-host-identifier-scenarios X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 12:49:08 -0000 Hi Dirk, NAT46 is not mentioned in the document because it not a scenario of high pr= iority (please refer to behave WG charter for instance).=20 Saying that, I don't think we need to be exhaustive in listing all NAT flav= ors there; what is important is to characterize the use case. Cheers, Med=20 >-----Message d'origine----- >De=A0: Dirk.von-Hugo@telekom.de [mailto:Dirk.von-Hugo@telekom.de] >Envoy=E9=A0: mercredi 29 mai 2013 17:11 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN; jshire@hyduke.com; fmc@ietf.org; int- >area@ietf.org >Cc=A0: draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org >Objet=A0: RE: draft-boucadair-intarea-host-identifier-scenarios > >Hi Med, all, >I see also the section 3.7 on femto cells with high security demands for >tunneled (mobile) data via IPSec through the fixed network. > >Another question is whether to include also a scenario for NAT46 addressin= g >IPv4 clients at end user nodes connected to both IPv6 RGW and IPv6 access >network? I think while many operators are starting to deploy IPv6 in thei= r >core and aggregation networks there will always be (maybe old fashioned) >customers which continue to use their available equipment, e.g. for >telephony. >Perhaps this is already handled, e.g. in UC 3.6, but I couldn't find NAT46 >to be mentioned. Did I miss something? > >What do you think? >Thanks! > >Best regards >Dirk >-----Original Message----- >From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of >mohamed.boucadair@orange.com >Sent: Dienstag, 7. Mai 2013 16:51 >To: 'Joshua Shire'; fmc@ietf.org; int-area@ietf.org >Cc: draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org >Subject: Re: [fmc] draft-boucadair-intarea-host-identifier-scenarios > >Dear Joshua, > >Apologies for the delay to answer this message. > >I see your point. I will add it to the list of items to be considered for >the next iteration of the document. > >BTW, -03 already included some of requirements which cover security aspect= s >(see for instance REQ#1, REQ#2, REQ#3, REQ#9). Once we have a stable >requirements list, we will identify the requirements which are valid for >each use case: http://tools.ietf.org/html/draft-boucadair-intarea-host- >identifier-scenarios-03#section-4.1 > >Cheers, >Med > >>-----Message d'origine----- >>De : Joshua Shire [mailto:jshire@hyduke.com] >>Envoy=E9 : vendredi 25 janvier 2013 08:17 >>=C0 : BOUCADAIR Mohamed OLNC/OLN; fmc@ietf.org; int-area@ietf.org >>Cc : draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org >>Objet : RE: draft-boucadair-intarea-host-identifier-scenarios >> >>Hello, >> >>I do not believe a pointer to >>http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analys >>is-04#section-3 will be satisfactory for the security >>considerations section. >> >>http://www.ietf.org/rfc/rfc3552.txt states that when writing >>a security considerations section, the process "...should be >>approached as an effort to perform "due diligence" in >>describing all known or foreseeable risks and threats to >>potential implementers and users." Normally we see RFCs >>describing more applied topics such as protocols, so the >>specific language and examples given in the above mentioned >>RFC may not seem directly applicable. However, "in spirit", >>the document seems clear in requiring all RFCs to examine in >>detail their potential security impact. >> >>As I'm sure we're all aware, some of the use cases identified >>are purposefully implemented to maintain the confidentiality >>of a client's identity (e.g. NAT to obfuscate the structure of >>an enterprise network, Open-Wifi to conceal the identity of a >>client under threat of persecution [or prosecution], etc.). >> >>Thus, in identifying these scenarios as sharing the "issue" of >>host identification, the author would seem to be required to >>discuss the potential security implications of treating the >>lack of host identification as such, rather than a desirable feature. >> >>Thanks, >> >>Joshua Shire >>Information Systems Manager >>Hyduke Energy Services Inc. >> >>-----Original Message----- >>From: int-area-bounces@ietf.org >>[mailto:int-area-bounces@ietf.org] On Behalf Of >>mohamed.boucadair@orange.com >>Sent: Monday, December 03, 2012 2:08 AM >>To: fmc@ietf.org; int-area@ietf.org >>Cc: draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org >>Subject: [Int-area] draft-boucadair-intarea-host-identifier-scenarios >> >>Dear all, >> >>We submitted an updated version of this draft to list use >>cases which encounter the issue of host identification. The >>following use cases are discussed in the draft: >> >> (1) Carrier Grade NAT (CGN) >> (2) A+P (e.g., MAP ) >> (3) Application Proxies >> (4) Provider Wi-Fi >> (5) Policy and Charging Architectures >> (6) Cellular Networks >> (7) Femtocells >> (8) Overlay Networks (e.g., CDNs) >> >>The document does not include any solution-specific >>discussion. Its main goal is to identify the use cases and >>describe them. >> >>If you think your use case is not included in this version, >>please share it with us. >> >>Comments are welcome. >> >>Cheers, >>Med >> >> >>-----Message d'origine----- >>De : i-d-announce-bounces@ietf.org >>[mailto:i-d-announce-bounces@ietf.org] De la part de >>internet-drafts@ietf.org Envoy=E9 : lundi 3 d=E9cembre 2012 08:26 >>=C0 : i-d-announce@ietf.org Objet : I-D Action: >>draft-boucadair-intarea-host-identifier-scenarios-02.txt >> >> >>A New Internet-Draft is available from the on-line >>Internet-Drafts directories. >> >> >> Title : Host Identification: Use Cases >> Author(s) : Mohamed Boucadair >> David Binet >> Sophie Durel >> Tirumaleswar Reddy >> Brandon Williams >> Filename : >>draft-boucadair-intarea-host-identifier-scenarios-02.txt >> Pages : 14 >> Date : 2012-12-02 >> >>Abstract: >> This document describes a set of scenarios in which host >> identification is required. >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-boucadair-intarea-host-i >>dentifier-scenarios >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-boucadair-intarea-host-identif >>ier-scenarios-02 >> >>A diff from the previous version is available at: >>http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-intarea-host-i >>dentifier-scenarios-02 >> >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>I-D-Announce mailing list >>I-D-Announce@ietf.org >>https://www.ietf.org/mailman/listinfo/i-d-announce >>Internet-Draft directories: http://www.ietf.org/shadow.html or >>ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>_______________________________________________ >>Int-area mailing list >>Int-area@ietf.org >>https://www.ietf.org/mailman/listinfo/int-area >> >_______________________________________________ >fmc mailing list >fmc@ietf.org >https://www.ietf.org/mailman/listinfo/fmc From touch@isi.edu Wed Jun 12 10:07:36 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E8E21F9ACC; Wed, 12 Jun 2013 10:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.966 X-Spam-Level: X-Spam-Status: No, score=-102.966 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4TKu7vXV+cl; Wed, 12 Jun 2013 10:07:30 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id E9B4321F9A7A; Wed, 12 Jun 2013 10:07:29 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5CH71W2013936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 10:07:01 -0700 (PDT) Message-ID: <51B8AAA7.3020909@isi.edu> Date: Wed, 12 Jun 2013 10:06:47 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Fernando Gont , Internet Area References: <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> In-Reply-To: <51B867C8.8010100@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Mark Andrews Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:07:36 -0000 Cc'd to INTAREA, where I believe fundamental changes to IP should be discussed: On 6/12/2013 5:21 AM, Fernando Gont wrote: > On 06/12/2013 02:37 AM, Mark Andrews wrote: >> The obvious limit is no re-assembly required to find the L4 header. > > That's already in draft-ietf-6man-oersized-header-chain Why is that not being reviewed in INTAREA? This isn't a 6man issue: It is not chartered to develop major changes or additions to the IPv6 specifications Further, at best, 2460 should say that the first fragment should include everything up to and including the fragment header. However, anything other than that wouldn't reassemble, so it's a self-correcting implementation error. EVERYTHING that IP *needs* to examine is before the frag header; that's already in 2460. Joe From touch@isi.edu Wed Jun 12 10:45:14 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E28C11E80F9; Wed, 12 Jun 2013 10:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJidhS5Yvbjo; Wed, 12 Jun 2013 10:45:08 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 524C821F99C1; Wed, 12 Jun 2013 10:45:08 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5CHilFi025683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 10:44:47 -0700 (PDT) Message-ID: <51B8B381.6090609@isi.edu> Date: Wed, 12 Jun 2013 10:44:33 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Fernando Gont References: <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <51B8B1A4.90702@si6networks.com> In-Reply-To: <51B8B1A4.90702@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Mark Andrews Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:45:14 -0000 On 6/12/2013 10:36 AM, Fernando Gont wrote: > On 06/12/2013 07:06 PM, Joe Touch wrote: >> Cc'd to INTAREA, where I believe fundamental changes to IP should be >> discussed: > > I disagree. This is nto a fundamental change, but rather a deployment > issue, well within the charter. See: It can't be just a deployment issue if it updates 2460 to change how fragmentation works. > The 6man working group is responsible for the maintenance, upkeep, > and advancement of the IPv6 protocol specifications and addressing > architecture. It is not chartered to develop major changes or > additions to the IPv6 specifications. IPv6 already puts all the per-hop information before the fragmentation header. Requiring the entire header chain to be inside the first fragment is, IMO, a major change. Joe From fgont@si6networks.com Wed Jun 12 10:47:56 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB9311E80F7; Wed, 12 Jun 2013 10:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIz6MNdltgOu; Wed, 12 Jun 2013 10:47:56 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 246E011E80E6; Wed, 12 Jun 2013 10:47:56 -0700 (PDT) Received: from [2001:5c0:1400:a::391] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Ump96-0005wZ-S2; Wed, 12 Jun 2013 19:47:44 +0200 Message-ID: <51B8B43E.3070103@si6networks.com> Date: Wed, 12 Jun 2013 19:47:42 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Joe Touch References: <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <51B8B1A4.90702@si6networks.com> <51B8B381.6090609@isi.edu> In-Reply-To: <51B8B381.6090609@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Mark Andrews Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:47:57 -0000 On 06/12/2013 07:44 PM, Joe Touch wrote: >> >> I disagree. This is nto a fundamental change, but rather a deployment >> issue, well within the charter. See: > > It can't be just a deployment issue if it updates 2460 to change how > fragmentation works. It doesn't change how fragmentation works. It just clarifies a corner case which was allowed by the standard, but is not employed in practice, and none expected to happen. >> The 6man working group is responsible for the maintenance, upkeep, >> and advancement of the IPv6 protocol specifications and addressing >> architecture. It is not chartered to develop major changes or >> additions to the IPv6 specifications. > > IPv6 already puts all the per-hop information before the fragmentation > header. Requiring the entire header chain to be inside the first > fragment is, IMO, a major change. I guess we must agree to disagree. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From touch@isi.edu Wed Jun 12 10:59:40 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE0B21F8F5C; Wed, 12 Jun 2013 10:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.934 X-Spam-Level: X-Spam-Status: No, score=-104.934 tagged_above=-999 required=5 tests=[AWL=1.665, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsWaMfk6nR2o; Wed, 12 Jun 2013 10:59:17 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4F621F9952; Wed, 12 Jun 2013 10:59:16 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r5CHwRuX022846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 10:58:27 -0700 (PDT) Message-ID: <51B8B6C9.2020606@isi.edu> Date: Wed, 12 Jun 2013 10:58:33 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Gert Doering References: <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <20130612174908.GT2504@Space.Net> In-Reply-To: <20130612174908.GT2504@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:59:40 -0000 On 6/12/2013 10:49 AM, Gert Doering wrote: > Hi, > > On Wed, Jun 12, 2013 at 10:06:47AM -0700, Joe Touch wrote: >> EVERYTHING that IP *needs* to examine is before the frag header; that's >> already in 2460. > > And *this* is why IETF is still producing documents that vendors can not > implement. Loop back to about 50 messages earlier in this thread, thanks > so much. Loop back to the part where I pointed out that this is about competing business issues, not theory. > We're talking about > devices that can stand the heat out there Sounds like you're living in a tower much more fragile than ivory. If you want to stand the heat, build heat-proof stuff. Joe From touch@isi.edu Wed Jun 12 12:56:20 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD43A11E80F6; Wed, 12 Jun 2013 12:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.703 X-Spam-Level: X-Spam-Status: No, score=-102.703 tagged_above=-999 required=5 tests=[AWL=-0.704, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maHpRQnDuUfn; Wed, 12 Jun 2013 12:56:00 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 915A911E80F9; Wed, 12 Jun 2013 12:55:48 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5CJtDI3027759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 12:55:14 -0700 (PDT) Message-ID: <51B8D213.8040900@isi.edu> Date: Wed, 12 Jun 2013 12:54:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Robert Elz References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> In-Reply-To: <10707.1371062690@perseus.noi.kre.to> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 19:56:20 -0000 So let me get this straight: - operationally, it's appropriate to drop all fragments because they interfere with a router being efficient - operationally, it's appropriate to block ICMPs because they could interfere with network operation Sounds a lot like the Internet and its users are getting in the way of router vendors and their business model. Joe On 6/12/2013 11:44 AM, Robert Elz wrote: > Date: Wed, 12 Jun 2013 19:49:08 +0200 > From: Gert Doering > Message-ID: <20130612174908.GT2504@Space.Net> > > | Loop back to about 50 messages earlier in this thread, > > I don't generally read this list (any more) - just happened to see the > past hour's worth of messages, so I have no idea what was 50 messages > earlier, but ... > > | We're not talking ivory tower theoretical routers. We're talking about > | devices that can stand the heat out there, like "be able to apply different > | rate limiting classes to incoming BGP SYNs from trusted networks, and to > | ICMP packets from the world". This MUST be done by the hardware, and it > | MUST be able to look at *Layer 4* information. > > If that's the issue, then the routers should just be treating any packet with > a frag header like dirt. That's what they deserve. Lowest sched priority, > and most likely to be dropped. That's easy to accomplish in hardware (well > as easy as anything else that involves looking down header chains) > and perfectly acceptable - everyone knows that if one sends fragmented packets > performance goes out the window. Perfectly acceptable result, and no > changes at all to v6 specs are needed to get to that. > > On the other hand, if the real issue is firewalls, then there really should be > no issue at all - firewalls already need to be able to reassemble packet > chains, or they can't look inside TCP properly (as while no-one sane > would ever split tcp segments in weird places, hackers will if the firewalls > can't handle it properly). Reassembling IP frags is childs play compared > to reassembling tcp segments. > > Again, no need to change anything in the IPv6 specs. > > Lastly, this comment caught my eye ... > > fgont@si6networks.com said: > | It doesn't change how fragmentation works. It just clarifies a corner case > | which was allowed by the standard, but is not employed in practice, and none > | expected to happen. > > Huh? Is that really claimimng that no-one ever thought that the frag > header would be anywhere but last in the header chain? That would be > absurd. For one, in normal use, dest options should normally come > after a frag header, processing them before the packet is reassembled would > mean processing them before the packet is received correctly, which would be > 100% bogus (on the other hand, if options were even invented to allow the > sender some control over reassembly - perhaps to lower timeouts or something - > then a destopts header before the frag header would be rational.) > > Beyond that, I have had cases where a frag header before a routing header > made perfect sense - I know that routing headers are largely deprecated these > days, but before that, it was possible to send a fragmented packet over a > low MTU link, have it reassembled at the far side of that link, and then > the routing header (following the frag header) causes the packet to continue > over links with a larger MTU, so the penalties of fragmentation apply > only where they are really needed. What's more, for the remaining use of > routing headers (route opt for mobile IPv6) putting the frag header before > the routing header is also the sane way to run things (the routing header there > is really just a fancy destination option). > > Lastly, consider that most v6 headers are allowed to be larger than the > MTU of the most common links in the internet at the time (and for that > matter, still) and certainly larger than the required MTU for v6 links, and > ask yourself how that would make any sense at all if all headers are > required to be before the frag header. > > Leave the specs alone, header chanins can have headers (other than hop by > hop opts of course) in whatever order makes sense to the application that > needs to send those headers. No more rules. Just deal with it. > > kre > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fgont@si6networks.com Wed Jun 12 13:23:07 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDB611E80F0; Wed, 12 Jun 2013 13:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9zioF0K8RZC; Wed, 12 Jun 2013 13:23:06 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 8927011E80BA; Wed, 12 Jun 2013 13:23:05 -0700 (PDT) Received: from [2001:5c0:1400:a::323] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmrZN-0001Ya-Qq; Wed, 12 Jun 2013 22:23:01 +0200 Message-ID: <51B8D8A4.6030002@si6networks.com> Date: Wed, 12 Jun 2013 22:23:00 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Robert Elz References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> In-Reply-To: <10707.1371062690@perseus.noi.kre.to> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 20:23:07 -0000 On 06/12/2013 08:44 PM, Robert Elz wrote: > | We're not talking ivory tower theoretical routers. We're talking about > | devices that can stand the heat out there, like "be able to apply different > | rate limiting classes to incoming BGP SYNs from trusted networks, and to > | ICMP packets from the world". This MUST be done by the hardware, and it > | MUST be able to look at *Layer 4* information. > > If that's the issue, then the routers should just be treating any packet with > a frag header like dirt. That's not what the discussion is about. We're talking about long IPv6 header chains... which might not contain a fragment header (e.g., simply the fixed IPv6 header, plus one long (or a few) dest options header, and then the real payload). > That's what they deserve. Lowest sched priority, > and most likely to be dropped. That's easy to accomplish in hardware (well > as easy as anything else that involves looking down header chains) > and perfectly acceptable - everyone knows that if one sends fragmented packets > performance goes out the window. Perfectly acceptable result, and no > changes at all to v6 specs are needed to get to that. It is not quite acceptable if the specs say one thing, and the real world says another. > On the other hand, if the real issue is firewalls, then there really should be > no issue at all - firewalls already need to be able to reassemble packet > chains, There are stateless filters, too. > Lastly, this comment caught my eye ... > > fgont@si6networks.com said: > | It doesn't change how fragmentation works. It just clarifies a corner case > | which was allowed by the standard, but is not employed in practice, and none > | expected to happen. > > Huh? Is that really claimimng that no-one ever thought that the frag > header would be anywhere but last in the header chain? That would be > absurd. I have no idea what you're talking about. The current version of draft-ietf-6man-oversized-header-chain essentially bans packets such as thos in page 5 of Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Wed Jun 12 10:36:47 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134E411E80EC; Wed, 12 Jun 2013 10:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iszRpTjsmAkF; Wed, 12 Jun 2013 10:36:45 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA9611E80E3; Wed, 12 Jun 2013 10:36:45 -0700 (PDT) Received: from pd95c600c.dip0.t-ipconnect.de ([217.92.96.12] helo=[192.168.0.77]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmoyO-0005fP-Ig; Wed, 12 Jun 2013 19:36:41 +0200 Message-ID: <51B8B1A4.90702@si6networks.com> Date: Wed, 12 Jun 2013 19:36:36 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Joe Touch References: <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> In-Reply-To: <51B8AAA7.3020909@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 12 Jun 2013 13:24:02 -0700 Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Mark Andrews Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:36:47 -0000 On 06/12/2013 07:06 PM, Joe Touch wrote: > Cc'd to INTAREA, where I believe fundamental changes to IP should be > discussed: I disagree. This is nto a fundamental change, but rather a deployment issue, well within the charter. See: The 6man working group is responsible for the maintenance, upkeep, and advancement of the IPv6 protocol specifications and addressing architecture. It is not chartered to develop major changes or additions to the IPv6 specifications. The working group will address protocol limitations/issues discovered during deployment and operation. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From gert@space.net Wed Jun 12 10:49:12 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2731311E80F7 for ; Wed, 12 Jun 2013 10:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeeZAkgktpZs for ; Wed, 12 Jun 2013 10:49:11 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 035BE11E8101 for ; Wed, 12 Jun 2013 10:49:10 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 9095D609F8 for ; Wed, 12 Jun 2013 19:49:08 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 6259460849 for ; Wed, 12 Jun 2013 19:49:08 +0200 (CEST) Received: (qmail 9979 invoked by uid 1007); 12 Jun 2013 19:49:08 +0200 Date: Wed, 12 Jun 2013 19:49:08 +0200 From: Gert Doering To: Joe Touch Message-ID: <20130612174908.GT2504@Space.Net> References: <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51B8AAA7.3020909@isi.edu> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 12 Jun 2013 13:24:02 -0700 Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:49:12 -0000 Hi, On Wed, Jun 12, 2013 at 10:06:47AM -0700, Joe Touch wrote: > EVERYTHING that IP *needs* to examine is before the frag header; that's > already in 2460. And *this* is why IETF is still producing documents that vendors can not implement. Loop back to about 50 messages earlier in this thread, thanks so much. We're not talking ivory tower theoretical routers. We're talking about devices that can stand the heat out there, like "be able to apply different rate limiting classes to incoming BGP SYNs from trusted networks, and to ICMP packets from the world". This MUST be done by the hardware, and it MUST be able to look at *Layer 4* information. *sigh* And then people wonder why operators stop bothering with IETF processes. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From gert@space.net Wed Jun 12 11:30:07 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A099C11E80D5 for ; Wed, 12 Jun 2013 11:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, GB_AFFORDABLE=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdPTJ5QI6yi9 for ; Wed, 12 Jun 2013 11:30:07 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 09E9521F883B for ; Wed, 12 Jun 2013 11:30:06 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 404D260A14 for ; Wed, 12 Jun 2013 20:30:05 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 277ED609F0 for ; Wed, 12 Jun 2013 20:30:05 +0200 (CEST) Received: (qmail 76591 invoked by uid 1007); 12 Jun 2013 20:30:05 +0200 Date: Wed, 12 Jun 2013 20:30:05 +0200 From: Gert Doering To: Joe Touch Message-ID: <20130612183004.GU2504@Space.Net> References: <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <20130612174908.GT2504@Space.Net> <51B8B6C9.2020606@isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OP8LxFWJZDVUP7sm" Content-Disposition: inline In-Reply-To: <51B8B6C9.2020606@isi.edu> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 12 Jun 2013 13:24:02 -0700 Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Gert Doering Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 18:30:07 -0000 --OP8LxFWJZDVUP7sm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jun 12, 2013 at 10:58:33AM -0700, Joe Touch wrote: > > We're talking about > > devices that can stand the heat out there >=20 > Sounds like you're living in a tower much more fragile than ivory. >=20 > If you want to stand the heat, build heat-proof stuff. I'm not a vendor, so I can't build anything myself (not on a multi-10G scale, at least). I'd like to have my vendors build devices that are heat-proof, affordable, and still conform to specifications. Without resorting to "pick any two". Specifications that are just wildly decoupled from the world ("a router is a router and has no need to look at anything but the IP address of the destination") are not helping anyone. So I'm willing to take a vendor that is heat-proof, affordable, and violates fully idiotic use-cases=20 permitted by ivory tower computer scientists designing protocols with arbitrarily long linked lists in packet headers, with no upper bounds. People tell me that IPv6 is so much better than IPv4 because all the nice restructuring of the IPv6 headers. Well, yes. Vendors do build devices that can stand the heat for IPv4, but not for IPv6. Guess why. Yes,=20 because the new header structure is so great. (And the reason for that is not in all cases "because they have more experience building IPv4 boxes") Sorry for ranting. But IETF is asking for operator input, so maybe start listening to it. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --OP8LxFWJZDVUP7sm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQCVAwUBUbi+LKkuBuNlUUl1AQK/UQP/QldOm8CUcZVq2noRhPBrvAxs8BwgKb/t NN876flbZGbSrJs70cRKLYGB3KZOo2xjyTDaS49S12aMa5HoFEU7ZMv5CRlMU/BV r+9xIRr1+CXaDFAc28cGfRKUc/s0oVsUOil3uvVzoKrzMiNS6XAiVOSjGu9OzBca 9V8XJu3Ck+g= =3/c3 -----END PGP SIGNATURE----- --OP8LxFWJZDVUP7sm-- From kre@munnari.OZ.AU Wed Jun 12 11:46:34 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4712221E80AB; Wed, 12 Jun 2013 11:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.172 X-Spam-Level: X-Spam-Status: No, score=0.172 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2kqiMQM0ROG; Wed, 12 Jun 2013 11:46:29 -0700 (PDT) Received: from jade.coe.psu.ac.th (munnari.OZ.AU [202.29.151.3]) by ietfa.amsl.com (Postfix) with ESMTP id 5837E21E8099; Wed, 12 Jun 2013 11:46:26 -0700 (PDT) Received: from perseus.noi.kre.to (jade.coe.psu.AC.TH [IPv6:2001:3c8:9007:1::21]) by jade.coe.psu.ac.th with ESMTP id r5CIj4mP011156; Thu, 13 Jun 2013 01:45:04 +0700 (ICT) Received: from perseus.noi.kre.to (localhost [127.0.0.1]) by perseus.noi.kre.to (8.14.7/8.14.2) with ESMTP id r5CIioB7018951; Thu, 13 Jun 2013 01:44:55 +0700 (ICT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.5 From: Robert Elz To: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area In-Reply-To: <20130612174908.GT2504@Space.Net> References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Jun 2013 01:44:50 +0700 Message-ID: <10707.1371062690@perseus.noi.kre.to> X-Mailman-Approved-At: Wed, 12 Jun 2013 13:24:02 -0700 Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 18:46:34 -0000 Date: Wed, 12 Jun 2013 19:49:08 +0200 From: Gert Doering Message-ID: <20130612174908.GT2504@Space.Net> | Loop back to about 50 messages earlier in this thread, I don't generally read this list (any more) - just happened to see the past hour's worth of messages, so I have no idea what was 50 messages earlier, but ... | We're not talking ivory tower theoretical routers. We're talking about | devices that can stand the heat out there, like "be able to apply different | rate limiting classes to incoming BGP SYNs from trusted networks, and to | ICMP packets from the world". This MUST be done by the hardware, and it | MUST be able to look at *Layer 4* information. If that's the issue, then the routers should just be treating any packet with a frag header like dirt. That's what they deserve. Lowest sched priority, and most likely to be dropped. That's easy to accomplish in hardware (well as easy as anything else that involves looking down header chains) and perfectly acceptable - everyone knows that if one sends fragmented packets performance goes out the window. Perfectly acceptable result, and no changes at all to v6 specs are needed to get to that. On the other hand, if the real issue is firewalls, then there really should be no issue at all - firewalls already need to be able to reassemble packet chains, or they can't look inside TCP properly (as while no-one sane would ever split tcp segments in weird places, hackers will if the firewalls can't handle it properly). Reassembling IP frags is childs play compared to reassembling tcp segments. Again, no need to change anything in the IPv6 specs. Lastly, this comment caught my eye ... fgont@si6networks.com said: | It doesn't change how fragmentation works. It just clarifies a corner case | which was allowed by the standard, but is not employed in practice, and none | expected to happen. Huh? Is that really claimimng that no-one ever thought that the frag header would be anywhere but last in the header chain? That would be absurd. For one, in normal use, dest options should normally come after a frag header, processing them before the packet is reassembled would mean processing them before the packet is received correctly, which would be 100% bogus (on the other hand, if options were even invented to allow the sender some control over reassembly - perhaps to lower timeouts or something - then a destopts header before the frag header would be rational.) Beyond that, I have had cases where a frag header before a routing header made perfect sense - I know that routing headers are largely deprecated these days, but before that, it was possible to send a fragmented packet over a low MTU link, have it reassembled at the far side of that link, and then the routing header (following the frag header) causes the packet to continue over links with a larger MTU, so the penalties of fragmentation apply only where they are really needed. What's more, for the remaining use of routing headers (route opt for mobile IPv6) putting the frag header before the routing header is also the sane way to run things (the routing header there is really just a fancy destination option). Lastly, consider that most v6 headers are allowed to be larger than the MTU of the most common links in the internet at the time (and for that matter, still) and certainly larger than the required MTU for v6 links, and ask yourself how that would make any sense at all if all headers are required to be before the frag header. Leave the specs alone, header chanins can have headers (other than hop by hop opts of course) in whatever order makes sense to the application that needs to send those headers. No more rules. Just deal with it. kre From gert@space.net Wed Jun 12 13:40:25 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6F921E805D for ; Wed, 12 Jun 2013 13:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwF2wPmug1eD for ; Wed, 12 Jun 2013 13:40:25 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id E5C4211E80E7 for ; Wed, 12 Jun 2013 13:40:24 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 87C8B609F8 for ; Wed, 12 Jun 2013 22:40:22 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 6588660833 for ; Wed, 12 Jun 2013 22:40:22 +0200 (CEST) Received: (qmail 18173 invoked by uid 1007); 12 Jun 2013 22:40:22 +0200 Date: Wed, 12 Jun 2013 22:40:22 +0200 From: Gert Doering To: Joe Touch Message-ID: <20130612204022.GY2504@Space.Net> References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51B8D213.8040900@isi.edu> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 20:40:25 -0000 Hi, On Wed, Jun 12, 2013 at 12:54:59PM -0700, Joe Touch wrote: > So let me get this straight: > > - operationally, it's appropriate to drop all fragments because they > interfere with a router being efficient > > - operationally, it's appropriate to block ICMPs because they could > interfere with network operation > You're constructing something, that at least I never said. My router *has* to rate-limit ICMP packets that are directed at it, otherwise it's easy to nuke it away (unless I find a vendor that will give me a fully wirespeed control-plane...). But yeah, when I have to make a choice between "there is no way to make my router stand the heat but to make them unpingable", and "have it die the next time someone out there is bored", guess what my customers expect me to do (and even then, it might be necessary to be able to rate-limit BGP related packets at a different speed and using a different policer than "all the other packets that my router sees", so a pure ACL on IPv6 address without protocol/ports won't do the job) Now, having sanity in the standards - and I really like the idea of limiting the full chain of extention headers to some limit, like 256 bytes, which can then be implemented by the vendors taking my money - would help find some compromise that enables *some* flexibility, but at the same time helps me implement the necessary control in the network to make it work under adverse conditions. > Sounds a lot like the Internet and its users are getting in the way of > router vendors and their business model. No, more like "reality conflicting with the IETF model of defining beautiful things based on theoretical possibilities". Gert Doering -- operator -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From touch@isi.edu Wed Jun 12 13:51:09 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7266911E80FD; Wed, 12 Jun 2013 13:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.975 X-Spam-Level: X-Spam-Status: No, score=-104.975 tagged_above=-999 required=5 tests=[AWL=1.624, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsYSTBniyMGP; Wed, 12 Jun 2013 13:51:03 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 32A4711E80CC; Wed, 12 Jun 2013 13:50:59 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r5CKneSp028661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 13:49:40 -0700 (PDT) Message-ID: <51B8DED6.9030306@isi.edu> Date: Wed, 12 Jun 2013 13:49:26 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Gert Doering References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> In-Reply-To: <20130612204022.GY2504@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 20:51:09 -0000 FWIW, I wouldn't mind: - IPv6 *should* limit its header chains to (some reasonable limit) What I expect when that's not the case: - SOME packets get through, perhaps more slowly - when the router can't keep up, it can drop the overload This isn't any different from many other things, e.g., when a router can't keep up with IPv6 packets that overload an egress. However, anything that says "if the chain is >X, then drop" is broken, period. At some point, if you want to play "IPv6 router", you need to earn the title. Joe On 6/12/2013 1:40 PM, Gert Doering wrote: > Hi, > > On Wed, Jun 12, 2013 at 12:54:59PM -0700, Joe Touch wrote: >> So let me get this straight: >> >> - operationally, it's appropriate to drop all fragments because they >> interfere with a router being efficient >> >> - operationally, it's appropriate to block ICMPs because they could >> interfere with network operation >> > > You're constructing something, that at least I never said. > > My router *has* to rate-limit ICMP packets that are directed at it, > otherwise it's easy to nuke it away (unless I find a vendor that will > give me a fully wirespeed control-plane...). But yeah, when I have > to make a choice between "there is no way to make my router stand the > heat but to make them unpingable", and "have it die the next time > someone out there is bored", guess what my customers expect me to do > (and even then, it might be necessary to be able to rate-limit BGP > related packets at a different speed and using a different policer than > "all the other packets that my router sees", so a pure ACL on IPv6 > address without protocol/ports won't do the job) > > Now, having sanity in the standards - and I really like the idea of > limiting the full chain of extention headers to some limit, like 256 > bytes, which can then be implemented by the vendors taking my money - > would help find some compromise that enables *some* flexibility, but > at the same time helps me implement the necessary control in the network > to make it work under adverse conditions. > > >> Sounds a lot like the Internet and its users are getting in the way of >> router vendors and their business model. > > No, more like "reality conflicting with the IETF model of defining > beautiful things based on theoretical possibilities". > > Gert Doering > -- operator > From fgont@si6networks.com Wed Jun 12 14:08:54 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93C421E8097; Wed, 12 Jun 2013 14:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QI5Na-EP8WMA; Wed, 12 Jun 2013 14:08:54 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 328EE21E8091; Wed, 12 Jun 2013 14:08:54 -0700 (PDT) Received: from [2001:5c0:1400:a::323] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmsHe-0002fO-1b; Wed, 12 Jun 2013 23:08:46 +0200 Message-ID: <51B8E35C.3070207@si6networks.com> Date: Wed, 12 Jun 2013 23:08:44 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Joe Touch References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> In-Reply-To: <51B8DED6.9030306@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Gert Doering , Robert Elz Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 21:08:54 -0000 On 06/12/2013 10:49 PM, Joe Touch wrote: > FWIW, I wouldn't mind: > > - IPv6 *should* limit its header chains to (some reasonable limit) > > What I expect when that's not the case: > > - SOME packets get through, perhaps more slowly > - when the router can't keep up, it can drop the overload > > This isn't any different from many other things, e.g., when a router > can't keep up with IPv6 packets that overload an egress. > > However, anything that says "if the chain is >X, then drop" is broken, > period. FWIW, I don't think anyone has proposed "if the chain is larger than X, then drop". We're just aiming at limiting the header chain length, *not* encouraging router to drop when the header chain exceeds that length. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From touch@isi.edu Wed Jun 12 14:31:39 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1A121E80CF; Wed, 12 Jun 2013 14:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.037 X-Spam-Level: X-Spam-Status: No, score=-103.037 tagged_above=-999 required=5 tests=[AWL=-0.438, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRoZsmneVAKx; Wed, 12 Jun 2013 14:31:33 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB5811E80FF; Wed, 12 Jun 2013 14:31:20 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r5CLUo9b004569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 14:30:53 -0700 (PDT) Message-ID: <51B8E87C.6010402@isi.edu> Date: Wed, 12 Jun 2013 14:30:36 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ole Troan References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Gert Doering , Robert Elz Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 21:31:39 -0000 On 6/12/2013 2:25 PM, Ole Troan wrote: > Joe, > >> FWIW, I wouldn't mind: >> >> - IPv6 *should* limit its header chains to (some reasonable limit) >> >> What I expect when that's not the case: >> >> - SOME packets get through, perhaps more slowly >> - when the router can't keep up, it can drop the overload >> >> This isn't any different from many other things, e.g., when a router can't keep up with IPv6 packets that overload an egress. >> >> However, anything that says "if the chain is >X, then drop" is broken, period. At some point, if you want to play "IPv6 router", you need to earn the title. > > an IPv6 router compliant with RFC2460 does not inspect the header chain. That cannot be true; there are headers after IPv6 but before fragmentation that are hop-by-hop. Joe From fgont@si6networks.com Wed Jun 12 14:44:55 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9774221E8101; Wed, 12 Jun 2013 14:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1duOgkSYFVl1; Wed, 12 Jun 2013 14:44:55 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id C97B921E8100; Wed, 12 Jun 2013 14:44:54 -0700 (PDT) Received: from [2001:5c0:1400:a::323] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmsqU-0003Um-72; Wed, 12 Jun 2013 23:44:46 +0200 Message-ID: <51B8EBCD.7070104@si6networks.com> Date: Wed, 12 Jun 2013 23:44:45 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ole Troan References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Gert Doering Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 21:44:55 -0000 On 06/12/2013 11:25 PM, Ole Troan wrote: >> However, anything that says "if the chain is >X, then drop" is broken, period. At some point, if you want to play "IPv6 router", you need to earn the title. > > an IPv6 router compliant with RFC2460 does not inspect the header chain. > > I'm not aware of any router that drop packets with extension headers. > I'm aware of network operators applying filtering policy that results in packets with extension headers being dropped. IIRC, someone reported that Cisco ASA drop v6 packets with extension headers by default..... > just to be clear I'm not against the IETF documenting e.g. in a BCP, what the longest expected header chain should be. Well, that seems more std track than bcp to me. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fernando@gont.com.ar Wed Jun 12 14:58:21 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B7421E8111; Wed, 12 Jun 2013 14:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ok08YPKALqMI; Wed, 12 Jun 2013 14:58:21 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 2518011E810E; Wed, 12 Jun 2013 14:58:21 -0700 (PDT) Received: from [2001:5c0:1400:a::323] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Umt3O-0003qq-QR; Wed, 12 Jun 2013 23:58:06 +0200 Message-ID: <51B8EEEE.8000400@gont.com.ar> Date: Wed, 12 Jun 2013 23:58:06 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jeroen Massar References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> <51B8EBBA.4000803@massar.ch> In-Reply-To: <51B8EBBA.4000803@massar.ch> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Ole Troan , Gert Doering Subject: [Int-area] Discussion about header chains (was Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 21:58:22 -0000 Jeroen, On 06/12/2013 11:44 PM, Jeroen Massar wrote: >> with the exception of the HBH header, correct. I got tired of writing that each time I was repeating myself. >> the HBH is an issue to itself. expect those packets to be severely rate limited. > > I am wondering why.... if your box cannot handle any headers, just > forward the packet, decreasing the hopcount and that is just. Well, the router is supposed to process the HBH header. And, for some options, if the option in question is not supported, the packet should be dropped -- i.e., you cannot just "ignore the hbh header" (at east in theory). > And if there is a HBH ever that a router should support, then only new > router will support it anyway. > > Disclaimer: this is the model that sixxsd (used for the SixXS PoPs) > does, and it seems to work like a charm; that is, no complaints yet ;) Probably because nobody uses such headers in practice ;-) Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@isi.edu Wed Jun 12 15:04:23 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6F911E8102; Wed, 12 Jun 2013 15:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.021 X-Spam-Level: X-Spam-Status: No, score=-103.021 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYr64FcreaiR; Wed, 12 Jun 2013 15:04:17 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6D35721E8128; Wed, 12 Jun 2013 15:04:13 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5CM3uUB026186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 15:03:56 -0700 (PDT) Message-ID: <51B8F03E.7080004@isi.edu> Date: Wed, 12 Jun 2013 15:03:42 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ole Troan References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> In-Reply-To: <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Gert Doering , Robert Elz Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:04:24 -0000 On 6/12/2013 2:36 PM, Ole Troan wrote: > Joe, > >>> an IPv6 router compliant with RFC2460 does not inspect the header chain. >> >> That cannot be true; there are headers after IPv6 but before fragmentation that are hop-by-hop. > > with the exception of the HBH header, correct. I got tired of writing that each time I was repeating myself. > the HBH is an issue to itself. expect those packets to be severely rate limited. There are three such headers that could come before fragmentation. They are (in order): HBH Destination Opts Routing Header The DO is to support RH, e.g., where the DO options are examined at each hop in the RH (it would appear only if RH is present). All of these options have to be copied for fragmentation; you would need to copy everything up to the frag header. Again, RFC 2460 is already clear on this point: The Unfragmentable Part consists of the IPv6 header plus any extension headers that must be processed by nodes en route to the destination, that is, all headers up to and including the Routing header if present, else the Hop-by-Hop Options header if present, else no extension headers. Joe From touch@isi.edu Wed Jun 12 15:07:32 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C3621E80E0; Wed, 12 Jun 2013 15:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.006 X-Spam-Level: X-Spam-Status: No, score=-103.006 tagged_above=-999 required=5 tests=[AWL=-0.407, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9KnRF4AbhY2; Wed, 12 Jun 2013 15:07:26 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6E61011E810E; Wed, 12 Jun 2013 15:07:26 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5CM6dQX026769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 15:06:40 -0700 (PDT) Message-ID: <51B8F0E1.5090409@isi.edu> Date: Wed, 12 Jun 2013 15:06:25 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jeroen Massar References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> <51B8EBBA.4000803@massar.ch> In-Reply-To: <51B8EBBA.4000803@massar.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Ole Troan , Gert Doering Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:07:32 -0000 On 6/12/2013 2:44 PM, Jeroen Massar wrote: > Unless the router in question knows what that HBH header will do (read: > it was implemented when the definition of that header was defined) or > what it should do with it, it won't be able to do anything with it > anyway. Thus just ignoring/skipping it, heck not parsing any headers at > all, will be quite fine... The only valid way to ignore the HBH header is when all its component options are "00" - skip option if not supported. If you don't check that, then you don't know whether it's valid to ignore the options. That would interfere with the semantics of options defined as "discard" or "discard and inform". Joe From sthaug@nethelp.no Wed Jun 12 15:08:05 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB3111E8116 for ; Wed, 12 Jun 2013 15:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsEBpRZ6haWr for ; Wed, 12 Jun 2013 15:08:00 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 297BD11E8110 for ; Wed, 12 Jun 2013 15:07:51 -0700 (PDT) Received: (qmail 15649 invoked from network); 12 Jun 2013 22:07:50 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 12 Jun 2013 22:07:50 -0000 Date: Thu, 13 Jun 2013 00:07:50 +0200 (CEST) Message-Id: <20130613.000750.78718087.sthaug@nethelp.no> To: fgont@si6networks.com From: sthaug@nethelp.no In-Reply-To: <51B8E35C.3070207@si6networks.com> References: <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, 6man@ietf.org, int-area@ietf.org Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:08:06 -0000 > > However, anything that says "if the chain is >X, then drop" is broken, > > period. > > FWIW, I don't think anyone has proposed "if the chain is larger than X, > then drop". On the other hand - I, as an operator, may well decide to drop such packets. Steinar Haug, AS 2116 From touch@isi.edu Wed Jun 12 15:08:30 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6632411E8115; Wed, 12 Jun 2013 15:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.992 X-Spam-Level: X-Spam-Status: No, score=-102.992 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5-O0TfQzx8e; Wed, 12 Jun 2013 15:08:24 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 89B6A11E8117; Wed, 12 Jun 2013 15:08:15 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5CM7sVx027001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 15:07:54 -0700 (PDT) Message-ID: <51B8F12C.1040204@isi.edu> Date: Wed, 12 Jun 2013 15:07:40 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Fernando Gont References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8EBCD.7070104@si6networks.com> In-Reply-To: <51B8EBCD.7070104@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Ole Troan , Gert Doering Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:08:30 -0000 On 6/12/2013 2:44 PM, Fernando Gont wrote: >> just to be clear I'm not against the IETF documenting e.g. in a BCP, what the longest expected header chain should be. > > Well, that seems more std track than bcp to me. If it's an operational recommendation (SHOULD because that's all that routers are expected to support), then it would be BCP. If you want to prohibit hosts from generating longer chains, that would be std track. Joe From fgont@si6networks.com Wed Jun 12 15:10:23 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F58E21F942B; Wed, 12 Jun 2013 15:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qULY8yFc3PUd; Wed, 12 Jun 2013 15:10:22 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9801321F8624; Wed, 12 Jun 2013 15:10:22 -0700 (PDT) Received: from [2001:5c0:1400:a::323] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmtF5-0004G1-2h; Thu, 13 Jun 2013 00:10:11 +0200 Message-ID: <51B8F1C1.3000400@si6networks.com> Date: Thu, 13 Jun 2013 00:10:09 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ole Troan References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8EBCD.7070104@si6networks.com> <24AA8E8A-B173-4BD1-99D6-7BB7B9008142@employees.org> In-Reply-To: <24AA8E8A-B173-4BD1-99D6-7BB7B9008142@employees.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:10:23 -0000 Hi, Ole, On 06/12/2013 11:53 PM, Ole Troan wrote: >> IIRC, someone reported that Cisco ASA drop v6 packets with extension >> headers by default..... > > I think you'll find that the Cisco ASA isn't marketed as a router either, it is a firewall. Agreed. >>> just to be clear I'm not against the IETF documenting e.g. in a BCP, what the longest expected header chain should be. >> >> Well, that seems more std track than bcp to me. > > I don't think we should encode in standard a number that is based on the ability of current hardware. > nor do I think we have any standard documents describing the behaviour of filtering routers / firewalls / middleboxes in this respect. Does it make any sense to tell people that they can send packets when we really know that there's no way they are going to get to their intended destination? Some random folks, for some reason, starts sending those packets. He's packets miserably die in the network. He comes to us, and we all say "oh yeah... they are being dropped.. we know that". And the folk asks us "why didn't you say so?". When standards diverge so much from reality, that's no good, IMHO. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Wed Jun 12 15:18:55 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B2121F99BE; Wed, 12 Jun 2013 15:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVbs9Jpd9JkL; Wed, 12 Jun 2013 15:18:55 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 512C921F99B7; Wed, 12 Jun 2013 15:18:48 -0700 (PDT) Received: from [2001:5c0:1400:a::323] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmtNC-0005FH-8C; Thu, 13 Jun 2013 00:18:34 +0200 Message-ID: <51B8F3B9.40406@si6networks.com> Date: Thu, 13 Jun 2013 00:18:33 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: sthaug@nethelp.no References: <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> <20130613.000750.78718087.sthaug@nethelp.no> In-Reply-To: <20130613.000750.78718087.sthaug@nethelp.no> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, 6man@ietf.org, int-area@ietf.org Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:18:56 -0000 On 06/13/2013 12:07 AM, sthaug@nethelp.no wrote: >>> However, anything that says "if the chain is >X, then drop" is broken, >>> period. >> >> FWIW, I don't think anyone has proposed "if the chain is larger than X, >> then drop". > > On the other hand - I, as an operator, may well decide to drop such > packets. Agreed. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Wed Jun 12 15:19:36 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E43C21E80DC; Wed, 12 Jun 2013 15:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6auiTo79WaWZ; Wed, 12 Jun 2013 15:19:36 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id CBAC821E8064; Wed, 12 Jun 2013 15:19:35 -0700 (PDT) Received: from [2001:5c0:1400:a::323] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmtO6-0005ME-UJ; Thu, 13 Jun 2013 00:19:31 +0200 Message-ID: <51B8F3F2.2060707@si6networks.com> Date: Thu, 13 Jun 2013 00:19:30 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Joe Touch References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8EBCD.7070104@si6networks.com> <51B8F12C.1040204@isi.edu> In-Reply-To: <51B8F12C.1040204@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Ole Troan , Gert Doering Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:19:36 -0000 On 06/13/2013 12:07 AM, Joe Touch wrote: > > On 6/12/2013 2:44 PM, Fernando Gont wrote: >>> just to be clear I'm not against the IETF documenting e.g. in a BCP, >>> what the longest expected header chain should be. >> >> Well, that seems more std track than bcp to me. > > If it's an operational recommendation (SHOULD because that's all that > routers are expected to support), then it would be BCP. > > If you want to prohibit hosts from generating longer chains, that would > be std track. I want to recommend hosts not to send such packets. Hence it looks like std track. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From warren@kumari.net Wed Jun 12 15:26:32 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CBE21E8064; Wed, 12 Jun 2013 15:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmZQ1aPMl4i8; Wed, 12 Jun 2013 15:26:27 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2312011E8119; Wed, 12 Jun 2013 15:26:26 -0700 (PDT) Received: from [192.168.6.179] (ip-64-134-41-42.public.wayport.net [64.134.41.42]) by vimes.kumari.net (Postfix) with ESMTPSA id 9DCF41B401CE; Wed, 12 Jun 2013 18:26:24 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <10707.1371062690@perseus.noi.kre.to> Date: Wed, 12 Jun 2013 18:26:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6FAE3DF4-B5B4-4F21-9098-761523745CC3@kumari.net> References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> To: Robert Elz X-Mailer: Apple Mail (2.1503) Cc: Internet Area , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Subject: Re: [Int-area] [6MAN] Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:26:32 -0000 On Jun 12, 2013, at 2:44 PM, Robert Elz wrote: > Date: Wed, 12 Jun 2013 19:49:08 +0200 > From: Gert Doering > Message-ID: <20130612174908.GT2504@Space.Net> >=20 > | Loop back to about 50 messages earlier in this thread, >=20 > I don't generally read this list (any more) - just happened to see the > past hour's worth of messages, so I have no idea what was 50 messages > earlier, but ... >=20 > | We're not talking ivory tower theoretical routers. We're talking = about > | devices that can stand the heat out there, like "be able to apply = different > | rate limiting classes to incoming BGP SYNs from trusted networks, = and to > | ICMP packets from the world". This MUST be done by the hardware, = and it > | MUST be able to look at *Layer 4* information. >=20 > If that's the issue, then the routers should just be treating any = packet with > a frag header like dirt. =20 You mean like: http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-01 = ? Seeing as I filter on routers (which don't do reassembly) and I want to = know what's actually in the packets I let into my network, they just get = dropped on the floor. Ain't nobody noticed, so, if it ain't broke=85 W > That's what they deserve. Lowest sched priority, > and most likely to be dropped. That's easy to accomplish in hardware = (well > as easy as anything else that involves looking down header chains)=20 > and perfectly acceptable - everyone knows that if one sends fragmented = packets > performance goes out the window. Perfectly acceptable result, and no > changes at all to v6 specs are needed to get to that. >=20 > On the other hand, if the real issue is firewalls, then there really = should be > no issue at all - firewalls already need to be able to reassemble = packet > chains, or they can't look inside TCP properly (as while no-one sane > would ever split tcp segments in weird places, hackers will if the = firewalls > can't handle it properly). Reassembling IP frags is childs play = compared > to reassembling tcp segments. >=20 > Again, no need to change anything in the IPv6 specs. >=20 > Lastly, this comment caught my eye ... >=20 > fgont@si6networks.com said: > | It doesn't change how fragmentation works. It just clarifies a = corner case > | which was allowed by the standard, but is not employed in practice, = and none > | expected to happen.=20 >=20 > Huh? Is that really claimimng that no-one ever thought that the frag > header would be anywhere but last in the header chain? That would be > absurd. For one, in normal use, dest options should normally come > after a frag header, processing them before the packet is reassembled = would > mean processing them before the packet is received correctly, which = would be > 100% bogus (on the other hand, if options were even invented to allow = the > sender some control over reassembly - perhaps to lower timeouts or = something - > then a destopts header before the frag header would be rational.) >=20 > Beyond that, I have had cases where a frag header before a routing = header > made perfect sense - I know that routing headers are largely = deprecated these > days, but before that, it was possible to send a fragmented packet = over a > low MTU link, have it reassembled at the far side of that link, and = then > the routing header (following the frag header) causes the packet to = continue > over links with a larger MTU, so the penalties of fragmentation apply > only where they are really needed. What's more, for the remaining = use of > routing headers (route opt for mobile IPv6) putting the frag header = before > the routing header is also the sane way to run things (the routing = header there > is really just a fancy destination option). >=20 > Lastly, consider that most v6 headers are allowed to be larger than = the > MTU of the most common links in the internet at the time (and for that > matter, still) and certainly larger than the required MTU for v6 = links, and > ask yourself how that would make any sense at all if all headers are > required to be before the frag header. >=20 > Leave the specs alone, header chanins can have headers (other than hop = by > hop opts of course) in whatever order makes sense to the application = that > needs to send those headers. No more rules. Just deal with it. >=20 > kre >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -- After you'd known Christine for any length of time, you found yourself = fighting a desire to look into her ear to see if you could spot daylight = coming the other way. -- (Terry Pratchett, Maskerade) From touch@isi.edu Wed Jun 12 15:26:48 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0124811E811A; Wed, 12 Jun 2013 15:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.979 X-Spam-Level: X-Spam-Status: No, score=-102.979 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yvv1j2qoxhps; Wed, 12 Jun 2013 15:26:42 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF3B11E8119; Wed, 12 Jun 2013 15:26:42 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5CMQAqK000374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 15:26:10 -0700 (PDT) Message-ID: <51B8F574.5000100@isi.edu> Date: Wed, 12 Jun 2013 15:25:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Fernando Gont References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8EBCD.7070104@si6networks.com> <51B8F12C.1040204@isi.edu> <51B8F3F2.2060707@si6networks.com> In-Reply-To: <51B8F3F2.2060707@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Ole Troan , Gert Doering Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:26:48 -0000 On 6/12/2013 3:19 PM, Fernando Gont wrote: > On 06/13/2013 12:07 AM, Joe Touch wrote: >> >> On 6/12/2013 2:44 PM, Fernando Gont wrote: >>>> just to be clear I'm not against the IETF documenting e.g. in a BCP, >>>> what the longest expected header chain should be. >>> >>> Well, that seems more std track than bcp to me. >> >> If it's an operational recommendation (SHOULD because that's all that >> routers are expected to support), then it would be BCP. >> >> If you want to prohibit hosts from generating longer chains, that would >> be std track. > > I want to recommend hosts not to send such packets. Hence it looks like > std track. Telling them they SHOULD NOT is BCP. It's a configuration, and it's compliant with the existing standard AFAICT, so since it's not a change per se it wouldn't be a STD. Joe From fgont@si6networks.com Wed Jun 12 15:37:38 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011DD21E80E4; Wed, 12 Jun 2013 15:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uKB196Wj+ni; Wed, 12 Jun 2013 15:37:37 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 756B911E811D; Wed, 12 Jun 2013 15:37:36 -0700 (PDT) Received: from [2001:5c0:1400:a::323] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmtfV-000657-IG; Thu, 13 Jun 2013 00:37:29 +0200 Message-ID: <51B8F828.1080304@si6networks.com> Date: Thu, 13 Jun 2013 00:37:28 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Joe Touch References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8EBCD.7070104@si6networks.com> <51B8F12C.1040204@isi.edu> <51B8F3F2.2060707@si6networks.com> <51B8F574.5000100@isi.edu> In-Reply-To: <51B8F574.5000100@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Ole Troan , Gert Doering Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:37:38 -0000 On 06/13/2013 12:25 AM, Joe Touch wrote: >> I want to recommend hosts not to send such packets. Hence it looks like >> std track. > > Telling them they SHOULD NOT is BCP. It's a configuration, and it's > compliant with the existing standard AFAICT, so since it's not a change > per se it wouldn't be a STD. It's not configuration -- after all, it's the apps that are supposed to select which options they include. The current std allows for arbitrary lengths of the header chain. And we want to say "The header chain should be up to X bytes, because otherwise interoperability will be affected". Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From warren@kumari.net Wed Jun 12 15:45:27 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0811C11E80F8; Wed, 12 Jun 2013 15:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-OUu90-XjZu; Wed, 12 Jun 2013 15:45:09 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10E711E8114; Wed, 12 Jun 2013 15:45:09 -0700 (PDT) Received: from [192.168.6.179] (ip-64-134-41-42.public.wayport.net [64.134.41.42]) by vimes.kumari.net (Postfix) with ESMTPSA id 7F5C01B401CE; Wed, 12 Jun 2013 18:45:08 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <20130613.000750.78718087.sthaug@nethelp.no> Date: Wed, 12 Jun 2013 18:45:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6759493F-9B2E-4B1C-83BB-32D54E1822C6@kumari.net> References: <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> <20130613.000750.78718087.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.1503) Cc: v6ops@ietf.org, 6man@ietf.org, int-area@ietf.org Subject: Re: [Int-area] [6MAN] Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:45:27 -0000 On Jun 12, 2013, at 6:07 PM, sthaug@nethelp.no wrote: >>> However, anything that says "if the chain is >X, then drop" is = broken, >>> period. >>=20 >> FWIW, I don't think anyone has proposed "if the chain is larger than = X, >> then drop". >=20 > On the other hand - I, as an operator, may well decide to drop such > packets. And, presumably, you as an operator are likely to also have something = like: filter AllowExpected { term web { from { destination-address { 2001:db8::100/128; } next-header tcp; destination-port [ http https ]; } then accept; } term example { from { destination-address { 2001:db8::123/128; } next-header udp; destination-port 17; } then accept; } term default { then { count default-deny; discard; } } } If the router cannot see the L4 header (because it has not sucked enough = bytes up to the filtering widget) you'd expect it to hit the "default" = term, I presume (I sure would!) This has accomplishes the same thing (unless you've decided to choose a = smaller number than the filtering logic supports). W BTW: Who added every basically single IETF list to this thread? >=20 > Steinar Haug, AS 2116 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -- After you'd known Christine for any length of time, you found yourself = fighting a desire to look into her ear to see if you could spot daylight = coming the other way. -- (Terry Pratchett, Maskerade) From touch@isi.edu Wed Jun 12 17:00:23 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC1811E8114; Wed, 12 Jun 2013 17:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.967 X-Spam-Level: X-Spam-Status: No, score=-102.967 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RoQXAuVVDLC; Wed, 12 Jun 2013 17:00:17 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7036D11E811A; Wed, 12 Jun 2013 17:00:15 -0700 (PDT) Received: from [128.9.184.156] ([128.9.184.156]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5CNxiuS019954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 16:59:44 -0700 (PDT) Message-ID: <51B90B76.40007@isi.edu> Date: Wed, 12 Jun 2013 16:59:50 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Warren Kumari References: <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> <20130613.000750.78718087.sthaug@nethelp.no> <6759493F-9B2E-4B1C-83BB-32D54E1822C6@kumari.net> In-Reply-To: <6759493F-9B2E-4B1C-83BB-32D54E1822C6@kumari.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org, 6man@ietf.org, int-area@ietf.org, sthaug@nethelp.no Subject: Re: [Int-area] [6MAN] Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 00:00:23 -0000 FWIW, I added INTAREA, because I don't consider potentially killing off IPv6 header extensions as merely maintenance (6man) or operational (v6ops). Joe On 6/12/2013 3:45 PM, Warren Kumari wrote: > BTW: Who added every basically single IETF list to this thread? From fgont@si6networks.com Wed Jun 12 17:15:25 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091ED21F9986; Wed, 12 Jun 2013 17:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9ncHtiCFlWz; Wed, 12 Jun 2013 17:15:24 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 4146F21F9981; Wed, 12 Jun 2013 17:15:23 -0700 (PDT) Received: from [2001:5c0:1400:a::1bd] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmvC0-0008Mi-BK; Thu, 13 Jun 2013 02:15:08 +0200 Message-ID: <51B90F0B.9050603@si6networks.com> Date: Thu, 13 Jun 2013 02:15:07 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Joe Touch References: <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> <20130613.000750.78718087.sthaug@nethelp.no> <6759493F-9B2E-4B1C-83BB-32D54E1822C6@kumari.net> <51B90B76.40007@isi.edu> In-Reply-To: <51B90B76.40007@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: int-area@ietf.org, v6ops@ietf.org, 6man@ietf.org, sthaug@nethelp.no Subject: Re: [Int-area] [6MAN] Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 00:15:25 -0000 On 06/13/2013 01:59 AM, Joe Touch wrote: > FWIW, I added INTAREA, because I don't consider potentially killing off > IPv6 header extensions as merely maintenance (6man) or operational (v6ops). We're trying to do exactly the opposite: try to define under which constraints we can expect them to work. If we continue on the current path (do nothing), they will be effectively killed. (see Brian et al's I-D, Warren et al's I-D, etc.). Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian.e.carpenter@gmail.com Wed Jun 12 22:16:16 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7A221F99C3; Wed, 12 Jun 2013 22:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoKIDZ4OioG8; Wed, 12 Jun 2013 22:16:16 -0700 (PDT) Received: from mail-gh0-x22c.google.com (mail-gh0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B7DF721F99B6; Wed, 12 Jun 2013 22:16:15 -0700 (PDT) Received: by mail-gh0-f172.google.com with SMTP id r18so1286008ghr.3 for ; Wed, 12 Jun 2013 22:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ivQOS2qgOYxhSjTfKQZFfL7MepyHJAJ9BwHdIM3DQHA=; b=HBuP5dKHlGT7eseBZSIPO/FFeLkiNRz8NRUOzsR9ei2JJlQORTJpjZRFkz80Q0eKJ4 Ri/FSKlpwsIiuwUXrLHSK5Ckmjx7KQMo6jpx6wGuSLrk6F0sFT72sHDwqeSvAPbWmkdO tHNf3WMcXSepsB4wsoWfHt1l5sxmTLiRxU5BtUl8iKFSZRCjAPtoBElHfmxNU3LMhMR/ +eM3CaSQdY6+um5VhFku2OGaZVXOrQJt5S6zwnO873J5xJ1CIXtzl9NPO9ZKgoNLx1A3 MZqKtO+BB302tkrMXBOtkCChzM1pgSMnjXScapqzUo/OMrkDzD4REZNLY0RlngdnxOx6 8kYw== X-Received: by 10.236.30.134 with SMTP id k6mr7754818yha.125.1371100575328; Wed, 12 Jun 2013 22:16:15 -0700 (PDT) Received: from [192.168.1.2] (153.235.252.27.dyn.cust.vf.net.nz. [27.252.235.153]) by mx.google.com with ESMTPSA id b50sm32223527yhl.1.2013.06.12.22.16.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Jun 2013 22:16:14 -0700 (PDT) Message-ID: <51B955A3.7040907@gmail.com> Date: Thu, 13 Jun 2013 17:16:19 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> <51B8EBBA.4000803@massar.ch> <51B8F0E1.5090409@isi.edu> In-Reply-To: <51B8F0E1.5090409@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations , Jeroen Massar , Internet Area Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 05:16:16 -0000 On 13/06/2013 10:06, Joe Touch wrote: > > > On 6/12/2013 2:44 PM, Jeroen Massar wrote: >> Unless the router in question knows what that HBH header will do (read: >> it was implemented when the definition of that header was defined) or >> what it should do with it, it won't be able to do anything with it >> anyway. Thus just ignoring/skipping it, heck not parsing any headers at >> all, will be quite fine... > > The only valid way to ignore the HBH header is when all its component > options are "00" - skip option if not supported. > > If you don't check that, then you don't know whether it's valid to > ignore the options. That would interfere with the semantics of options > defined as "discard" or "discard and inform". Reality check: high speed routers don't look at HbH options. Your best hope is that they throw them on a slow path, but not all designs have a slow path. If you are designing a HbH option, you'd better assume that some routers will ignore it. On 13/06/2013 10:21, Ray Hunter wrote: >> I think we should advocate 256 as a target for hardware designers; we know that >> > some of them have current hardware limits less than that, but a "SHOULD inspect 256" >> > seems reasonable (and conversely, a "SHOULD NOT exceed 256" for hosts generating >> > IPv6 packets). >> > >> > Given time (as somebody said, maybe ten years) this would palliate the >> > problem. >> > >> > Brian > > > Whilst I agree we need to take steps to simplify the problem, I'd like > some feedback from hardware manufacturers either publicly or privately > whether this limit is sufficient on its own. I'm pretty sure that it isn't; it's a starting point for digging out of the hole, because it bounds one aspect of the problem. Brian (cross-posting with reluctance) From otroan@employees.org Wed Jun 12 14:25:57 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DB311E80E7; Wed, 12 Jun 2013 14:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Do84lOHBEcz4; Wed, 12 Jun 2013 14:25:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB9511E80CC; Wed, 12 Jun 2013 14:25:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAInmuFGQ/khL/2dsb2JhbABaDoJ7v0OBARZ0giMBAQQBOj8FCwtGVwaIGwa7LI4MgQQzB4J/YQOpAoFYeUA6gS0 X-IronPort-AV: E=Sophos;i="4.87,854,1363132800"; d="scan'208";a="155269681" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 12 Jun 2013 21:25:46 +0000 Received: from dhcp-10-61-111-244.cisco.com (dhcp-10-61-111-244.cisco.com [10.61.111.244]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5CLPg4M027652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Jun 2013 21:25:43 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <51B8DED6.9030306@isi.edu> Date: Wed, 12 Jun 2013 23:25:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Wed, 12 Jun 2013 23:01:25 -0700 Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Gert Doering , Robert Elz Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 21:25:58 -0000 Joe, > FWIW, I wouldn't mind: >=20 > - IPv6 *should* limit its header chains to (some reasonable limit) >=20 > What I expect when that's not the case: >=20 > - SOME packets get through, perhaps more slowly > - when the router can't keep up, it can drop the overload >=20 > This isn't any different from many other things, e.g., when a router = can't keep up with IPv6 packets that overload an egress. >=20 > However, anything that says "if the chain is >X, then drop" is broken, = period. At some point, if you want to play "IPv6 router", you need to = earn the title. an IPv6 router compliant with RFC2460 does not inspect the header chain. I'm not aware of any router that drop packets with extension headers. I'm aware of network operators applying filtering policy that results in = packets with extension headers being dropped. it would be very interesting to see where in the network those policies = are used. my assumption was on Enterprise border, and that packets go across the Internet unhindered, as well as = inside of Enterprises. it would be interesting if someone could test that. RIPE Atlas? or if operators on the list = would share what the filter where and why. just to be clear I'm not against the IETF documenting e.g. in a BCP, = what the longest expected header chain should be. cheers, Ole= From otroan@employees.org Wed Jun 12 14:36:16 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B833B11E8109; Wed, 12 Jun 2013 14:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLttRTIvyX+T; Wed, 12 Jun 2013 14:36:11 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 439BC11E80FF; Wed, 12 Jun 2013 14:36:10 -0700 (PDT) Received: from dhcp-10-61-111-244.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 72FA75EF1; Wed, 12 Jun 2013 14:36:07 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <51B8E87C.6010402@isi.edu> Date: Wed, 12 Jun 2013 23:36:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Wed, 12 Jun 2013 23:01:25 -0700 Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Gert Doering , Robert Elz Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 21:36:17 -0000 Joe, >> an IPv6 router compliant with RFC2460 does not inspect the header = chain. >=20 > That cannot be true; there are headers after IPv6 but before = fragmentation that are hop-by-hop. with the exception of the HBH header, correct. I got tired of writing = that each time I was repeating myself. the HBH is an issue to itself. expect those packets to be severely rate = limited. cheers, Ole From jeroen@massar.ch Wed Jun 12 14:44:34 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C5E21E80D8; Wed, 12 Jun 2013 14:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3w7UYwNosbp; Wed, 12 Jun 2013 14:44:31 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id AA5D621E8094; Wed, 12 Jun 2013 14:44:31 -0700 (PDT) Received: from kami.ch.unfix.org (173-164-171-230-SFBA.hfc.comcastbusiness.net [173.164.171.230]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 8F527801C2BA; Wed, 12 Jun 2013 23:44:27 +0200 (CEST) Message-ID: <51B8EBBA.4000803@massar.ch> Date: Wed, 12 Jun 2013 14:44:26 -0700 From: Jeroen Massar Organization: Massar User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ole Troan References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> In-Reply-To: <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 12 Jun 2013 23:01:25 -0700 Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Gert Doering Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 21:44:34 -0000 On 2013-06-12 14:36, Ole Troan wrote: > Joe, > >>> an IPv6 router compliant with RFC2460 does not inspect the header chain. >> >> That cannot be true; there are headers after IPv6 but before fragmentation that are hop-by-hop. > > with the exception of the HBH header, correct. I got tired of writing that each time I was repeating myself. > the HBH is an issue to itself. expect those packets to be severely rate limited. I am wondering why.... if your box cannot handle any headers, just forward the packet, decreasing the hopcount and that is just. Much more efficient, does not get in the slow path and some other box that is more capable will handle special requests. Unless the router in question knows what that HBH header will do (read: it was implemented when the definition of that header was defined) or what it should do with it, it won't be able to do anything with it anyway. Thus just ignoring/skipping it, heck not parsing any headers at all, will be quite fine... And if there is a HBH ever that a router should support, then only new router will support it anyway. Disclaimer: this is the model that sixxsd (used for the SixXS PoPs) does, and it seems to work like a charm; that is, no complaints yet ;) Greets, Jeroen From otroan@employees.org Wed Jun 12 14:54:39 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B88C11E8119; Wed, 12 Jun 2013 14:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JB+aA9c-eoKg; Wed, 12 Jun 2013 14:54:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id CF66111E810E; Wed, 12 Jun 2013 14:54:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALDsuFGQ/khL/2dsb2JhbABagwm/Q4EBFnSCIwEBBAE6PxALDjhXBogbBrsqjxAzB4J/YQOpAoFYgTk6 X-IronPort-AV: E=Sophos;i="4.87,854,1363132800"; d="scan'208";a="155270498" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 12 Jun 2013 21:54:01 +0000 Received: from dhcp-10-61-111-244.cisco.com (dhcp-10-61-111-244.cisco.com [10.61.111.244]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5CLrwGj001946 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Jun 2013 21:53:59 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <51B8EBCD.7070104@si6networks.com> Date: Wed, 12 Jun 2013 23:53:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <24AA8E8A-B173-4BD1-99D6-7BB7B9008142@employees.org> References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8EBCD.7070104@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Wed, 12 Jun 2013 23:01:25 -0700 Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 21:54:39 -0000 Fernando, >>> However, anything that says "if the chain is >X, then drop" is = broken, period. At some point, if you want to play "IPv6 router", you = need to earn the title. >>=20 >> an IPv6 router compliant with RFC2460 does not inspect the header = chain. >>=20 >> I'm not aware of any router that drop packets with extension headers. >> I'm aware of network operators applying filtering policy that results = in packets with extension headers being dropped. >=20 > IIRC, someone reported that Cisco ASA drop v6 packets with extension > headers by default..... I think you'll find that the Cisco ASA isn't marketed as a router = either, it is a firewall. >> just to be clear I'm not against the IETF documenting e.g. in a BCP, = what the longest expected header chain should be. >=20 > Well, that seems more std track than bcp to me. I don't think we should encode in standard a number that is based on the = ability of current hardware. nor do I think we have any standard documents describing the behaviour = of filtering routers / firewalls / middleboxes in this respect. cheers, Ole= From marka@isc.org Wed Jun 12 19:07:49 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C85211E8106; Wed, 12 Jun 2013 19:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGjaZL-TgJCJ; Wed, 12 Jun 2013 19:07:47 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id E16C111E8114; Wed, 12 Jun 2013 19:07:46 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 3DDC3C9530; Thu, 13 Jun 2013 02:07:38 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1371089266; bh=eXa0juQI5PendGtdGSKdEG/116sb0o+db5OKQo+nAhM=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=bGs1KRbiqbn3YRJ1rgF4VkC4Qna+mLXzJesR9Zj3pKXxy0ErH+lEWetGj9u38CiYn 3IHXI5eKTobNOxwYQV/1x7fcgl4NdDqEDBh3d/HSjZehmbL+SlMno4t/2ezvhAxMVH 8BPuep3AS+R7l87EGv3A53DsPOS9iNekF8JERXEk= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Thu, 13 Jun 2013 02:07:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:e980:38d3:9f1c:e9ba]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3F505216C4B; Thu, 13 Jun 2013 02:07:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 7F7B535D3BA9; Thu, 13 Jun 2013 12:07:17 +1000 (EST) To: Warren Kumari From: Mark Andrews References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <6FAE3DF4-B5B4-4F21-9098-761523745CC3@kumari.net> In-reply-to: Your message of "Wed, 12 Jun 2013 18:26:23 -0400." <6FAE3DF4-B5B4-4F21-9098-761523745CC3@kumari.net> Date: Thu, 13 Jun 2013 12:07:17 +1000 Message-Id: <20130613020717.7F7B535D3BA9@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist X-Mailman-Approved-At: Wed, 12 Jun 2013 23:01:25 -0700 Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz Subject: Re: [Int-area] [v6ops] [6MAN] Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 02:07:49 -0000 In message <6FAE3DF4-B5B4-4F21-9098-761523745CC3@kumari.net>, Warren Kumari writes: > > On Jun 12, 2013, at 2:44 PM, Robert Elz wrote: > > > Date: Wed, 12 Jun 2013 19:49:08 +0200 > > From: Gert Doering > > Message-ID: <20130612174908.GT2504@Space.Net> > > = > > > | Loop back to about 50 messages earlier in this thread, > > = > > > I don't generally read this list (any more) - just happened to see the > > past hour's worth of messages, so I have no idea what was 50 messages > > earlier, but ... > > = > > > | We're not talking ivory tower theoretical routers. We're talking about > > | devices that can stand the heat out there, like "be able to apply diffe= > rent > > | rate limiting classes to incoming BGP SYNs from trusted networks, and to > > | ICMP packets from the world". This MUST be done by the hardware, and it > > | MUST be able to look at *Layer 4* information. > > = > > > If that's the issue, then the routers should just be treating any packet = > with > > a frag header like dirt. = > > > You mean like: http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-01 ? > > Seeing as I filter on routers (which don't do reassembly) and I want to kno= > w what's actually in the packets I let into my network, they just get dropp= > ed on the floor. > Ain't nobody noticed, so, if it ain't broke=85 > > W Don't take lack of complaints as "nobody noticed". If you want complaints then nameserver vendors can remove the code which tries you handle your broken routers. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jeroen@massar.ch Thu Jun 13 00:02:51 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F9421F991E; Thu, 13 Jun 2013 00:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dsfdk8DxIfz; Thu, 13 Jun 2013 00:02:46 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [78.47.209.234]) by ietfa.amsl.com (Postfix) with ESMTP id A6C0A21F9798; Thu, 13 Jun 2013 00:02:41 -0700 (PDT) Received: from kami.ch.unfix.org (unknown [IPv6:2001:559:8000:c9:7256:81ff:fea5:2925]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id B8669801C2BA; Thu, 13 Jun 2013 09:02:19 +0200 (CEST) Message-ID: <51B96E7B.8010706@massar.ch> Date: Thu, 13 Jun 2013 00:02:19 -0700 From: Jeroen Massar Organization: Massar User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Fernando Gont References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> <51B8EBBA.4000803@massar.ch> <51B8EEEE.8000400@gont.com.ar> In-Reply-To: <51B8EEEE.8000400@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Ole Troan Subject: Re: [Int-area] Discussion about header chains (was Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 07:02:51 -0000 On 2013-06-12 14:58, Fernando Gont wrote: > Jeroen, > > On 06/12/2013 11:44 PM, Jeroen Massar wrote: >>> with the exception of the HBH header, correct. I got tired of writing that each time I was repeating myself. >>> the HBH is an issue to itself. expect those packets to be severely rate limited. >> >> I am wondering why.... if your box cannot handle any headers, just >> forward the packet, decreasing the hopcount and that is just. > > Well, the router is supposed to process the HBH header. According to the spec, yes, but does it make sense? See more below. (note that must is not written in capitols in 2460 btw ;) > And, for some > options, if the option in question is not supported, the packet should > be dropped -- i.e., you cannot just "ignore the hbh header" (at east in > theory). Why not? Is there any HBH header that is crucial for operation of IPv6? It might be in the RFC, does not mean it is actually needed ;) On 2013-06-12 15:06, Joe Touch wrote: > [..] > The only valid way to ignore the HBH header is when all its component > options are "00" - skip option if not supported. None of the variants will ever catch on/make sense unless one can do a full network upgrade to support that special option. And unless one can upgrade the whole Internet (or at least the network your packets travel over), the only useful one is ignore, the others are futile unless one wants to probe which boxes support that feature, which would thus allow fingerprinting of the age of the stack. > If you don't check that, then you don't know whether it's valid to > ignore the options. That would interfere with the semantics of options > defined as "discard" or "discard and inform". But ignoring them, allows any box that does implement the option to actually process them. If something uses the 'discard' ones, it would require the whole network to be upgraded in one go, and that is not ever going to happen. Thus either one does that upgrade or one never specifies discard and then ignoring is perfect IMHO. Greets, Jeroen (hmmm should have had this whole discussion the previous week, as then I could have asked Bob Hinden what the real intent behind all of this was upto at least this morning ;) From randy@psg.com Thu Jun 13 01:18:02 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0AD21F999B; Thu, 13 Jun 2013 01:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+VexB72mdGR; Thu, 13 Jun 2013 01:18:02 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 586B921F8EDF; Thu, 13 Jun 2013 01:18:01 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Un2jH-00006g-5n; Thu, 13 Jun 2013 08:17:59 +0000 Date: Thu, 13 Jun 2013 10:17:55 +0200 Message-ID: From: Randy Bush To: Fernando Gont In-Reply-To: <51B8E35C.3070207@si6networks.com> References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: Internet Area , IPv6 Operations , IPv6 Deployment Prevention Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 08:18:02 -0000 > FWIW, I don't think anyone has proposed "if the chain is larger than X, > then drop". i am saying that i am telling my neighbor that, if the header length is larger than X, it is likely that their packet will not propagate. it's an ops bcp statement, not a statement of ipv6 protocol definition. same as telling them that a bgp announcement of a prefix longer than a /24 likely will not propagete. today, real routers really do drop packets with headers longer than various limits. as an op, i am trying to remove the surpeise in the 'various'. randy From cb.list6@gmail.com Thu Jun 13 06:27:30 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573D421F8F33; Thu, 13 Jun 2013 06:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KJfrWJ29qr6; Thu, 13 Jun 2013 06:27:29 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAC121F8EC3; Thu, 13 Jun 2013 06:27:28 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id m6so1549085wiv.3 for ; Thu, 13 Jun 2013 06:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wEi7kAW0z67pVzxwA6R3ktR881uQueGu61NQetvMukg=; b=kklL8h0RrLJRCjJ8DiznCKK/eKzYlWkyGqiCxpVu83q8RNqS/fhltI6ItGErHEVZZv nWtWxiDqO5jGUSyIPxr12Pm83ZoC2Noq+QKfubkKbZYAwg0G1/35g9jV4ELQsMm/pYls tNHm/1S8vAdxEs3Smsz5GNqrwIamrNAbn9op5SuU2G8CbYtqIe0CBjI9zTE+NJFnBhQu KauDWCjyPmbXJlV4+uEUM4P8+hMyXL33BfYp0J5cszbesL+WoVBisrK9si9k2wCXq1vI mJ9yi3csp0CRXdiaynrkhTH5YyCpyrZLexn1KcjFL+Go9g8tGIwZiSvrOy4+hfZk5E8H FAiQ== MIME-Version: 1.0 X-Received: by 10.180.184.101 with SMTP id et5mr527227wic.45.1371130048328; Thu, 13 Jun 2013 06:27:28 -0700 (PDT) Received: by 10.194.56.231 with HTTP; Thu, 13 Jun 2013 06:27:28 -0700 (PDT) Received: by 10.194.56.231 with HTTP; Thu, 13 Jun 2013 06:27:28 -0700 (PDT) In-Reply-To: References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> Date: Thu, 13 Jun 2013 06:27:28 -0700 Message-ID: From: "cb.list6" To: Randy Bush Content-Type: multipart/alternative; boundary=001a11c2289a78b9c904df091731 Cc: IPv6 Ops WG , Internet Area , IPv6 Deployment Prevention Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 13:27:30 -0000 --001a11c2289a78b9c904df091731 Content-Type: text/plain; charset=ISO-8859-1 On Jun 13, 2013 1:18 AM, "Randy Bush" wrote: > > > FWIW, I don't think anyone has proposed "if the chain is larger than X, > > then drop". > > i am saying that i am telling my neighbor that, if the header length is > larger than X, it is likely that their packet will not propagate. it's > an ops bcp statement, not a statement of ipv6 protocol definition. > > same as telling them that a bgp announcement of a prefix longer than a > /24 likely will not propagete. > > today, real routers really do drop packets with headers longer than > various limits. as an op, i am trying to remove the surpeise in the > 'various'. > > randy > Randy, is it more helpful to document well known and acceptable permutations rather x number of bytes? In the end, byte guidance provides a cap on what is possible but does not help the world understand what is rational and acceptable and what is likely to reach its destination CB _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area --001a11c2289a78b9c904df091731 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jun 13, 2013 1:18 AM, "Randy Bush" <randy@psg.com> wrote:
>
> > FWIW, I don't think anyone has proposed "if the chain is= larger than X,
> > then drop".
>
> i am saying that i am telling my neighbor that, if the header length i= s
> larger than X, it is likely that their packet will not propagate. =A0i= t's
> an ops bcp statement, not a statement of ipv6 protocol definition.
>
> same as telling them that a bgp announcement of a prefix longer than a=
> /24 likely will not propagete.
>
> today, real routers really do drop packets with headers longer than > various limits. =A0as an op, i am trying to remove the surpeise in the=
> 'various'.
>
> randy
>

Randy, is it more helpful to document well known and accepta= ble permutations rather x number of bytes?=A0

In the end, byte guidance provides a cap on what is possible= but does not help the world understand what is rational and acceptable and= what is likely to reach its destination

CB _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www= .ietf.org/mailman/listinfo/int-area

--001a11c2289a78b9c904df091731-- From touch@isi.edu Thu Jun 13 13:19:05 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA7F21F9A65; Thu, 13 Jun 2013 13:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.955 X-Spam-Level: X-Spam-Status: No, score=-102.955 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6fuN0Xv+Wd1; Thu, 13 Jun 2013 13:19:00 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 25E8121F9A3D; Thu, 13 Jun 2013 13:19:00 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5DKI2cA011356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Jun 2013 13:18:02 -0700 (PDT) Message-ID: <51BA28EB.3040508@isi.edu> Date: Thu, 13 Jun 2013 13:17:47 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jeroen Massar References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> <51B8EBBA.4000803@massar.ch> <51B8EEEE.8000400@gont.com.ar> <51B96E7B.8010706@massar.ch> In-Reply-To: <51B96E7B.8010706@massar.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Ole Troan , Fernando Gont Subject: Re: [Int-area] Discussion about header chains (was Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 20:19:06 -0000 On 6/13/2013 12:02 AM, Jeroen Massar wrote: > On 2013-06-12 14:58, Fernando Gont wrote: >> Jeroen, >> >> On 06/12/2013 11:44 PM, Jeroen Massar wrote: >>>> with the exception of the HBH header, correct. I got tired of writing that each time I was repeating myself. >>>> the HBH is an issue to itself. expect those packets to be severely rate limited. >>> >>> I am wondering why.... if your box cannot handle any headers, just >>> forward the packet, decreasing the hopcount and that is just. >> >> Well, the router is supposed to process the HBH header. > > According to the spec, yes, but does it make sense? See more below. > (note that must is not written in capitols in 2460 btw ;) > >> And, for some >> options, if the option in question is not supported, the packet should >> be dropped -- i.e., you cannot just "ignore the hbh header" (at east in >> theory). > > Why not? Is there any HBH header that is crucial for operation of IPv6? Current non-experimental ones include: - jumbograms - RPL - router alert - CALIPSO (informational, but which includes a note about hazards of HBH opts, but claims there was a conclusion that this was still the correct approach) RPL was just approved in 2012. Even though few of these are 'crucial', why are router vendors still creating new standards, and why does the IESG continue to approve them? Joe From jeroen@massar.ch Thu Jun 13 13:54:38 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA15021F91BC; Thu, 13 Jun 2013 13:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toQChgo2CX+p; Thu, 13 Jun 2013 13:54:34 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [78.47.209.234]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE3121F9AC2; Thu, 13 Jun 2013 13:54:33 -0700 (PDT) Received: from kami.ch.unfix.org (unknown [IPv6:2001:559:8000:c9:7256:81ff:fea5:2925]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 5BF7A801C2BA; Thu, 13 Jun 2013 22:54:29 +0200 (CEST) Message-ID: <51BA3184.1040500@massar.ch> Date: Thu, 13 Jun 2013 13:54:28 -0700 From: Jeroen Massar Organization: Massar User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Joe Touch References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> <51B8EBBA.4000803@massar.ch> <51B8EEEE.8000400@gont.com.ar> <51B96E7B.8010706@massar.ch> <51BA28EB.3040508@isi.edu> In-Reply-To: <51BA28EB.3040508@isi.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Ole Troan , Fernando Gont Subject: Re: [Int-area] Discussion about header chains (was Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 20:54:38 -0000 On 2013-06-13 13:17, Joe Touch wrote: [..] >>> And, for some >>> options, if the option in question is not supported, the packet should >>> be dropped -- i.e., you cannot just "ignore the hbh header" (at east in >>> theory). >> >> Why not? Is there any HBH header that is crucial for operation of IPv6? > > Current non-experimental ones include: peeking at http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml 'act' and noting there are a few protocols that have act != 00 that might be affected by this. > - jumbograms act = 11 (discard + notify senders, non-multicast) I am not aware of any medium being able to do even close to 65k (or heck 20k) packets, let alone over it. Is there any gear anywhere in the world which actually implements/needs this? Now for boxes that actually have both a Jumbogram capable interface and a non-jumbogram interface, for those boxes being able to understand and thus reject this option would make sense indeed. Anywhere else this option should never be seen. (And if the code does not know about it, the hardware will likely not get it either). > - RPL act = 01 (discard) I don't see damage when this packet is ignored though. "The RPL Option is only for use between RPL routers participating in the same RPL Instance." Code that does not know about RPL does not support it and does not include the instance. (Generally this looks like one of those 'scary' and 'do not want to see from another operator on my network' kind of options btw) Security considerations does not hi-light what problems could happen if a box just ignores it unfortunately. > - router alert act = 00 (ignore) thus handled by routers that do not do HBH at all. > - CALIPSO (informational, but which includes a note about > hazards of HBH opts, but claims there was a conclusion > that this was still the correct approach) act = 00 (ignore), thus no issue here. I btw love the IESG note at the top: "The IESG notes that general deployment of protocols with hop-by-hop options are problematic, and the development of such protocols is consequently discouraged." and: "It is unsuitable for use and ineffective on the global public Internet." > RPL was just approved in 2012. > > Even though few of these are 'crucial', why are router vendors still > creating new standards, and why does the IESG continue to approve them? Except maybe one day far in the future where Jumbopackets are needed, I do not see any of these as 'crucial'. I also do not see a single problem with routers that simply completely ignore anything but the IP header (thus decrement hop-limit, error+icmp if needed, forward the packet to the next hop) and do not look at any of the next headers... Note that this kind of ignore does allow future HBH options to be developed and deployed without issues (maybe somebody comes up with a useful thing). Processing overhead in routers is none, as they just route, boxes that have more knowledge can handle the options. (which is I assume also the idea behind the act bits, but it seems they only limit deployment of something new, not allow it) I would love to be informed though if anybody knows any situation where that can be problematic, now or in the future. Greets, Jeroen From touch@isi.edu Thu Jun 13 14:03:53 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CA921F9A62; Thu, 13 Jun 2013 14:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.944 X-Spam-Level: X-Spam-Status: No, score=-104.944 tagged_above=-999 required=5 tests=[AWL=1.655, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FTY1oN2PRlS; Thu, 13 Jun 2013 14:03:48 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id D369E21F9A4E; Thu, 13 Jun 2013 14:03:47 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r5DL2APN021811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Jun 2013 14:02:10 -0700 (PDT) Message-ID: <51BA3358.6040701@isi.edu> Date: Thu, 13 Jun 2013 14:02:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jeroen Massar References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> <51B8EBBA.4000803@massar.ch> <51B8EEEE.8000400@gont.com.ar> <51B96E7B.8010706@massar.ch> <51BA28EB.3040508@isi.edu> <51BA3184.1040500@massar.ch> In-Reply-To: <51BA3184.1040500@massar.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Ole Troan , Fernando Gont Subject: Re: [Int-area] Discussion about header chains (was Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 21:03:53 -0000 On 6/13/2013 1:54 PM, Jeroen Massar wrote: > On 2013-06-13 13:17, Joe Touch wrote: > [..] >>>> And, for some >>>> options, if the option in question is not supported, the packet should >>>> be dropped -- i.e., you cannot just "ignore the hbh header" (at east in >>>> theory). >>> >>> Why not? Is there any HBH header that is crucial for operation of IPv6? >> >> Current non-experimental ones include: > > peeking at > http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml > 'act' and noting there are a few protocols that have act != 00 that > might be affected by this. Agreed. I'm not sure why the table includes HBH and DO in the same list without additional info; it would be useful to expand that table to indicate that. However, even ignoring the HBH opts wouldn't help if they can't be "jumped over" efficiently to find other headers in the chain. I.e., ignoring HBH isn't he same as prohibiting it or limiting it. Joe From jeroen@massar.ch Thu Jun 13 14:10:38 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B1F21F999A; Thu, 13 Jun 2013 14:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJn89vYCpNtD; Thu, 13 Jun 2013 14:10:33 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [78.47.209.234]) by ietfa.amsl.com (Postfix) with ESMTP id 074EC21F9947; Thu, 13 Jun 2013 14:10:32 -0700 (PDT) Received: from kami.ch.unfix.org (dhcp-84.wireless.lah1.vix.su [24.104.150.84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id CDCB1801C2BA; Thu, 13 Jun 2013 23:10:28 +0200 (CEST) Message-ID: <51BA3544.2060901@massar.ch> Date: Thu, 13 Jun 2013 14:10:28 -0700 From: Jeroen Massar Organization: Massar User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Joe Touch References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> <51B8EBBA.4000803@massar.ch> <51B8EEEE.8000400@gont.com.ar> <51B96E7B.8010706@massar.ch> <51BA28EB.3040508@isi.edu> <51BA3184.1040500@massar.ch> <51BA3358.6040701@isi.edu> In-Reply-To: <51BA3358.6040701@isi.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Ole Troan , Fernando Gont Subject: Re: [Int-area] Discussion about header chains (was Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 21:10:38 -0000 On 2013-06-13 14:02, Joe Touch wrote: [..] >> peeking at >> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml >> 'act' and noting there are a few protocols that have act != 00 that >> might be affected by this. > > Agreed. > > I'm not sure why the table includes HBH and DO in the same list without > additional info; it would be useful to expand that table to indicate that. There are a few other nits in that list, eg references to [IPV6] while those RFCs are quite well known ;) > However, even ignoring the HBH opts wouldn't help if they can't be > "jumped over" efficiently to find other headers in the chain. I.e., > ignoring HBH isn't he same as prohibiting it or limiting it. The whole design for HBH/DO is so that they are always aligned on 8-bytes and start with the ID and a length (which is per 8 bytes), thus should be reasonably efficient to jump over them if one wants to parse them (till we hit 512bit cpu's). Greets, Jeroen From wwwrun@rfc-editor.org Tue Jun 18 14:46:21 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B801821F85F7; Tue, 18 Jun 2013 14:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23kYXZO9Fie0; Tue, 18 Jun 2013 14:46:21 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFC121F8425; Tue, 18 Jun 2013 14:46:17 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A927D6217D; Tue, 18 Jun 2013 14:44:06 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130618214406.A927D6217D@rfc-editor.org> Date: Tue, 18 Jun 2013 14:44:06 -0700 (PDT) Cc: int-area@ietf.org, rfc-editor@rfc-editor.org Subject: [Int-area] RFC 6967 on Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 21:46:21 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6967 Title: Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments Author: M. Boucadair, J. Touch, P. Levis, R. Penno Status: Informational Stream: IETF Date: June 2013 Mailbox: mohamed.boucadair@orange.com, touch@isi.edu, pierre.levis@orange.com, repenno@cisco.com Pages: 24 Characters: 53498 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-intarea-nat-reveal-analysis-10.txt URL: http://www.rfc-editor.org/rfc/rfc6967.txt This document is a collection of potential solutions for revealing a host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier could be used by a remote server to sort packets according to the sending host. The host identifier must be unique to each host under the same shared IP address. This document analyzes a set of potential solutions for revealing a host identifier and does not recommend a particular solution, although it does highlight the hazards of some approaches. This document is a product of the Internet Area Working Group Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From brandon.williams@akamai.com Wed Jun 19 12:46:47 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1FF21F9C51; Wed, 19 Jun 2013 12:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1olBNH8GBPR; Wed, 19 Jun 2013 12:46:43 -0700 (PDT) Received: from prod-mail-xrelay01.akamai.com (prod-mail-xrelay01.akamai.com [72.246.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 71FCD21F9ECF; Wed, 19 Jun 2013 12:46:43 -0700 (PDT) Received: from prod-mail-xrelay01.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C4181D1073; Wed, 19 Jun 2013 19:46:42 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay01.akamai.com (Postfix) with ESMTP id AC488D0CDC; Wed, 19 Jun 2013 19:46:42 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id A185B1FF9; Wed, 19 Jun 2013 19:46:42 +0000 (GMT) Message-ID: <51C20AA1.3090604@akamai.com> Date: Wed, 19 Jun 2013 15:46:41 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "tcpm@ietf.org" , "int-area@ietf.org" References: <20130619193032.15613.81616.idtracker@ietfa.amsl.com> In-Reply-To: <20130619193032.15613.81616.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130619193032.15613.81616.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Int-area] Fwd: New Version Notification for draft-williams-overlaypath-ip-tcp-rfc-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 19:46:47 -0000 Dear all, A new version of this draft has been submitted. The changes is the version are: o Clarify public overlay network use case regarding NAT. o Add some discussion regarding use of option space and packet fragmentation. Comments are welcome. Cheers, --Brandon PS: Please note, I have cross posted to tcpm and int-area because the draft describes both a TCP option and IP options for v4 and v6. -------- Original Message -------- Subject: New Version Notification for draft-williams-overlaypath-ip-tcp-rfc-04.txt Date: Wed, 19 Jun 2013 15:30:32 -0400 From: internet-drafts@ietf.org To: Williams, Brandon A new version of I-D, draft-williams-overlaypath-ip-tcp-rfc-04.txt has been successfully submitted by Brandon Williams and posted to the IETF repository. Filename: draft-williams-overlaypath-ip-tcp-rfc Revision: 04 Title: Overlay Path Option for IP and TCP Creation date: 2013-06-19 Group: Individual Submission Number of pages: 17 URL: http://www.ietf.org/internet-drafts/draft-williams-overlaypath-ip-tcp-rfc-04.txt Status: http://datatracker.ietf.org/doc/draft-williams-overlaypath-ip-tcp-rfc Htmlized: http://tools.ietf.org/html/draft-williams-overlaypath-ip-tcp-rfc-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-williams-overlaypath-ip-tcp-rfc-04 Abstract: Data transport through overlay networks often uses either connection termination or network address translation (NAT) in such a way that the public IP addresses of the true endpoint machines involved in the data transport are invisible to each other. This document describes IPv4, IPv6, and TCP options for communicating this information from the overlay network to the endpoint machines. The IETF Secretariat From Fred.L.Templin@boeing.com Mon Jun 24 14:16:28 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC5C21E812E for ; Mon, 24 Jun 2013 14:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1aO6mMKJcDZ for ; Mon, 24 Jun 2013 14:16:21 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 4A07B21E8129 for ; Mon, 24 Jun 2013 14:16:21 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r5OLH11G029403 for ; Mon, 24 Jun 2013 14:17:01 -0700 Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r5OLH0Tt029399 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 24 Jun 2013 14:17:00 -0700 Received: from XCH-BLV-303.nw.nos.boeing.com (130.247.25.215) by XCH-NWHT-07.nw.nos.boeing.com (130.247.25.111) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 24 Jun 2013 14:16:20 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-BLV-303.nw.nos.boeing.com ([169.254.3.3]) with mapi id 14.02.0328.011; Mon, 24 Jun 2013 14:16:19 -0700 From: "Templin, Fred L" To: Ronald Bonica , "Carlos Pignataro (cpignata)" Thread-Topic: draft-bonica-intarea-gre-mtu-02.txt Thread-Index: AQHOX8a3wS1s6Fkp8ki4KgulZKiiupknXJGwgB38yuA= Date: Mon, 24 Jun 2013 21:16:18 +0000 Message-ID: <2134F8430051B64F815C691A62D983180A9809@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> <95067C434CE250468B77282634C96ED322BD8926@xmb-aln-x02.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F3F16A@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509F3F16A@BY2PRD0512MB653.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: Internet Area Subject: [Int-area] draft-bonica-intarea-gre-mtu-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 21:16:28 -0000 Hi Ron and Carlos, Here are my comments on this draft: Fred fred.l.templin@boeing.com Section 1.2: ************ Under the bullet: "o Path MTU Discovery (PMTUD)", should add a trailing citation such as: "[RFC2923] documents operational issues with PMTUD that apply equally to IPv4 and IPv6." Section 2.1: ************ Under the heading: "In Strategy 1", this seems to be taking a view that applies only to IPv4 (and not IPv6). Suggest rewriting as: "In Strategy 1, the tunnel ingress router encapsulates the entire payload into a single GRE-delivery packet, then fragments the packet if necessary and forwards each fragment in the direction of the tunnel egress. For IPv4, if any fragment exceeds the LMTU of any link along the path to the tunnel egress, the router directly upstream of that link fragments it (further). The tunnel egress router reassembles the GRE-delivery packet, de-encapsulates its payload, and processes the payload appropriately." Section 2.1: ************ Under the heading: "In Strategy 2", this again seems to be taking a view that applies only to IPv4. Suggest rewriting as: "In Strategy 2, the tunnel ingress router performs PMTUD procedures or some variant thereof (e.g., PLMTUD). When the tunnel ingress router receives a non-fragmentable packet that is larger than the minimum IP MTU and also so large that it cannot be forwarded through the tunnel, it discards the packet and sends an ICMPv4 "fragmentation needed" [RFC0792][RFC1191] or an ICMPv6 "packet too big" [RFC1981] message to the packet source. The ICMP message contains a Next-hop MTU equal to the TMTU associated with the tunnel. If the ICMP message reaches the packet source, and if the packet source executes PMTUD procedures, the packet source adjusts its PMTU for the packet destination and emits subsequent packets with size less than the TMTU." Section 2.1: ************ Under the heading: "In Strategy 3", change: "less than the TMTU of any tunnel" to: "greater than the TMTU of any tunnel". Section 2.1: ************ Under the heading: "Strategy 1 is an attractive alternative to Strategy 1...", Suggest rewriting to: "Strategy 1 is an attractive alternative to Strategy 2, because it does not rely on PMTU. However, Strategy 1 may not be operationally practical in all environments because it assigns the task of reassembly to the tunnel egress router. When the tunnel supports high data rates, reassembly at the tunnel egress can be cost-prohibitive. For IPv4, the tunnel ingress must also monitor the rate at which it sends in order to avoid reassembly misassociations [RFC4963]." Section 2.2: ************ This section seems to forget that the tunnel MUST support the minimum MTU for IPv4/IPv6. So, if PMTUD within the tunnel is broken, and if the tunnel receives a non-fragmentable packet that is no larger than minMTU but larger than the tunnel can pass in one piece, the tunnel ingress MUST encapsulate the packet and perform fragmentation on the encapsulated packet before sending each fragment toward the egress. The same is true for both IPv4 and IPv6, and the text needs to say this. Section 3.2: ************ The statement: "When PMTUD is disabled, the TMTU MUST be set to a value that is less than or equal to the LMTU associated with the next-hop towards the tunnel egress, minus the GRE overhead." In this statement, how can the tunnel ingress discover the smallest LMTU of all links on the path to the tunnel egress if PMTUD is disabled? Only options are to either do some sort of out-of-band path probing, or to assume the minimum MTU (1280 for IPv6 or 576 for IPv4). The text doesn't currently say this, but needs to. Section 4.1: ************ This section is missing the mark in that it does not talk at all about the minimum MTU the tunnel MUST support. Packets that are no larger than the IPv4/IPv6 minimum MTU MUST be admitted into the tunnel even if it means some fragmentation may be necessary. Section 4.2: ************ This section needs re-working. For tunnels over IPv6, if the packet is no larger than the IPv6 minMTU (1280 bytes) but larger than TMTU, then the tunnel ingress MUST fragment it and have the fragments reassembled by the tunnel egress; it has no other choice if it means to be compliant with RFC2460. Section 5.1: ************ This section does not currently honor the IPv4 minMTU of 576 bytes. In particular, for packets that are no larger than the IPv4 minMTU the tunnel ingress MUST ensure that the packet is delivered to the tunnel egress even if some fragmentation is necessary. Section 5.2: ************ This section does not currently honor the IPv6 minMTU of 1280 bytes. In particular, for packets that are no larger than the IPv6 minMTU the tunnel ingress MUST ensure that the packet is delivered to the tunnel egress even if some fragmentation is necessary. From linda.dunbar@huawei.com Tue Jun 25 07:05:18 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454D321E80AE for ; Tue, 25 Jun 2013 07:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6PmEczPoUdr for ; Tue, 25 Jun 2013 07:05:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 88DFD21E8063 for ; Tue, 25 Jun 2013 07:05:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUJ26166; Tue, 25 Jun 2013 14:05:10 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 25 Jun 2013 15:04:03 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 25 Jun 2013 15:04:43 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Tue, 25 Jun 2013 07:04:38 -0700 From: Linda Dunbar To: Joe Touch , "Carlos Pignataro (cpignata)" Thread-Topic: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt Thread-Index: AQHOYIIHCLVTT1AFqk2vPhrKL3inOJklHViAgAAG3YCAH/zjQA== Date: Tue, 25 Jun 2013 14:04:38 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B3D1CC@dfweml509-mbx.china.huawei.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645B3615C@dfweml509-mbx.china.huawei.com> <51A665B1.40507@isi.edu> <95067C434CE250468B77282634C96ED322BD8932@xmb-aln-x02.cisco.com> <51ACD5DF.7040800@isi.edu> <95067C434CE250468B77282634C96ED322BDF244@xmb-aln-x02.cisco.com> <51AD307D.1070007@isi.edu> In-Reply-To: <51AD307D.1070007@isi.edu> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Ronald Bonica , Internet Area Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 14:05:18 -0000 Ron,=20 Your draft recommends that the ingress node discards the frame and sends IC= MP msg to the source node when the size of GRE encapsulated frame exceeds l= ink MTU.=20 We experienced that Window XP doesn't adjust frame size after receiving ICM= P message. Many Linux based applications don't do anything either with the = MTU ICMP message. I think your draft should point those issues out and reco= mmend fragmentation approach under those circumstances.=20 Linda =20 From touch@isi.edu Tue Jun 25 09:51:09 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B191321FA000 for ; Tue, 25 Jun 2013 09:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104 X-Spam-Level: X-Spam-Status: No, score=-104 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJS8W8N6dARW for ; Tue, 25 Jun 2013 09:51:03 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id D9E0821F9A00 for ; Tue, 25 Jun 2013 09:51:03 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r5PGnSLt020611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Jun 2013 09:49:30 -0700 (PDT) Message-ID: <51C9C9FD.2080406@isi.edu> Date: Tue, 25 Jun 2013 09:49:01 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Linda Dunbar References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645B3615C@dfweml509-mbx.china.huawei.com> <51A665B1.40507@isi.edu> <95067C434CE250468B77282634C96ED322BD8932@xmb-aln-x02.cisco.com> <51ACD5DF.7040800@isi.edu> <95067C434CE250468B77282634C96ED322BDF244@xmb-aln-x02.cisco.com> <51AD307D.1070007@isi.edu> <4A95BA014132FF49AE685FAB4B9F17F645B3D1CC@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B3D1CC@dfweml509-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Carlos Pignataro \(cpignata\)" , Internet Area , Ronald Bonica Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 16:51:09 -0000 On 6/25/2013 7:04 AM, Linda Dunbar wrote: > Ron, > > Your draft recommends that the ingress node discards the frame and > sends ICMP msg to the source node when the size of GRE encapsulated > frame exceeds link MTU. > We experienced that Window XP doesn't adjust frame size after > receiving ICMP message. Many Linux based applications don't do anything > either with the MTU ICMP message. I think your draft should point those > issues out and recommend fragmentation approach under those circumstances. Do these apps set DF=1? If so, they ought to be prepared to handle ICMP PTB messages. If not, they shouldn't be setting PTB. However, my view remains that PTB is for when a link cannot handle a packet - not when it chooses not to do so electively. The only packet that ought to be too big for GRE is one that exceeds the max payload of IP after encapsulation. Others ought to be fragmented at the GRE ingress and reassembled at the GRE egress at the outer IP layer, exactly because IP *can* do this. Joe From cpignata@cisco.com Tue Jun 25 10:22:44 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5575F21F9BAA for ; Tue, 25 Jun 2013 10:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1B7l5NxD4j5 for ; Tue, 25 Jun 2013 10:22:37 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id ADB3621F9A86 for ; Tue, 25 Jun 2013 10:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1456; q=dns/txt; s=iport; t=1372180957; x=1373390557; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JX5B1e3OPfTlcIuSz3Ig/zLESfOf2oNGMl96KphwLmc=; b=EJS2HPYHi/xgrY4E2NnqtX6pes4kz8/ByVkdBCSruYwf3EEk6l4XyWo6 6tPDHEZluKtLK/fF10GSENUOptbukl+7ReUCb48haiDnWqC4AE8KrOBqJ 69H3HjNMYz+1dsiD3MII1DRrd6g2YwjRwnCoS7MHXnMoj7HCkznPmpq5q M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAKHQyVGtJXG//2dsb2JhbABaDoJ7wDOBBhZ0giMBAQEDATo9AhACAQgYHhAyJQIEDgWICAa7c48SMweDAmEDl0ORRIJSPoFoBg X-IronPort-AV: E=Sophos;i="4.87,938,1363132800"; d="scan'208";a="227288756" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 25 Jun 2013 17:22:37 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5PHMbMQ022677 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Jun 2013 17:22:37 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Tue, 25 Jun 2013 12:22:35 -0500 From: "Carlos Pignataro (cpignata)" To: Joe Touch Thread-Topic: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt Thread-Index: AQHOYIIMa1mBCKLTbEayE5IJHrB8Epkk/CuAgAAGg4CAIen7AIAALe2A//+1kJY= Date: Tue, 25 Jun 2013 17:22:35 +0000 Message-ID: References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645B3615C@dfweml509-mbx.china.huawei.com> <51A665B1.40507@isi.edu> <95067C434CE250468B77282634C96ED322BD8932@xmb-aln-x02.cisco.com> <51ACD5DF.7040800@isi.edu> <95067C434CE250468B77282634C96ED322BDF244@xmb-aln-x02.cisco.com> <51AD307D.1070007@isi.edu> <4A95BA014132FF49AE685FAB4B9F17F645B3D1CC@dfweml509-mbx.china.huawei.com>, <51C9C9FD.2080406@isi.edu> In-Reply-To: <51C9C9FD.2080406@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ronald Bonica , Internet Area Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 17:22:44 -0000 Joe, On Jun 25, 2013, at 12:50 PM, "Joe Touch" wrote: >=20 >=20 > On 6/25/2013 7:04 AM, Linda Dunbar wrote: >> Ron, >>=20 >> Your draft recommends that the ingress node discards the frame and >> sends ICMP msg to the source node when the size of GRE encapsulated >> frame exceeds link MTU. >> We experienced that Window XP doesn't adjust frame size after >> receiving ICMP message. Many Linux based applications don't do anything >> either with the MTU ICMP message. I think your draft should point those >> issues out and recommend fragmentation approach under those circumstance= s. >=20 > Do these apps set DF=3D1? If so, they ought to be prepared to handle ICMP= PTB messages. If not, they shouldn't be setting PTB. >=20 > However, my view remains that PTB is for when a link cannot handle a pack= et - not when it chooses not to do so electively. The only packet that ough= t to be too big for GRE is one that exceeds the max payload of IP after enc= apsulation. Others ought to be fragmented at the GRE ingress and reassemble= d at the GRE egress at the outer IP layer, exactly because IP *can* do this= . If a physical link has an MTU of 1500, can you configure it and set it to b= e 1300, despite the hardware being able to do 1500? Are you suggesting that a GRE tunnel has a Tunnel MTU of 65535 - encap alwa= ys? >=20 > Joe Thumb typed by Carlos Pignataro. Excuze typofraphicak errows From touch@isi.edu Tue Jun 25 11:14:49 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C6221E80CD for ; Tue, 25 Jun 2013 11:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.3 X-Spam-Level: X-Spam-Status: No, score=-105.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpGWtOrEslE8 for ; Tue, 25 Jun 2013 11:14:43 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 03D0121E80C1 for ; Tue, 25 Jun 2013 11:14:42 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5PIDovt029598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Jun 2013 11:13:50 -0700 (PDT) Message-ID: <51C9DDC2.6090904@isi.edu> Date: Tue, 25 Jun 2013 11:13:22 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645B3615C@dfweml509-mbx.china.huawei.com> <51A665B1.40507@isi.edu> <95067C434CE250468B77282634C96ED322BD8932@xmb-aln-x02.cisco.com> <51ACD5DF.7040800@isi.edu> <95067C434CE250468B77282634C96ED322BDF244@xmb-aln-x02.cisco.com> <51AD307D.1070007@isi.edu> <4A95BA014132FF49AE685FAB4B9F17F645B3D1CC@dfweml509-mbx.china.huawei.com>, <51C9C9FD.2080406@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Ronald Bonica , Internet Area Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 18:14:49 -0000 On 6/25/2013 10:22 AM, Carlos Pignataro (cpignata) wrote: > Joe, > > On Jun 25, 2013, at 12:50 PM, "Joe Touch" wrote: > >> >> >> On 6/25/2013 7:04 AM, Linda Dunbar wrote: >>> Ron, >>> >>> Your draft recommends that the ingress node discards the frame and >>> sends ICMP msg to the source node when the size of GRE encapsulated >>> frame exceeds link MTU. >>> We experienced that Window XP doesn't adjust frame size after >>> receiving ICMP message. Many Linux based applications don't do anything >>> either with the MTU ICMP message. I think your draft should point those >>> issues out and recommend fragmentation approach under those circumstances. >> >> Do these apps set DF=1? If so, they ought to be prepared to handle ICMP PTB messages. If not, they shouldn't be setting PTB. >> >> However, my view remains that PTB is for when a link cannot handle a packet - not when it chooses not to do so electively. The only packet that ought to be too big for GRE is one that exceeds the max payload of IP after encapsulation. Others ought to be fragmented at the GRE ingress and reassembled at the GRE egress at the outer IP layer, exactly because IP *can* do this. > > If a physical link has an MTU of 1500, can you configure it and set it to be 1300, despite the hardware being able to do 1500? > > Are you suggesting that a GRE tunnel has a Tunnel MTU of 65535 - encap always? A GRE tunnel, IMO, has the MTU of whatever its outer encapsulation is. I.e., GRE over IP with no options has an MTU of 65535-40-{gre_size}. Beyond that it *cannot* reassemble. Joe From Fred.L.Templin@boeing.com Tue Jun 25 12:08:34 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F45D21F9AA9 for ; Tue, 25 Jun 2013 12:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.3 X-Spam-Level: X-Spam-Status: No, score=-5.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGEexMAw7soQ for ; Tue, 25 Jun 2013 12:08:27 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6FF21F99BC for ; Tue, 25 Jun 2013 12:08:22 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r5PJ8L4H026382 for ; Tue, 25 Jun 2013 14:08:21 -0500 Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r5PJ8Kj8026367 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 25 Jun 2013 14:08:21 -0500 Received: from XCH-EXCO-103.nw.nos.boeing.com (130.247.25.37) by XCH-NWHT-03.nw.nos.boeing.com (130.247.71.23) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 25 Jun 2013 12:08:20 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-EXCO-103.nw.nos.boeing.com ([fe80::7434:66d:a0ba:2234%15]) with mapi id 14.02.0328.011; Tue, 25 Jun 2013 12:08:20 -0700 From: "Templin, Fred L" To: Joe Touch , "Carlos Pignataro (cpignata)" Thread-Topic: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt Thread-Index: AQHOcc/mXu3gHRCrPkSFCxN9F2j9lZlGx6CA Date: Tue, 25 Jun 2013 19:08:19 +0000 Message-ID: <2134F8430051B64F815C691A62D983180AA7CC@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645B3615C@dfweml509-mbx.china.huawei.com> <51A665B1.40507@isi.edu> <95067C434CE250468B77282634C96ED322BD8932@xmb-aln-x02.cisco.com> <51ACD5DF.7040800@isi.edu> <95067C434CE250468B77282634C96ED322BDF244@xmb-aln-x02.cisco.com> <51AD307D.1070007@isi.edu> <4A95BA014132FF49AE685FAB4B9F17F645B3D1CC@dfweml509-mbx.china.huawei.com>, <51C9C9FD.2080406@isi.edu> <51C9DDC2.6090904@isi.edu> In-Reply-To: <51C9DDC2.6090904@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: Ronald Bonica , Internet Area Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 19:08:34 -0000 > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of Joe Touch > Sent: Tuesday, June 25, 2013 11:13 AM > To: Carlos Pignataro (cpignata) > Cc: Ronald Bonica; Internet Area > Subject: Re: [Int-area] New Version Notification for draft-bonica- > intarea-gre-mtu-00.txt >=20 >=20 >=20 > On 6/25/2013 10:22 AM, Carlos Pignataro (cpignata) wrote: > > Joe, > > > > On Jun 25, 2013, at 12:50 PM, "Joe Touch" wrote: > > > >> > >> > >> On 6/25/2013 7:04 AM, Linda Dunbar wrote: > >>> Ron, > >>> > >>> Your draft recommends that the ingress node discards the frame and > >>> sends ICMP msg to the source node when the size of GRE encapsulated > >>> frame exceeds link MTU. > >>> We experienced that Window XP doesn't adjust frame size after > >>> receiving ICMP message. Many Linux based applications don't do > anything > >>> either with the MTU ICMP message. I think your draft should point > those > >>> issues out and recommend fragmentation approach under those > circumstances. > >> > >> Do these apps set DF=3D1? If so, they ought to be prepared to handle > ICMP PTB messages. If not, they shouldn't be setting PTB. > >> > >> However, my view remains that PTB is for when a link cannot handle a > packet - not when it chooses not to do so electively. The only packet > that ought to be too big for GRE is one that exceeds the max payload of > IP after encapsulation. Others ought to be fragmented at the GRE > ingress and reassembled at the GRE egress at the outer IP layer, > exactly because IP *can* do this. > > > > If a physical link has an MTU of 1500, can you configure it and set > it to be 1300, despite the hardware being able to do 1500? > > > > Are you suggesting that a GRE tunnel has a Tunnel MTU of 65535 - > encap always? >=20 > A GRE tunnel, IMO, has the MTU of whatever its outer encapsulation is. >=20 > I.e., GRE over IP with no options has an MTU of 65535-40-{gre_size}. > Beyond that it *cannot* reassemble. I have a slightly different view, but one that still involves fragmentation. The GRE tunnel MUST observe the minimum IPv6 MTU of 1280 bytes. But, to uphold the de facto Internet cell size of 1500 bytes we should extend this up to 1500. So, if the MTU within the tunnel is unknown and/or unknowable, then the ingress MUST use fragmentation to make sure that packets no larger than 1500 bytes get through - the egress then gets to reassemble. Packets larger than 1500 can be admitted into the tunnel unfragmented and allowed to sink or swim on their own. The ingress may or may not get ICMP PTBs if one of these is dropped, but the source should be using RFC4821 when it sends packets larger than 1500 bytes anyway, so loss of PTBs should not affect the hosts. Thanks - Fred fred.l.templin@boeing.com > Joe > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From touch@isi.edu Tue Jun 25 14:39:06 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67BF11E8164 for ; Tue, 25 Jun 2013 14:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.949 X-Spam-Level: X-Spam-Status: No, score=-103.949 tagged_above=-999 required=5 tests=[AWL=-1.350, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEyVPNjh5yxB for ; Tue, 25 Jun 2013 14:39:01 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 046FE11E8162 for ; Tue, 25 Jun 2013 14:39:00 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r5PLcSYC029902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Jun 2013 14:38:28 -0700 (PDT) Message-ID: <51CA0DB8.6090401@isi.edu> Date: Tue, 25 Jun 2013 14:38:00 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Templin, Fred L" References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645B3615C@dfweml509-mbx.china.huawei.com> <51A665B1.40507@isi.edu> <95067C434CE250468B77282634C96ED322BD8932@xmb-aln-x02.cisco.com> <51ACD5DF.7040800@isi.edu> <95067C434CE250468B77282634C96ED322BDF244@xmb-aln-x02.cisco.com> <51AD307D.1070007@isi.edu> <4A95BA014132FF49AE685FAB4B9F17F645B3D1CC@dfweml509-mbx.china.huawei.com>, <51C9C9FD.2080406@isi.edu> <51C9DDC2.6090904@isi.edu> <2134F8430051B64F815C691A62D983180AA7CC@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180AA7CC@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Carlos Pignataro \(cpignata\)" , Internet Area , Ronald Bonica Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 21:39:07 -0000 Hi, Fred, ... >> A GRE tunnel, IMO, has the MTU of whatever its outer encapsulation is. >> >> I.e., GRE over IP with no options has an MTU of 65535-40-{gre_size}. >> Beyond that it *cannot* reassemble. > > I have a slightly different view, but one that still involves > fragmentation. The GRE tunnel MUST observe the minimum IPv6 MTU > of 1280 bytes. In what it sends over IP (i.e., in the chunks it uses to transit from ingress to egress). There's no reason to impose that limit on what it receives at the ingress. > But, to uphold the de facto Internet cell size of > 1500 bytes we should extend this up to 1500. So, if the MTU within > the tunnel is unknown and/or unknowable, then the ingress MUST use > fragmentation to make sure that packets no larger than 1500 bytes > get through - the egress then gets to reassemble. This is an artificial limit that is unnecessary. IMO, MTU is just that - "MAXIMUM". Not 'preferred'. So if GRE *can* transit packets arriving at the ingress that are 65535-IP-GRE, why should it do otherwise? (yes, it *can* be configured lower if desired, just as with any other link, but there's no reason to assume 'lower than maximum' as a default) > Packets larger than 1500 can be admitted into the tunnel unfragmented > and allowed to sink or swim on their own. Whether and how much GRE fragments what it receives at an ingress ought to be determined by its understanding of its own ingress-egress MTU capability. However, those fragments are not directly related to what the tunnel can transit *because* the ingress can fragment and the egress can reassemble. Acting like the ingress and egress can't participate in frag/reassembly of the outer packet introduces an artificial limit to GRE tunnels. If that's what you want to do - or what has already been done - that's fine, but *that* is what is suboptimal. > The ingress may or may not > get ICMP PTBs if one of these is dropped, but the source should be > using RFC4821 when it sends packets larger than 1500 bytes anyway, > so loss of PTBs should not affect the hosts. Agreed on that point, but not the 1500-byte transit limit. Joe From Fred.L.Templin@boeing.com Tue Jun 25 15:01:32 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DE111E815C for ; Tue, 25 Jun 2013 15:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5Yjswbw-Wfm for ; Tue, 25 Jun 2013 15:01:26 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 16A8E11E812F for ; Tue, 25 Jun 2013 15:01:26 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r5PM1Ooi018193 for ; Tue, 25 Jun 2013 15:01:24 -0700 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r5PM1NFe018106 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 25 Jun 2013 15:01:23 -0700 Received: from XCH-BLV-307.nw.nos.boeing.com (130.247.25.219) by XCH-NWHT-05.nw.nos.boeing.com (130.247.25.109) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 25 Jun 2013 15:01:23 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-BLV-307.nw.nos.boeing.com ([169.254.7.161]) with mapi id 14.02.0328.011; Tue, 25 Jun 2013 15:01:23 -0700 From: "Templin, Fred L" To: Joe Touch Thread-Topic: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt Thread-Index: AQHOcexv4CDeOS4hME2jCEFNN9O7c5lG9d2A Date: Tue, 25 Jun 2013 22:01:23 +0000 Message-ID: <2134F8430051B64F815C691A62D983180AAB85@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645B3615C@dfweml509-mbx.china.huawei.com> <51A665B1.40507@isi.edu> <95067C434CE250468B77282634C96ED322BD8932@xmb-aln-x02.cisco.com> <51ACD5DF.7040800@isi.edu> <95067C434CE250468B77282634C96ED322BDF244@xmb-aln-x02.cisco.com> <51AD307D.1070007@isi.edu> <4A95BA014132FF49AE685FAB4B9F17F645B3D1CC@dfweml509-mbx.china.huawei.com>, <51C9C9FD.2080406@isi.edu> <51C9DDC2.6090904@isi.edu> <2134F8430051B64F815C691A62D983180AA7CC@XCH-BLV-504.nw.nos.boeing.com> <51CA0DB8.6090401@isi.edu> In-Reply-To: <51CA0DB8.6090401@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "Carlos Pignataro \(cpignata\)" , Internet Area , Ronald Bonica Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 22:01:32 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, June 25, 2013 2:38 PM > To: Templin, Fred L > Cc: Carlos Pignataro (cpignata); Ronald Bonica; Internet Area > Subject: Re: [Int-area] New Version Notification for draft-bonica- > intarea-gre-mtu-00.txt >=20 > Hi, Fred, >=20 > ... > >> A GRE tunnel, IMO, has the MTU of whatever its outer encapsulation > is. > >> > >> I.e., GRE over IP with no options has an MTU of 65535-40-{gre_size}. > >> Beyond that it *cannot* reassemble. > > > > I have a slightly different view, but one that still involves > > fragmentation. The GRE tunnel MUST observe the minimum IPv6 MTU > > of 1280 bytes. >=20 > In what it sends over IP (i.e., in the chunks it uses to transit from > ingress to egress). There's no reason to impose that limit on what it > receives at the ingress. What I am suggesting is that the tunnel ingress sets an indefinite MTU, meaning that all packets are admitted into the tunnel regardless of their size. But, see more below...=20 > > But, to uphold the de facto Internet cell size of > > 1500 bytes we should extend this up to 1500. So, if the MTU within > > the tunnel is unknown and/or unknowable, then the ingress MUST use > > fragmentation to make sure that packets no larger than 1500 bytes > > get through - the egress then gets to reassemble. >=20 > This is an artificial limit that is unnecessary. What I am after is a fragmentation threshold designed to set an upper bound on the amount the tunnel egress will have to reassemble. This also happens to be the size of packets that MUST make it through the tunnel. IPv6 says that this value must be set to 1280 at a minimum. I am saying that it should be bumped up to 1500 to mirror the minimum MTU used on the vast majority of links in the Internet today. But, see more below... =20 > IMO, MTU is just that - "MAXIMUM". Not 'preferred'. So if GRE *can* > transit packets arriving at the ingress that are 65535-IP-GRE, why > should it do otherwise? What I am saying is that all packets are admitted into the tunnel regardless of their size, but the tunnel will use fragmentation only for those packets that MUST make it through to the other side, i.e., all packets that are no larger than 1500 bytes. This means that the tunnel egress need only configure a reassembly buffer size of 1500 bytes plus the tunnel overhead. Packets larger than 1500 bytes will still make it through the tunnel (in one piece) if the MTU within the tunnel can accommodate that size. But, the most the ingress will ever ask the egress to reassemble is 1500 (plus overhead). =20 > (yes, it *can* be configured lower if desired, just as with any other > link, but there's no reason to assume 'lower than maximum' as a > default) >=20 > > Packets larger than 1500 can be admitted into the tunnel unfragmented > > and allowed to sink or swim on their own. >=20 > Whether and how much GRE fragments what it receives at an ingress ought > to be determined by its understanding of its own ingress-egress MTU > capability. However, those fragments are not directly related to what > the tunnel can transit *because* the ingress can fragment and the > egress > can reassemble. Right. The egress has to reassemble whatever the ingress fragments. What I am saying is that the ingress put a conservative upper bound on the amount it will ever ask the egress to reassemble. > Acting like the ingress and egress can't participate in frag/reassembly > of the outer packet introduces an artificial limit to GRE tunnels. If > that's what you want to do - or what has already been done - that's > fine, but *that* is what is suboptimal. No, I fully agree that *some* fragmentation and reassembly is necessary. I'm just saying that the ingress should set a limit on the most it would ever ask the egress to reassemble. But, that does *not* put an artificial limit on the tunnel MTU.=20 > > The ingress may or may not > > get ICMP PTBs if one of these is dropped, but the source should be > > using RFC4821 when it sends packets larger than 1500 bytes anyway, > > so loss of PTBs should not affect the hosts. >=20 > Agreed on that point, but not the 1500-byte transit limit. Please reread the algorithm I proposed, Joe. What I am suggesting is an "infinite" tunnel ingress MTU - not a 1500 byte MTU. Thanks - Fred fred.l.templin@boeing.com > Joe From touch@isi.edu Tue Jun 25 15:19:59 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31AD011E8161 for ; Tue, 25 Jun 2013 15:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9tmovvsJEjj for ; Tue, 25 Jun 2013 15:19:53 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 354FF11E812F for ; Tue, 25 Jun 2013 15:19:53 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r5PMJR5i013124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Jun 2013 15:19:29 -0700 (PDT) Message-ID: <51CA1771.6020304@isi.edu> Date: Tue, 25 Jun 2013 15:19:29 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Templin, Fred L" References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645B3615C@dfweml509-mbx.china.huawei.com> <51A665B1.40507@isi.edu> <95067C434CE250468B77282634C96ED322BD8932@xmb-aln-x02.cisco.com> <51ACD5DF.7040800@isi.edu> <95067C434CE250468B77282634C96ED322BDF244@xmb-aln-x02.cisco.com> <51AD307D.1070007@isi.edu> <4A95BA014132FF49AE685FAB4B9F17F645B3D1CC@dfweml509-mbx.china.huawei.com>, <51C9C9FD.2080406@isi.edu> <51C9DDC2.6090904@isi.edu> <2134F8430051B64F815C691A62D983180AA7CC@XCH-BLV-504.nw.nos.boeing.com> <51CA0DB8.6090401@isi.edu> <2134F8430051B64F815C691A62D983180AAB85@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180AAB85@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Carlos Pignataro \(cpignata\)" , Internet Area , Ronald Bonica Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 22:19:59 -0000 Hi, Fred, On 6/25/2013 3:01 PM, Templin, Fred L wrote: > Hi Joe, > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Tuesday, June 25, 2013 2:38 PM >> To: Templin, Fred L >> Cc: Carlos Pignataro (cpignata); Ronald Bonica; Internet Area >> Subject: Re: [Int-area] New Version Notification for draft-bonica- >> intarea-gre-mtu-00.txt >> >> Hi, Fred, >> >> ... >>>> A GRE tunnel, IMO, has the MTU of whatever its outer encapsulation >> is. >>>> >>>> I.e., GRE over IP with no options has an MTU of 65535-40-{gre_size}. >>>> Beyond that it *cannot* reassemble. >>> >>> I have a slightly different view, but one that still involves >>> fragmentation. The GRE tunnel MUST observe the minimum IPv6 MTU >>> of 1280 bytes. >> >> In what it sends over IP (i.e., in the chunks it uses to transit from >> ingress to egress). There's no reason to impose that limit on what it >> receives at the ingress. > > What I am suggesting is that the tunnel ingress sets an indefinite > MTU, meaning that all packets are admitted into the tunnel regardless > of their size. But, see more below... > >>> But, to uphold the de facto Internet cell size of >>> 1500 bytes we should extend this up to 1500. So, if the MTU within >>> the tunnel is unknown and/or unknowable, then the ingress MUST use >>> fragmentation to make sure that packets no larger than 1500 bytes >>> get through - the egress then gets to reassemble. >> >> This is an artificial limit that is unnecessary. > > What I am after is a fragmentation threshold designed to set an > upper bound on the amount the tunnel egress will have to reassemble. > This also happens to be the size of packets that MUST make it through > the tunnel. IPv6 says that this value must be set to 1280 at a minimum. > I am saying that it should be bumped up to 1500 to mirror the minimum > MTU used on the vast majority of links in the Internet today. But, see > more below... You're introducing an artificial limit based on the assumption that GRE should never transit more than the minimum, but there's no reason for that limit; GRE is sourcing packets to the egress, and can easily generate and reassemble fragments. The rest of the path may impose a limit - such as based on transiting Ethernet, but there's no reason to introduce that limit here. >> IMO, MTU is just that - "MAXIMUM". Not 'preferred'. So if GRE *can* >> transit packets arriving at the ingress that are 65535-IP-GRE, why >> should it do otherwise? > > What I am saying is that all packets are admitted into the tunnel > regardless of their size, but the tunnel will use fragmentation only > for those packets that MUST make it through to the other side, i.e., > all packets that are no larger than 1500 bytes. Why? Why are you introducing that as an artificial constraint for GRE? > This means that the > tunnel egress need only configure a reassembly buffer size of 1500 > bytes plus the tunnel overhead. Packets larger than 1500 bytes will > still make it through the tunnel (in one piece) if the MTU within the > tunnel can accommodate that size. But, the most the ingress will ever > ask the egress to reassemble is 1500 (plus overhead). IP reassembly requires tsupport for max-size IP packets, not just ones whose sizes you like ;-) >> (yes, it *can* be configured lower if desired, just as with any other >> link, but there's no reason to assume 'lower than maximum' as a >> default) >> >>> Packets larger than 1500 can be admitted into the tunnel unfragmented >>> and allowed to sink or swim on their own. >> >> Whether and how much GRE fragments what it receives at an ingress ought >> to be determined by its understanding of its own ingress-egress MTU >> capability. However, those fragments are not directly related to what >> the tunnel can transit *because* the ingress can fragment and the >> egress >> can reassemble. > > Right. The egress has to reassemble whatever the ingress fragments. > What I am saying is that the ingress put a conservative upper bound > on the amount it will ever ask the egress to reassemble. If the egress supports IPv6, the upper bound is already 66635. Why are you introducing a lower constraint when that's already required? >> Acting like the ingress and egress can't participate in frag/reassembly >> of the outer packet introduces an artificial limit to GRE tunnels. If >> that's what you want to do - or what has already been done - that's >> fine, but *that* is what is suboptimal. > > No, I fully agree that *some* fragmentation and reassembly is > necessary. I'm just saying that the ingress should set a limit > on the most it would ever ask the egress to reassemble. But, > that does *not* put an artificial limit on the tunnel MTU. But that's what you're doing; you will reject packets larger than 1500 that transit, even though you can reassemble them (and you have to if you implement IPv6 reassembly anyway). I understand what you're trying to save, but an IP encapsulation egress is still required to support IPv6 host-side capabilities, so there's no savings. >> > The ingress may or may not >>> get ICMP PTBs if one of these is dropped, but the source should be >>> using RFC4821 when it sends packets larger than 1500 bytes anyway, >>> so loss of PTBs should not affect the hosts. >> >> Agreed on that point, but not the 1500-byte transit limit. > > Please reread the algorithm I proposed, Joe. What I am suggesting > is an "infinite" tunnel ingress MTU - not a 1500 byte MTU. > > Thanks - Fred > fred.l.templin@boeing.com > >> Joe > From Fred.L.Templin@boeing.com Tue Jun 25 15:32:53 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8168421E80D7 for ; Tue, 25 Jun 2013 15:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7AMeIQxq2ry for ; Tue, 25 Jun 2013 15:32:47 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 429BE11E814D for ; Tue, 25 Jun 2013 15:32:47 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r5PMWk05003730 for ; Tue, 25 Jun 2013 15:32:46 -0700 Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r5PMWjUb003726 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 25 Jun 2013 15:32:46 -0700 Received: from XCH-BLV-204.nw.nos.boeing.com (10.57.37.58) by XCH-NWHT-03.nw.nos.boeing.com (130.247.71.23) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 25 Jun 2013 15:32:45 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-BLV-204.nw.nos.boeing.com ([169.254.4.84]) with mapi id 14.02.0328.011; Tue, 25 Jun 2013 15:32:44 -0700 From: "Templin, Fred L" To: Joe Touch Thread-Topic: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt Thread-Index: AQHOcfIP4CDeOS4hME2jCEFNN9O7c5lHAL8w Date: Tue, 25 Jun 2013 22:32:44 +0000 Message-ID: <2134F8430051B64F815C691A62D983180AABF9@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645B3615C@dfweml509-mbx.china.huawei.com> <51A665B1.40507@isi.edu> <95067C434CE250468B77282634C96ED322BD8932@xmb-aln-x02.cisco.com> <51ACD5DF.7040800@isi.edu> <95067C434CE250468B77282634C96ED322BDF244@xmb-aln-x02.cisco.com> <51AD307D.1070007@isi.edu> <4A95BA014132FF49AE685FAB4B9F17F645B3D1CC@dfweml509-mbx.china.huawei.com>, <51C9C9FD.2080406@isi.edu> <51C9DDC2.6090904@isi.edu> <2134F8430051B64F815C691A62D983180AA7CC@XCH-BLV-504.nw.nos.boeing.com> <51CA0DB8.6090401@isi.edu> <2134F8430051B64F815C691A62D983180AAB85@XCH-BLV-504.nw.nos.boeing.com> <51CA1771.6020304@isi.edu> In-Reply-To: <51CA1771.6020304@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "Carlos Pignataro \(cpignata\)" , Internet Area , Ronald Bonica Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 22:32:53 -0000 Hi Joe, The constraint you seem to be missing is that RFC2460 only requires IPv6 nodes to reassemble as much as 1500 bytes. Nodes are permitted to reassemble more than that, but 1500 is all that can be expected unless there is specification stating that it needs to be more. Granted, my algorithm is asking GRE egress tunnel endpoints to configure a reassembly buffer size of 1500 *plus* the tunnel encapsulation overhead, which is more than RFC2460 ensures. But, it will never ask for more than that. Also think about it this way. Why should the tunnel work hard to pass a packet that is larger than 1500 bytes and also larger than the minimum link MTU within the tunneled path when the source could instead adjust the size of the packets it is sending downward? Such "jumbos" should be dropped by the tunnel and not accommodated by a resource-intensive process such as frag/reass. "Take care of the smalls, and let the bigs take care of themselves." BTW, the algorithm I have articulated is exactly the SEAL algorithm. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, June 25, 2013 3:19 PM > To: Templin, Fred L > Cc: Carlos Pignataro (cpignata); Ronald Bonica; Internet Area > Subject: Re: [Int-area] New Version Notification for draft-bonica- > intarea-gre-mtu-00.txt >=20 > Hi, Fred, >=20 > On 6/25/2013 3:01 PM, Templin, Fred L wrote: > > Hi Joe, > > > >> -----Original Message----- > >> From: Joe Touch [mailto:touch@isi.edu] > >> Sent: Tuesday, June 25, 2013 2:38 PM > >> To: Templin, Fred L > >> Cc: Carlos Pignataro (cpignata); Ronald Bonica; Internet Area > >> Subject: Re: [Int-area] New Version Notification for draft-bonica- > >> intarea-gre-mtu-00.txt > >> > >> Hi, Fred, > >> > >> ... > >>>> A GRE tunnel, IMO, has the MTU of whatever its outer encapsulation > >> is. > >>>> > >>>> I.e., GRE over IP with no options has an MTU of 65535-40- > {gre_size}. > >>>> Beyond that it *cannot* reassemble. > >>> > >>> I have a slightly different view, but one that still involves > >>> fragmentation. The GRE tunnel MUST observe the minimum IPv6 MTU > >>> of 1280 bytes. > >> > >> In what it sends over IP (i.e., in the chunks it uses to transit > from > >> ingress to egress). There's no reason to impose that limit on what > it > >> receives at the ingress. > > > > What I am suggesting is that the tunnel ingress sets an indefinite > > MTU, meaning that all packets are admitted into the tunnel regardless > > of their size. But, see more below... > > > >>> But, to uphold the de facto Internet cell size of > >>> 1500 bytes we should extend this up to 1500. So, if the MTU within > >>> the tunnel is unknown and/or unknowable, then the ingress MUST use > >>> fragmentation to make sure that packets no larger than 1500 bytes > >>> get through - the egress then gets to reassemble. > >> > >> This is an artificial limit that is unnecessary. > > > > What I am after is a fragmentation threshold designed to set an > > upper bound on the amount the tunnel egress will have to reassemble. > > This also happens to be the size of packets that MUST make it through > > the tunnel. IPv6 says that this value must be set to 1280 at a > minimum. > > I am saying that it should be bumped up to 1500 to mirror the minimum > > MTU used on the vast majority of links in the Internet today. But, > see > > more below... >=20 > You're introducing an artificial limit based on the assumption that GRE > should never transit more than the minimum, but there's no reason for > that limit; GRE is sourcing packets to the egress, and can easily > generate and reassemble fragments. The rest of the path may impose a > limit - such as based on transiting Ethernet, but there's no reason to > introduce that limit here. >=20 > >> IMO, MTU is just that - "MAXIMUM". Not 'preferred'. So if GRE *can* > >> transit packets arriving at the ingress that are 65535-IP-GRE, why > >> should it do otherwise? > > > > What I am saying is that all packets are admitted into the tunnel > > regardless of their size, but the tunnel will use fragmentation only > > for those packets that MUST make it through to the other side, i.e., > > all packets that are no larger than 1500 bytes. >=20 > Why? Why are you introducing that as an artificial constraint for GRE? >=20 > > This means that the > > tunnel egress need only configure a reassembly buffer size of 1500 > > bytes plus the tunnel overhead. Packets larger than 1500 bytes will > > still make it through the tunnel (in one piece) if the MTU within the > > tunnel can accommodate that size. But, the most the ingress will ever > > ask the egress to reassemble is 1500 (plus overhead). >=20 > IP reassembly requires tsupport for max-size IP packets, not just ones > whose sizes you like ;-) >=20 > >> (yes, it *can* be configured lower if desired, just as with any > other > >> link, but there's no reason to assume 'lower than maximum' as a > >> default) > >> > >>> Packets larger than 1500 can be admitted into the tunnel > unfragmented > >>> and allowed to sink or swim on their own. > >> > >> Whether and how much GRE fragments what it receives at an ingress > ought > >> to be determined by its understanding of its own ingress-egress MTU > >> capability. However, those fragments are not directly related to > what > >> the tunnel can transit *because* the ingress can fragment and the > >> egress > >> can reassemble. > > > > Right. The egress has to reassemble whatever the ingress fragments. > > What I am saying is that the ingress put a conservative upper bound > > on the amount it will ever ask the egress to reassemble. >=20 > If the egress supports IPv6, the upper bound is already 66635. Why are > you introducing a lower constraint when that's already required? >=20 > >> Acting like the ingress and egress can't participate in > frag/reassembly > >> of the outer packet introduces an artificial limit to GRE tunnels. > If > >> that's what you want to do - or what has already been done - that's > >> fine, but *that* is what is suboptimal. > > > > No, I fully agree that *some* fragmentation and reassembly is > > necessary. I'm just saying that the ingress should set a limit > > on the most it would ever ask the egress to reassemble. But, > > that does *not* put an artificial limit on the tunnel MTU. >=20 > But that's what you're doing; you will reject packets larger than 1500 > that transit, even though you can reassemble them (and you have to if > you implement IPv6 reassembly anyway). >=20 > I understand what you're trying to save, but an IP encapsulation egress > is still required to support IPv6 host-side capabilities, so there's no > savings. >=20 > >> > The ingress may or may not > >>> get ICMP PTBs if one of these is dropped, but the source should be > >>> using RFC4821 when it sends packets larger than 1500 bytes anyway, > >>> so loss of PTBs should not affect the hosts. > >> > >> Agreed on that point, but not the 1500-byte transit limit. > > > > Please reread the algorithm I proposed, Joe. What I am suggesting > > is an "infinite" tunnel ingress MTU - not a 1500 byte MTU. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> Joe > > From touch@isi.edu Tue Jun 25 20:11:29 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCD421E8089 for ; Tue, 25 Jun 2013 20:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dZ0cfV3GKR6 for ; Tue, 25 Jun 2013 20:11:23 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6F25D21E804E for ; Tue, 25 Jun 2013 20:11:23 -0700 (PDT) Received: from [192.168.1.94] (pool-71-105-85-4.lsanca.dsl-w.verizon.net [71.105.85.4]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r5Q3AL4N017235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Jun 2013 20:10:30 -0700 (PDT) Message-ID: <51CA5B8A.4060008@isi.edu> Date: Tue, 25 Jun 2013 20:10:02 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Templin, Fred L" References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645B3615C@dfweml509-mbx.china.huawei.com> <51A665B1.40507@isi.edu> <95067C434CE250468B77282634C96ED322BD8932@xmb-aln-x02.cisco.com> <51ACD5DF.7040800@isi.edu> <95067C434CE250468B77282634C96ED322BDF244@xmb-aln-x02.cisco.com> <51AD307D.1070007@isi.edu> <4A95BA014132FF49AE685FAB4B9F17F645B3D1CC@dfweml509-mbx.china.huawei.com>, <51C9C9FD.2080406@isi.edu> <51C9DDC2.6090904@isi.edu> <2134F8430051B64F815C691A62D983180AA7CC@XCH-BLV-504.nw.nos.boeing.com> <51CA0DB8.6090401@isi.edu> <2134F8430051B64F815C691A62D983180AAB85@XCH-BLV-504.nw.nos.boeing.com> <51CA1771.6020304@isi.edu> <2134F8430051B64F815C691A62D983180AABF9@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180AABF9@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Carlos Pignataro \(cpignata\)" , Internet Area , Ronald Bonica Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 03:11:29 -0000 Hi, Fred, On 6/25/2013 3:32 PM, Templin, Fred L wrote: > Hi Joe, > > The constraint you seem to be missing is that RFC2460 only requires > IPv6 nodes to reassemble as much as 1500 bytes. Right; sorry for not noticing that further. Had IPv4 on the brain. ... > Granted, my algorithm is asking GRE egress tunnel endpoints to > configure a reassembly buffer size of 1500 *plus* the tunnel > encapsulation overhead, which is more than RFC2460 ensures. Agreed. ... > Also think about it this way. Why should the tunnel work hard to > pass a packet that is larger than 1500 bytes and also larger than > the minimum link MTU within the tunneled path when the source could > instead adjust the size of the packets it is sending downward? That's not a good argument. I agree that all that need be satisfied is the largest reassembled IPv6 packet, but not that we should assume the source can or will adjust downward - if that were the case, you could ignore the overhead of GRE and just claim that the MTU is 1280. Joe From rbonica@juniper.net Wed Jun 26 06:00:09 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7311B11E81C5 for ; Wed, 26 Jun 2013 06:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMriV6STrHsk for ; Wed, 26 Jun 2013 06:00:02 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 42C3E11E81CA for ; Wed, 26 Jun 2013 06:00:02 -0700 (PDT) Received: from mail52-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 26 Jun 2013 13:00:00 +0000 Received: from mail52-va3 (localhost [127.0.0.1]) by mail52-va3-R.bigfish.com (Postfix) with ESMTP id DBC171C02DD for ; Wed, 26 Jun 2013 13:00:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -3 X-BigFish: VPS-3(zz9371I542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail52-va3: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=rbonica@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail52-va3 (localhost.localdomain [127.0.0.1]) by mail52-va3 (MessageSwitch) id 1372251598386114_14319; Wed, 26 Jun 2013 12:59:58 +0000 (UTC) Received: from VA3EHSMHS030.bigfish.com (unknown [10.7.14.234]) by mail52-va3.bigfish.com (Postfix) with ESMTP id 5005648004C for ; Wed, 26 Jun 2013 12:59:58 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.54) by VA3EHSMHS030.bigfish.com (10.7.99.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 26 Jun 2013 12:59:58 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 26 Jun 2013 05:59:56 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 26 Jun 2013 05:59:56 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.184) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 26 Jun 2013 06:11:49 -0700 Received: from mail47-co1-R.bigfish.com (10.243.78.225) by CO1EHSOBE026.bigfish.com (10.243.66.89) with Microsoft SMTP Server id 14.1.225.23; Wed, 26 Jun 2013 12:59:55 +0000 Received: from mail47-co1 (localhost [127.0.0.1]) by mail47-co1-R.bigfish.com (Postfix) with ESMTP id BB54E34029B for ; Wed, 26 Jun 2013 12:59:55 +0000 (UTC) Received: from mail47-co1 (localhost.localdomain [127.0.0.1]) by mail47-co1 (MessageSwitch) id 1372251593934272_21436; Wed, 26 Jun 2013 12:59:53 +0000 (UTC) Received: from CO1EHSMHS014.bigfish.com (unknown [10.243.78.249]) by mail47-co1.bigfish.com (Postfix) with ESMTP id D7FB840004B; Wed, 26 Jun 2013 12:59:53 +0000 (UTC) Received: from BY2PRD0512HT003.namprd05.prod.outlook.com (157.56.238.5) by CO1EHSMHS014.bigfish.com (10.243.66.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 26 Jun 2013 12:59:53 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.17]) by BY2PRD0512HT003.namprd05.prod.outlook.com ([10.255.243.36]) with mapi id 14.16.0324.000; Wed, 26 Jun 2013 12:59:52 +0000 From: Ronald Bonica To: Linda Dunbar , Joe Touch , "Carlos Pignataro (cpignata)" Thread-Topic: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt Thread-Index: AQHOYIIVmNm01ZQNX0mvZRw0kXAkDZkkp/+AgAAG3YCAIen7AIABf4xg Date: Wed, 26 Jun 2013 12:59:52 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2509F895CE@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645B3615C@dfweml509-mbx.china.huawei.com> <51A665B1.40507@isi.edu> <95067C434CE250468B77282634C96ED322BD8932@xmb-aln-x02.cisco.com> <51ACD5DF.7040800@isi.edu> <95067C434CE250468B77282634C96ED322BDF244@xmb-aln-x02.cisco.com> <51AD307D.1070007@isi.edu> <4A95BA014132FF49AE685FAB4B9F17F645B3D1CC@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B3D1CC@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ISI.EDU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: Internet Area Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 13:00:09 -0000 Linda, What do these platforms do when they receive an ICMP Packet too big from a = router that isn't a tunnel ingress? Ron > -----Original Message----- > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > Sent: Tuesday, June 25, 2013 10:05 AM > To: Joe Touch; Carlos Pignataro (cpignata) > Cc: Ronald Bonica; Internet Area > Subject: RE: [Int-area] New Version Notification for draft-bonica- > intarea-gre-mtu-00.txt >=20 > Ron, >=20 > Your draft recommends that the ingress node discards the frame and > sends ICMP msg to the source node when the size of GRE encapsulated > frame exceeds link MTU. > We experienced that Window XP doesn't adjust frame size after receiving > ICMP message. Many Linux based applications don't do anything either > with the MTU ICMP message. I think your draft should point those issues > out and recommend fragmentation approach under those circumstances. >=20 > Linda >=20 >=20 >=20 From bob.hinden@gmail.com Wed Jun 26 06:18:16 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB08921F9A3C for ; Wed, 26 Jun 2013 06:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgNGwYlM-t6X for ; Wed, 26 Jun 2013 06:18:15 -0700 (PDT) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 22CB921F9942 for ; Wed, 26 Jun 2013 06:18:14 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id c4so7364718eek.15 for ; Wed, 26 Jun 2013 06:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=HVQyYrbuXHGxoTUEAdReJG9G/NK12DlMEWDoDv6PX4Y=; b=v998qtES7mskUjb7mEpdrOmpkCR9Lza2MDWxBuun0muZnUSbDKMaGLw6e5i0qgeM/q 8/MP3RN3lHDvK3b9kyZQBRfDmBetPtDcXoQMmAvTvWpQTPBblJbHSeTIu0T8Zgy1ZNb+ hD8P/RsRTz7+wlsYgmoBbpYNo9QXOFl5SsOjpsBhAJJv/jfM5GQsZoOZxw4Hh1Xi1Qzy d2Yci/pgSCiP78raNXlLa8qolKwJDy47A1ZcGi6Ys9OgbWf+lGWy5+PnYJBmrZbceqF0 X06QWhuJ0JucjMstmnpi2HVYJHr5KFUG3YmBPrY/GNLm5483cKbADEqMRx7I7jmSv3rj 8qeQ== X-Received: by 10.14.115.9 with SMTP id d9mr4098328eeh.87.1372252693024; Wed, 26 Jun 2013 06:18:13 -0700 (PDT) Received: from [172.24.251.79] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id i2sm42870624eeu.4.2013.06.26.06.18.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 06:18:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Bob Hinden In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B3D1CC@dfweml509-mbx.china.huawei.com> Date: Wed, 26 Jun 2013 16:18:10 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <25D1DC90-65B8-4263-AF73-EEEE8DF73049@gmail.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645B3615C@dfweml509-mbx.china.huawei.com> <51A665B1.40507@isi.edu> <95067C434CE250468B77282634C96ED322BD8932@xmb-aln-x02.cisco.com> <51ACD5DF.7040800@isi.edu> <95067C434CE250468B77282634C96ED322BDF244@xmb-aln-x02.cisco.com> <51AD307D.1070007@isi.edu> <4A95BA014132FF49AE685FAB4B9F17F645B3D1CC@dfweml509-mbx.china.huawei.com> To: Linda Dunbar X-Mailer: Apple Mail (2.1508) Cc: Ronald Bonica , Internet Area Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 13:18:16 -0000 Linda, On Jun 25, 2013, at 5:04 PM, Linda Dunbar = wrote: > Ron,=20 >=20 > Your draft recommends that the ingress node discards the frame and = sends ICMP msg to the source node when the size of GRE encapsulated = frame exceeds link MTU.=20 > We experienced that Window XP doesn't adjust frame size after = receiving ICMP message. Given's Windows XP's minimal IPv6 implementation (even assuming it = actually installed by the user), I don't think it's a good to platform = to compare against. Windows 7 or 8 make more sense. Bob From Fred.L.Templin@boeing.com Wed Jun 26 08:42:13 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FF721F9D76 for ; Wed, 26 Jun 2013 08:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXI1PYuNhKL9 for ; Wed, 26 Jun 2013 08:42:07 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id E305121F9971 for ; Wed, 26 Jun 2013 08:42:06 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r5QFgkvp015479 for ; Wed, 26 Jun 2013 08:42:46 -0700 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r5QFgkYx015471 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 26 Jun 2013 08:42:46 -0700 Received: from XCH-BLV-404.nw.nos.boeing.com (130.247.25.157) by XCH-NWHT-05.nw.nos.boeing.com (130.247.25.109) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 26 Jun 2013 08:42:05 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-BLV-404.nw.nos.boeing.com ([169.254.4.225]) with mapi id 14.02.0328.011; Wed, 26 Jun 2013 08:42:05 -0700 From: "Templin, Fred L" To: Joe Touch Thread-Topic: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt Thread-Index: AQHOchql4CDeOS4hME2jCEFNN9O7c5lIH4tg Date: Wed, 26 Jun 2013 15:42:04 +0000 Message-ID: <2134F8430051B64F815C691A62D983180AC895@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645B3615C@dfweml509-mbx.china.huawei.com> <51A665B1.40507@isi.edu> <95067C434CE250468B77282634C96ED322BD8932@xmb-aln-x02.cisco.com> <51ACD5DF.7040800@isi.edu> <95067C434CE250468B77282634C96ED322BDF244@xmb-aln-x02.cisco.com> <51AD307D.1070007@isi.edu> <4A95BA014132FF49AE685FAB4B9F17F645B3D1CC@dfweml509-mbx.china.huawei.com>, <51C9C9FD.2080406@isi.edu> <51C9DDC2.6090904@isi.edu> <2134F8430051B64F815C691A62D983180AA7CC@XCH-BLV-504.nw.nos.boeing.com> <51CA0DB8.6090401@isi.edu> <2134F8430051B64F815C691A62D983180AAB85@XCH-BLV-504.nw.nos.boeing.com> <51CA1771.6020304@isi.edu> <2134F8430051B64F815C691A62D983180AABF9@XCH-BLV-504.nw.nos.boeing.com> <51CA5B8A.4060008@isi.edu> In-Reply-To: <51CA5B8A.4060008@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "Carlos Pignataro \(cpignata\)" , Internet Area , Ronald Bonica Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 15:42:13 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, June 25, 2013 8:10 PM > To: Templin, Fred L > Cc: Carlos Pignataro (cpignata); Ronald Bonica; Internet Area > Subject: Re: [Int-area] New Version Notification for draft-bonica- > intarea-gre-mtu-00.txt >=20 > Hi, Fred, >=20 > On 6/25/2013 3:32 PM, Templin, Fred L wrote: > > Hi Joe, > > > > The constraint you seem to be missing is that RFC2460 only requires > > IPv6 nodes to reassemble as much as 1500 bytes. >=20 > Right; sorry for not noticing that further. Had IPv4 on the brain. OK, but IPv4 also has a limit of minMRU=3D576. So, we have: IPv4 minMTU =3D 576 (*) IPv4 minMRU =3D 576 IPv6 minMTU =3D 1280 IPv6 minMRU =3D 1500 (*) Even though the specs say that IPv4 minMTU =3D 68, everyone seems to be saying that for practical purposes it is now 576. > ... > > Granted, my algorithm is asking GRE egress tunnel endpoints to > > configure a reassembly buffer size of 1500 *plus* the tunnel > > encapsulation overhead, which is more than RFC2460 ensures. >=20 > Agreed. Right. So, then the fragmentation threshold for GRE over IPv6 needs to be (1500 - HLEN) instead of 1500. =20 > ... > > Also think about it this way. Why should the tunnel work hard to > > pass a packet that is larger than 1500 bytes and also larger than > > the minimum link MTU within the tunneled path when the source could > > instead adjust the size of the packets it is sending downward? >=20 > That's not a good argument. I agree that all that need be satisfied is > the largest reassembled IPv6 packet, but not that we should assume the > source can or will adjust downward - if that were the case, you could > ignore the overhead of GRE and just claim that the MTU is 1280. In my lab, my implementation sends a single packet for packet sizes no larger than (1280 - HLEN). For packets that are larger than (1280 - HLEN) but no larger than 1500, it fragments the packet into two pieces and sends both pieces to the tunnel far end which then needs to reassemble. But, reassembly will be delayed by the inter-packet delay plus the time it takes to run the reassembly routine, and the delay is measurable. So, we really only want to use frag/reass when we absolutely have to. Thanks - Fred fred.l.templin@boeing.com =20 > Joe From Fred.L.Templin@boeing.com Wed Jun 26 09:09:15 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6B311E81C8 for ; Wed, 26 Jun 2013 09:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKXrHMgupsGG for ; Wed, 26 Jun 2013 09:09:10 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6556D11E80DF for ; Wed, 26 Jun 2013 09:09:10 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r5QG99CS028340 for ; Wed, 26 Jun 2013 11:09:09 -0500 Received: from XCH-PHX-311.sw.nos.boeing.com (xch-phx-311.sw.nos.boeing.com [130.247.25.171]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r5QG98Nt028326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 26 Jun 2013 11:09:09 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-PHX-311.sw.nos.boeing.com ([169.254.11.3]) with mapi id 14.02.0328.011; Wed, 26 Jun 2013 09:09:08 -0700 From: "Templin, Fred L" To: "Carlos Pignataro (cpignata)" , Ronald Bonica Thread-Topic: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt Thread-Index: AQHOchql4CDeOS4hME2jCEFNN9O7c5lIH4tggAAGcCA= Date: Wed, 26 Jun 2013 16:09:07 +0000 Message-ID: <2134F8430051B64F815C691A62D983180AC8F2@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645B3615C@dfweml509-mbx.china.huawei.com> <51A665B1.40507@isi.edu> <95067C434CE250468B77282634C96ED322BD8932@xmb-aln-x02.cisco.com> <51ACD5DF.7040800@isi.edu> <95067C434CE250468B77282634C96ED322BDF244@xmb-aln-x02.cisco.com> <51AD307D.1070007@isi.edu> <4A95BA014132FF49AE685FAB4B9F17F645B3D1CC@dfweml509-mbx.china.huawei.com>, <51C9C9FD.2080406@isi.edu> <51C9DDC2.6090904@isi.edu> <2134F8430051B64F815C691A62D983180AA7CC@XCH-BLV-504.nw.nos.boeing.com> <51CA0DB8.6090401@isi.edu> <2134F8430051B64F815C691A62D983180AAB85@XCH-BLV-504.nw.nos.boeing.com> <51CA1771.6020304@isi.edu> <2134F8430051B64F815C691A62D983180AABF9@XCH-BLV-504.nw.nos.boeing.com> <51CA5B8A.4060008@isi.edu> <2134F8430051B64F815C691A62D983180AC895@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180AC895@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: Internet Area Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 16:09:16 -0000 Authors, I have already worked out the details of the algorithms your draft is seeking in SEAL: http://datatracker.ietf.org/doc/draft-templin-intarea-seal/ There are exactly two differences between SEAL and GRE: - SEAL does not use IP frag/reass; it uses its own frag/reass mechanisms at a layer above IP - SEAL requires that the tunnel egress reassemble enough so that all packets that are no larger than 1500 bytes will be accommodated unconditionally. With GRE, the best the tunnel ingress can assume is that the egress has a 1500 byte reassembly buffer, which is not big enough to hold a 1500 byte packet plus the encapsulation overhead I will say again that for IPv6 the GRE tunnel MUST accommodate packet sizes up to 1280 as specified in RFC2460. And, when the path over which the tunnel is configured only has a 1280 MTU the GRE tunnel MUST use IP frag/reass to meet the IPv6 minMTU requirement. But, we are seeing in other discussions that both IPv6 frag/reass and IPv6 PMTUD may not work very well in some environments. Thanks - Fred fred.l.templin@boeing.com From linda.dunbar@huawei.com Wed Jun 26 13:09:49 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1786811E8204 for ; Wed, 26 Jun 2013 13:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJ4DNN8SDsnF for ; Wed, 26 Jun 2013 13:09:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5650711E8209 for ; Wed, 26 Jun 2013 13:09:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASW67393; Wed, 26 Jun 2013 20:09:40 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 26 Jun 2013 21:08:55 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 27 Jun 2013 04:09:38 +0800 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Wed, 26 Jun 2013 13:09:35 -0700 From: Linda Dunbar To: Ronald Bonica , Joe Touch , "Carlos Pignataro (cpignata)" Thread-Topic: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt Thread-Index: AQHOYIIHCLVTT1AFqk2vPhrKL3inOJklHViAgAAG3YCAH/zjQIADbVQAgAABItA= Date: Wed, 26 Jun 2013 20:09:35 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B4038F@dfweml509-mbx.china.huawei.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F187DD@BY2PRD0512MB653.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645B3615C@dfweml509-mbx.china.huawei.com> <51A665B1.40507@isi.edu> <95067C434CE250468B77282634C96ED322BD8932@xmb-aln-x02.cisco.com> <51ACD5DF.7040800@isi.edu> <95067C434CE250468B77282634C96ED322BDF244@xmb-aln-x02.cisco.com> <51AD307D.1070007@isi.edu> <4A95BA014132FF49AE685FAB4B9F17F645B3D1CC@dfweml509-mbx.china.huawei.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F895CE@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509F895CE@BY2PRD0512MB653.namprd05.prod.outlook.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Internet Area Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 20:09:49 -0000 Ron,=20 Those applications ignore the ICMP messages and keep sending data frames as= if there is no ICMP message received.=20 We ran into this problem in testing Video distribution system. After the fi= rst few frames, the receivers can't receive anything. After lengthy debuggi= ng, we found out that an intermediate node drops packets when GRE encapsula= ted frames exceed the link MTU. We tested that ICMP message is sent back, b= ut the source node didn't respond. We tried several setting as Joe pointed = out. Some guest OSs change behavior, some don't. =20 Linda > -----Original Message----- > From: Ronald Bonica [mailto:rbonica@juniper.net] > Sent: Wednesday, June 26, 2013 8:00 AM > To: Linda Dunbar; Joe Touch; Carlos Pignataro (cpignata) > Cc: Internet Area > Subject: RE: [Int-area] New Version Notification for draft-bonica- > intarea-gre-mtu-00.txt >=20 > Linda, >=20 > What do these platforms do when they receive an ICMP Packet too big > from a router that isn't a tunnel ingress? >=20 > Ron >=20 >=20 > > -----Original Message----- > > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > > Sent: Tuesday, June 25, 2013 10:05 AM > > To: Joe Touch; Carlos Pignataro (cpignata) > > Cc: Ronald Bonica; Internet Area > > Subject: RE: [Int-area] New Version Notification for draft-bonica- > > intarea-gre-mtu-00.txt > > > > Ron, > > > > Your draft recommends that the ingress node discards the frame and > > sends ICMP msg to the source node when the size of GRE encapsulated > > frame exceeds link MTU. > > We experienced that Window XP doesn't adjust frame size after > receiving > > ICMP message. Many Linux based applications don't do anything either > > with the MTU ICMP message. I think your draft should point those > issues > > out and recommend fragmentation approach under those circumstances. > > > > Linda > > > > > > >=20 >=20