Hi Ron, 3c) may happen for a VPN or non-VPN case. The payload can be in non-IPv6 space. Is “Outcome 3c) is not acceptable, but it extremely unlikely.” for particular network/usage in your mind?
Is the goal here to prove such corruption is acceptable or extreme unlikely? Regards, Lucy From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Ronald Bonica Sent: Tuesday, March 31, 2015 1:43 PM To: Black, David; int-area@ietf.org; i...@ietf.org Cc: draft-ietf-intarea-gre-i...@tools.ietf.org; intarea-cha...@ietf.org Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 Resend… From: Ronald Bonica Sent: Tuesday, March 31, 2015 2:23 PM To: 'Black, David'; int-area@ietf.org<mailto:int-area@ietf.org>; i...@ietf.org<mailto:i...@ietf.org> Cc: draft-ietf-intarea-gre-i...@tools.ietf.org<mailto:draft-ietf-intarea-gre-i...@tools.ietf.org>; intarea-cha...@ietf.org<mailto:intarea-cha...@ietf.org> Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6 David, Lucy, You are correct. Maybe the following text will address the issue: OLD> Because the IPv6 delivery header does not include a checksum of its own, it is subject to corruption. However, even if the delivery header is corrupted, to likelihood of that corruption resulting in misdelivery of the payload is extremely low. <OLD NEW> Because the IPv6 delivery header does not include a checksum of its own, the destination address in the delivery header is subject to corruption. If the destination address in the deliver header is corrupted, the following outcomes are possible: 1) The delivery packet is dropped because the new destination address is unreachable 2) The delivery packet is dropped because the new destination address is reachable, but that node is not configured to process GRE delivery packets from the ingress 3) The delivery packet is processed by a GRE egress other than that which was originally specified by the GRE ingress. Processing options are: a. The payload packet is dropped because the payload destination is unreachable from the node that processed the delivery packet b. The payload packet is delivered to its intended destination c. The payload packet is erroneously delivered to a node other than its intended destination. The intended destination and the node to which the payload is actually delivered are numbered identically, but reside in different VPNs. Outcomes 1), 2), 3a) and 3b) are acceptable. Outcome 3c) is not acceptable, but it extremely unlikely. Because IPv6 address space is so large and so sparsely populated, outcome 1) is by far the most probable. Therefore, the combined likelihood of all acceptable outcomes by far exceeds the likelihood of the one unacceptable outcome. Furthermore, even if the payload is erroneously delivered to a node other than its intended destination, that node will discard the packet if the payload is also corrupted or if there are no applications waiting to consume the packet. <NEW Ron From: Black, David [mailto:david.bl...@emc.com] Sent: Monday, March 30, 2015 7:48 PM To: Ronald Bonica; int-area@ietf.org<mailto:int-area@ietf.org>; i...@ietf.org<mailto:i...@ietf.org> Cc: draft-ietf-intarea-gre-i...@tools.ietf.org<mailto:draft-ietf-intarea-gre-i...@tools.ietf.org>; intarea-cha...@ietf.org<mailto:intarea-cha...@ietf.org>; Black, David Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6 > Also, why would you object to 3b? The packet ends up at the right node, just > via an unexpected route. That assertion is based on the assumption that the payload destination address is worldwide unique. There are lots of counterexamples that void the assumption, e.g., 10.0.0.0/8. Thanks, --David
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
