Re: [Int-area] introducing a new IPv4 option [was RE: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address]
On 05/10/2010 08:04 p.m., Joel Jaeggli wrote: 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. 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: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] introducing a new IPv4 option [was RE: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address]
On 10/15/10 10:33 AM, Fernando Gont wrote: On 05/10/2010 08:04 p.m., Joel Jaeggli wrote: 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. Unless you expect that it will be *replaced* in 5 years or so with 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 years of living with IPv4, so you're going to have 20 years of supporting the assumptions currently present in legacy systems. Thanks, ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] introducing a new IPv4 option [was RE: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address]
From: Joel Jaeggli joe...@bogus.com because the software and stack have already osified. The implication being that that's not true for IPv6? That will please the ILNP people to hear, I'm sure, what with ILNP being the official RRG recommendation for multi-homing support (now that MULTI6 has been turned down by the users) - since ILNP requires changes to the host stacks (in the IPv6 and TCPv6 code). So how well you do think that change will be accepted by the v6 host community? Noel ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] introducing a new IPv4 option [was RE: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address]
On 10/15/10 11:44 AM, Noel Chiappa wrote: From: Joel Jaeggli joe...@bogus.com because the software and stack have already osified. The implication being that that's not true for IPv6? However painful it may be, altering the stacks of devices not yet built is easier than that of those already in the field. That will please the ILNP people to hear, I'm sure, what with ILNP being the official RRG recommendation for multi-homing support (now that MULTI6 has been turned down by the users) - since ILNP requires changes to the host stacks (in the IPv6 and TCPv6 code). So how well you do think that change will be accepted by the v6 host community? I believe the word you're looking for is recalcitrant. Noel ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] introducing a new IPv4 option [was RE: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address]
-Original Message- From: Bob Hinden [mailto:bob.hin...@gmail.com] Sent: Wednesday, September 08, 2010 12:38 PM To: Dan Wing Cc: Bob Hinden; 'Lars Eggert'; int-area@ietf.org 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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] introducing a new IPv4 option [was RE: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address]
On 10/5/10 6:47 PM, Bob Hinden wrote: Dan, 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/ 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 Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] introducing a new IPv4 option [was RE: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address]
From: Bob Hinden bob.hin...@gmail.com At the IP and Transport level functionality, the IPv4 Internet is essentially frozen somewhere in the 1990's. It's certainly difficult to introduce change, but not impossible - one just has to be smarter, and be prepared to live with some ugliness (and non-optimality) in some aspects of one's protocol. Noel ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] introducing a new IPv4 option [was RE: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address]
From: Joel Jaeggli joe...@bogus.com Now is not the point to invest time fixing the ipv4 internet. Yes, because after all the basic IPv6 architecture is _so different_ from the IPv4 one... Noel ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] introducing a new IPv4 option [was RE: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address]
-Original Message- From: Joel Jaeggli [mailto:joe...@bogus.com] Sent: Tuesday, October 05, 2010 4:04 PM To: Bob Hinden Cc: Dan Wing; int-area@ietf.org Subject: Re: [Int-area] introducing a new IPv4 option [was RE: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address] On 10/5/10 6:47 PM, Bob Hinden wrote: Dan, 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/ 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. 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 Bob ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
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. Bob ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
[Int-area] introducing a new IPv4 option [was RE: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address]
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? -d ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] introducing a new IPv4 option [was RE: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address]
Hi, Dan, On 8/31/2010 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, Only ones that are already broken. UDP runs over IP, and IP does not guarantee that packets are not replicated. Protocols that care about loss, ordering, or duplication need to check that at the application layer or use something like TCP instead. 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? Most have moved the option into a shim layer, i.e., changing from loose source route into IP-in-IP encapsulation. For what you want to do, IP-in-IP seems like it does the right thing - only the outermost IP would be NAT'd - but it would make some other parts of the protocol more complex. JOe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
