Subject: Re: [Int-area] Spencer Dawkins' Discuss on draft-ietf-intarea-gre-ipv6-13: (with DISCUSS and COMMENT)

From: Ronald Bonica <[email-masked]>
Date: Fri, 21 Aug 2015 19:07:59 +0000

Hi David,

I think that we are converging. Responses inline.........

> 
> Hi Spencer,
> 
> My 0.02 ...
> 
> > So, my questions are:
> >
> > (1) how likely is it that endpoints in different VPNs would have
> > overlapping address ranges?
> 
> IMHO, this is likely enough to be unsafe to ignore.  IPv4 private address space
> (e.g., 10.0.0.0/8) in the inner header is an "obvious suspect" here.
[RPB] 

This is a matter of perspective. If any probability greater than 0 is unsafe to ignore, than I agree with you.

In all honesty, I can't tell you the probability of a misdelivery on any given day. 

However, the probability of misdelivery on any given day is equal to:

      Pa * Pb * Pc * Pd * Pe * Pf *Pg * Ph

Where:
	-Pa is the probability of any packet corruption on that day
	-Pb is the probability that the corrupted bits will be in the IPv6 delivery header destination address
	-Pc is the probability that corruption is limited to bits that are not protected by a checksum (e.g., the GRE or TCP checksums)
	-Pd is the probability the new (corrupted) destination address has been configured on some node
	-Pe is the probability that that node runs GRE
	-Pf is the probability that that node contains context required to disambiguate non-unique addresses (e.g., it is a VPN PE)
	-Pg is the probability that the payload address has been configured on some device in the VPN into which the packet has been leaked
	-Ph is the probability that that device is listening on the protocol/port to which the packet is directed

Given that many of these numbers are very small, there product will be even smaller. We are talking about a decimal point followed by lots of zeros followed by a non-zero digit.

                                                         Ron