Subject: Re: [Int-area] introducing a new IPv4 option [was RE: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address]

From: "Dan Wing" <[email-masked]>
Date: Tue, 5 Oct 2010 15:26:35 -0700

> -----Original Message-----
> From: Bob Hinden [mailto:[email-masked]]
> Sent: Wednesday, September 08, 2010 12:38 PM
> To: Dan Wing
> Cc: Bob Hinden; 'Lars Eggert'; [email-masked]
> Subject: Re: [Int-area] introducing a new IPv4 option [was RE: [BEHAVE]
> Revealing identity of TCP client connection when sharing IPv4 address]
> 
> 
> On Aug 31, 2010, at 11:33 AM, Dan Wing wrote:
> 
> > A paper was published in 2004 which analyzed the success of new IP
> options
> > and new TCP options,
> >
> >  "Measuring Interactions Between Transport Protocols and Middleboxes"
> >  Alberto Medina, Mark Allman, Sally Floyd
> >  http://conferences.sigcomm.org/imc/2004/papers/p336-medina.pdf
> >
> > In Section 4.3, it showed a new IP Option resulted in a 70%
> connection
> > failure, whereas
> > Section 4.4 shows a new TCP option resulted in only a 0.2% connection
> > failure.  I do
> > not expect things have improved on the Internet for IP options, and
> my
> > testing with
> > nmap to the top 500 websites also has very high failure when sending
> an TCP
> > SYN
> > with an IP option.
> >
> > Using an IP Option on today's Internet seems unworkable, unless we do
> > something
> > creative like sending two packets (one with the IP option, one
> without) and
> > react accordingly.  This will probably break UDP-based application
> protocols
> >
> > that don't expect packets to arrive twice, and of course doubles
> traffic for
> > TCP until the address sharing device learns if the server supports or
> > rejects
> > IP options - which is more state to maintain.
> >
> > Are there other ideas for how to successfully introduce a new IP
> option to
> > the IPv4 Internet?
> 
> No.  It's very likely only gotten work since the 2004 paper.

Off list, someone else suggested it had gotten better.  So I tested 
the top sites from Alexa's list using NMAP, and results were:

  TCP 3-way handshake without IP option:  99% success
  TCP 3-way handshake with IP option:      9% success

NMAP commands, input, and output are at:
  http://www.employees.org/~dwing/ipoptions/

-d

---

From: Bob Hinden <[email-masked]>
Date: Tue, 5 Oct 2010 15:47:54 -0700

Dan,

>  http://www.employees.org/~dwing/ipoptions/

It is much worse.  At the IP and Transport level functionality, the IPv4 Internet is essentially frozen somewhere in the 1990's.  Sad...  

Bob

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 05 Oct 2010 19:04:28 -0400

On 10/5/10 6:47 PM, Bob Hinden wrote:
>> TCP 3-way handshake without IP option:  99% success TCP 3-way
>> handshake with IP option:      9% success
>> 
> It is much worse.  At the IP and Transport level functionality, the
> IPv4 Internet is essentially frozen somewhere in the 1990's.  Sad...

Now is not the point to invest time fixing the ipv4 internet.

>  Bob
> 
> 
> _______________________________________________ Int-area mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 5 Oct 2010 18:52:01 -0700

> From: Joel Jaeggli [mailto:[email-masked]]
> Sent: Tuesday, October 05, 2010 4:04 PM
> To: Bob Hinden
> Cc: Dan Wing; [email-masked]

What is the survival rate of IPv6 Extension Headers on the Internet?  
Has anyone done a survey?

Based on Jari's experience with NAT64 and fragmentation, it seems 
there is some blockage of IPv6 Extension Headers already.

-d

---

From: Fernando Gont <[email-masked]>
Date: Fri, 15 Oct 2010 14:33:26 -0300

> Now is not the point to invest time fixing the ipv4 internet.

Unless you expect that it will be *replaced* in 5 years or so with
something else, I'd argue "Why not?". There are estimates of 15-20 more
years of living with IPv4, so....

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 15 Oct 2010 10:43:22 -0700

On 10/15/10 10:33 AM, Fernando Gont wrote:
> something else, I'd argue "Why not?". 

because the software and stack have already osified. existing systems
are not going to pick up changes that you implement particularly in the
waist of the hourglass. That's just reality.

> There are estimates of 15-20 more

you're going to have 20 years of supporting the assumptions currently
present in legacy systems.