Ron,
Tom comments:
> You are assuming that failures will nicely follow a random
> distribution, this is not always the case
+1, and likewise, IPv6 addresses are also not uniformly randomly
distributed in practice ;-). Nice try, though ...
You asked:
> > David, what is the minimum text that we can import to satisfy the
> > requirement.
I'm not sure I can dictate the text, but let me suggest where to "dig."
A motivating observation is that if the likelihood of destination
IPv6 address corruption causing misdelivery is very small, then the
likelihood of that corruption in combination with an offsetting
corruption in the source IPv6 address is something like (very small)**2,
i.e., truly miniscule. Hence, if one can pair off tunnel source and
destination IPv6 addresses so that both have to be corrupted for
misdelivery to occur, then misdelivery should be sufficiently unlikely.
(NB: a number of words in this paragraph are "hand waves" - that's
deliberate).
So, what is it safe to say (without breaking running code) on the
subjects of:
- GRE encapsulator use of separate IPv6 source addresses for
separate tunnels? (NB: "tunnels" not "destinations" to
allow for multicast).
- GRE decapsulator check of IPv6 source address?
For MPLS/UDP, the answers were versions of SHOULD and MUST in that
order (see items c and d in Section 3.1 of draft-ietf-mpls-in-udp).
OTOH, GRE "running code" is a crucial consideration here and the
comment that "GRE over IPv6 is only practical when operators can
deal with that risk" is also useful, IMHO.
Thanks,
--David
> -----Original Message-----
> From: Tom Herbert [mailto:[email protected]]
> Sent: Tuesday, March 31, 2015 6:57 PM
> To: Ronald Bonica
> Cc: Lucy yong; Black, David; [email protected]; [email protected]; draft-ietf-
> [email protected]; [email protected]
> Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6
>
> On Tue, Mar 31, 2015 at 3:04 PM, Ronald Bonica <[email protected]> wrote:
> > Lucy, David,
> >
> >
> >
> > The proposed text says that outcome 3c) is unacceptable but highly unlikely.
> > For example, assume the following:
> >
> >
> >
> > - That an IPv6 address is assigned to every milligram of matter on
> > earth, including every drop of water. (2**95 IPv6 addresses are assigned)
> >
> > - That every minute, the destination address on a delivery packet
> > is corrupted
> >
> > - The pattern of corruption is random
> >
> >
> >
> > Every time a destination address is corrupted, the odds are 1 /
> > 8,589,934,592 that the result will be an assigned address. This should
> > happen one ever 16, 331 years.
> >
> >
> >
> > Now, assume that only 1% of those of those 2**95 IPv6 addresses are
> > configured on devices that de-encapsulate GRE. In this case, outcomes 3a),
> > 3b) and 3c) will occur only once every 1,633,100 years!
> >
> >
> >
> > So, practically speaking, we don’t have much to worry about. But for the
> > purposes of the pedantry, we may need to say that GRE over IPv6 is only
> > practical when operators can deal with that risk.
> >
>
> You are assuming that failures will nicely follow a random
> distribution, this is not always the case. For instance, we have had
> issues in the past where a packet was queued to NIC on the host, but
> then addresses we're overwritten due to loss of synchronization
> between host and device as to rather packet was completed, so the
> result would be mis-delivery if there is not checksum to catch that.
>
> It is necessary prudence to assume that the risk of mis-delivery is
> non-zero and that risk is probably greater in IPv6 than IPv4. An
> operator should be aware of these risks and be able to evaluate the
> ramifications of mis-delivery. Probably, in most cases the risk is in
> fact inconsequential, but that really needs to be determined by the
> operator-- of course if the operator's network is carrying nuclear
> launch codes I would hope they worry about mis-delivery a little more
> :-)
>
> Tom
>
>
> >
> >
> > David, what is the minimum text that we can import to satisfy the
> > requirement.
> >
> >
> >
> > Ron
> >
> >
> >
> >
> >
> >
> >
> > From: Lucy yong [mailto:[email protected]]
> > Sent: Tuesday, March 31, 2015 3:21 PM
> > To: Ronald Bonica; Black, David; [email protected]; [email protected]
> >
> >
> > Cc: [email protected]; [email protected]
> > Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6
> >
> >
> >
> > 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:[email protected]] On Behalf Of Ronald Bonica
> > Sent: Tuesday, March 31, 2015 1:43 PM
> > To: Black, David; [email protected]; [email protected]
> > Cc: [email protected]; [email protected]
> > 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'; [email protected]; [email protected]
> > Cc: [email protected]; [email protected]
> > 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:[email protected]]
> > Sent: Monday, March 30, 2015 7:48 PM
> > To: Ronald Bonica; [email protected]; [email protected]
> > Cc: [email protected]; [email protected];
> > 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
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/int-area
> >
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
