[ipv6hackers] Fwd: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed
Fernando Gont
fgont at si6networks.com
Sun Jun 9 06:39:50 CEST 2013
FYI
Thought this might be of interest to this list. ;-)
-------- Original Message --------
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed
Date: Sat, 8 Jun 2013 19:58:57 -0400
From: Warren Kumari <warren at kumari.net>
To: Ray Hunter <v6ops at globis.net>
CC: v6ops at ietf.org <v6ops at ietf.org>
On Jun 8, 2013, at 12:28 PM, Warren Kumari <warren at kumari.net> wrote:
>
> On Jun 8, 2013, at 1:39 AM, Ray Hunter <v6ops at globis.net> wrote:
>
>>
>>
>> Warren Kumari wrote:
>>> On Jun 7, 2013, at 7:59 PM, Nalini Elkins <nalini.elkins at insidethestack.com> wrote:
>>>
>>>> On 6/7/2013 4:18 PM, Nalini Elkins wrote:
>>>>>>> Well, HBH is the *correct* place to put things that are examined per-hop ;-)
>>>>> Maybe I am missing something but I am not seeing why the header we are
>>>>> proposing has to be looked at by ANY intermediate hop. The source node
>>>>> sticks in the timestamp and packet sequence number & we are all set.
>>>>> Why would that need to be in a HBH header?
>>>>>> It wounldn't unless you need it to be examined by a router. If it's only examined by the endpoints, it could be elsewhere.
>>>>>> The point of the HBH header is to place all of the info a router should *ever* need to look at (that isn't in the main IPv6 header) in one place that's easy to find and parse.
>>>> Sure. That is why we put it in the Dest Ops header. No need for a router to ever bother with our little guy!
>>>
>>> Sure, but the Dest Ops header shows up before the L4 information, and so pushed the L4 header further out.
>> Absolutely.
>>
>>> Someone (it may have been Ron Bonica, hopefully he doesn't mind me mentioning it) suggested reordering the header chain so that it goes IP -> HBH -> L4 / Payload -:> Dest Options.
>>> This is not a stupid idea….
>>>
>>> Anyway, I decided that maybe having some data here would be useful, so I decided to see how many sites from Dan Wing's list (http://www.employees.org/~dwing/aaaa-stats/ipv6-aaaa.2013-06-07_0800.txt) I could:
>>> A: make an IPv6 connection to and
>>> B: would accept packets where the first header was not the payload.
>>>
>>> So, here are some stats. I connect (using scapy) and do an HTTP GET. If that works, I try again, with an empty Destination Options (the only thing I could figure out that would move the payload up and not influence routing / seem weird). My methodology may be broken, and the code (pasted at the bottom *certainly* is horrendous, but at least we have *some* data. And kvetching about methodology, data is (IMO) more interesting than where are currently are, which seems to not be progressing…
>>>
>>>
>>> [SNIP]
>> <snip>
>>
>> Thanks for the data.
>>
>> But your test only pushed the L4 header out by one Destination Option header (8 bytes (2 + PadN of 6))
>
> Yup. I mentioned that in my mail
>
> I am planning on retesting the sites that managed to pass *any* headers by adding more padding and seeing where various sites fall out.
> Unfortunately scapy doesn't really like my adding the padding myself (or, at least I haven't yet figured out yet how). I'll try beat it into submission more, or just give up and hand-craft the packets myself.
And, while doing this (which I think I finally got to work right) I
discovered that I had an embarrassingly stupid bug in my initial code
-- I was only checking to make sure that I got *some* response from the
site, but not what the response was. This means that I was counting
sites that returned e.g. an ICMPv6DestUnreach as though they worked.
The view of the world after fixing this (code below) is *very* different
-- one site (www.sapo.pt) works with extension headers, but only
sporadically - I'm guessing there is a LB and one node is missing
filters / there is ECMP and one path is missing filters.
This is 0.09% of tested sites. This is more like what I would have
expected -- I'm paranoid and so expect others to be as well, and to
discard / reject packets that don't start with [TCP/UDP/ICMP].
It is also possible that there is something wrong with my methodology /
scapy's packet crafting, but seeing as one site works I think the
generated packets are ok...
wkumari at vimes:~/tmp$ time sudo python ./ipv6_eh_tester.py
[SNIP]
www.zbozi.cz does not work if there is a Destination Option Extension Header
www.zerolag.com does not work if there is a Destination Option Extension
Header
### ziggi.uol.com.br returned an ICMPv6 Destination Unreachable ###
zipmail.uol.com.br does not work if there is a Destination Option
Extension Header
www.zimbra.free.fr does not work if there is a Destination Option
Extension Header
www.singtel.com does not work if there is a Destination Option Extension
Header
www.zuhause.de does not work if there is a Destination Option Extension
Header
www.zoover.nl does not work if there is a Destination Option Extension
Header
www.zwame.pt does not work if there is a Destination Option Extension Header
www.zoover.de does not work if there is a Destination Option Extension
Header
Cannot resolve www.skoob.com.br
### www.xl.co.id returned an ICMPv6 Destination Unreachable ###
www.slysoft.com does not work if there is a Destination Option Extension
Header
www.socialsecurity.gov does not work if there is a Destination Option
Extension Header
www.ssa.gov does not work if there is a Destination Option Extension Header
www.techtudo.com.br does not work if there is a Destination Option
Extension Header
www.tradebit.com does not work if there is a Destination Option
Extension Header
tutsplus.com does not work if there is a Destination Option Extension Header
www.turktelekom.com.tr does not work if there is a Destination Option
Extension Header
www.ub.ac.id does not work if there is a Destination Option Extension Header
Progress: Processed 1100 sites, 0.092081 work with extension headers
www.unesp.br does not work if there is a Destination Option Extension Header
www.newsen.com does not work if there is a Destination Option Extension
Header
Working V6 sites: 1088, Working v6 sites with EH: 1. Percent: 0.091912
------------------------------------------------------------
Working EH sites:
www.sapo.pt
real 81m3.027s
user 2m4.080s
sys 0m13.525s
Here is the scapy show() for a working www.sapo.pt:
>>> b.show()
###[ IPv6 ]###
version= 6L
tc= 0L
fl= 0L
plen= 24
nh= Destination Option Header
hlim= 118
src= 2001:8a0:2104:ff:213:13:146:140
dst= 2606:700:e:551::100
###[ IPv6 Extension Header - Destination Options Header ]###
nh= TCP
len= 0
autopad= On
\options\
|###[ PadN ]###
| otype= PadN [00: skip, 0: Don't change en-route]
| optlen= 4
| optdata= '\x00\x00\x00\x00'
###[ TCP ]###
sport= www
dport= ftp_data
seq= 2802195972
ack= 1
dataofs= 6L
reserved= 0L
flags= SA
window= 8192
chksum= None
urgptr= 0
options= {}
So, it looks like 0.09% of sites on the big-I Internet will accept
packets that look like:
>>> packet.show()
###[ IPv6 ]###
version= 6
tc= 0
fl= 0
plen= None
nh= Destination Option Header
hlim= 64
src= 2606:700:e:551::100
dst= <Net6 www.sapo.pt>
###[ IPv6 Extension Header - Destination Options Header ]###
nh= TCP
len= None
autopad= On
\options\
###[ TCP ]###
sport= ftp_data
dport= www
seq= 0
ack= 0
dataofs= None
reserved= 0
flags= S
window= 8192
chksum= None
urgptr= 0
options= {}
###[ Raw ]###
load= 'GET / HTTP/1.0\r\n\r\n'
Yes, I'm only testing web servers here, and those on the public
Internet. Feel free to perform your own testing internally, etc.
W
Ugly code:
#!/usr/bin/python
#
# $Revision:: 88 $
# $Date:: 2013-06-08 18:26:06 -0400 (Sat, 08 Jun 2013) $
# $Author:: wkumari $
# $HeadURL:: svn+ssh://svn.kumari.net/data/svn/code/python#$
# Copyright: Warren Kumari (warren at kumari.net) -- 2013
#
from scapy.all import *
class PaddedDestOpt(Packet):
name = "Padded IPv6 Destination Option Header"
fields_desc = [ ByteEnumField("nh", 59, ipv6nh),
FieldLenField("len", None, length_of="padding", fmt="B",
adjust = lambda pkt,x: (x+2+7)/8-1),
# Stuff in a PadN header
ByteField("otype", 0x01),
FieldLenField("optlen", None, length_of="padding",
fmt="B"),
StrLenField("padding", "",
length_from = lambda pkt: pkt.optlen - 2)
]
overload_fields = {IPv6: { "nh": 60 }}
def SupportsEH(name):
try:
response=sr1(IPv6(dst=name)/TCP(dport=80)/'GET / HTTP/1.0\r\n\r\n',
timeout=2, verbose=0)
except socket.gaierror:
print 'Cannot resolve %s' % name
return (False, False)
if packet:
response=sr1(IPv6(dst=name)/IPv6ExtHdrDestOpt()/TCP(dport=80)/'GET /
HTTP/1.0\r\n\r\n', timeout=4, verbose=0)
if response:
if response.haslayer(ICMPv6DestUnreach):
print '### %s returned an ICMPv6 Destination Unreachable ###' % name
return (True, False)
elif response.haslayer(ICMPv6TimeExceeded):
print '!!! %s returned an ICMPv6 TTL Exceeded !!!' % name
return (True, False)
elif response.haslayer(TCP):
print '*** %s works with extension headers! ***' % name
return (True, True)
else:
print 'We got some other sort of error from %s. Packet:' % site
response.show()
return (True, False)
else:
print '%s does not work if there is a Destination Option Extension
Header' % name
return (True, False)
else:
print '%s does NOT seem to work on IPv6' % name
return (False, False)
def ReadSiteList(filename):
sites=[]
for line in open(filename).read().splitlines():
try:
site = line.split()[0]
except IndexError:
pass
sites.append(site)
return sites
def main():
v6_sites=[]
eh_sites=[]
count = 0
# From:
http://www.employees.org/~dwing/aaaa-stats/ipv6-aaaa.2013-06-07_0800.txt
sites = ReadSiteList('ipv6-aaaa.2013-06-07_0800.txt')
#sites = ReadSiteList('ipv6_eh_sites.txt')
for site in sites:
count +=1
(v6, eh) = SupportsEH(site)
if v6:
v6_sites.append(site)
if eh:
eh_sites.append(site)
if not count % 20:
print 'Progress: Processed %d sites, %f work with extension
headers\n' % (count,
float(len(eh_sites)) / len(v6_sites) * 100.0)
print 'Working V6 sites: %d, Working v6 sites with EH: %d. Percent:
%f' % (len(v6_sites), len (eh_sites), float(len(eh_sites)) /
len(v6_sites) * 100.0)
print '\n\n'
print '-'*60
print 'Working EH sites:'
print '\n'.join([site for site in eh_sites])
if __name__ == '__main__':
main()
>
>>
>> That to me would suggest far more brokenness than simply that the L4
>> header had moved a small amount beyond the limit of the 'n' first bytes
>> of the packet (where 'n' is limited due to bandwidth limitations to the
>> ASIC), because 8 bytes is the absolute minimum a L4 header can be
>> displaced. Your test traffic would certainly not constitute an
>> abnormally long extension header chain IMHO. e.g. It might be that there
>> were problems with a broken parser not finding the L4 header at an exact
>> fixed location where it expected it, a filter that had been configured,
>> or some additional configuration to say drop all destination options.
>
> Yup, the *huge* majority of the "brokenness" was probably filters like the below - if you don't apply any filters / hashing / load-balancing the router is only looking at the IP header.
>
> term discard-ext-header-packets {
> from {
> next-header-except [ tcp udp icmpv6 ];
> }
> then {
> count discarded-packets-with-headers;
> discard;
> }
> }
> }
>
>
> But, as we say in: http://tools.ietf.org/html/draft-wkumari-long-headers-00
>
> "In one widely deployed router architecture, if there are any
> extension headers between the IPv6 header and the upper-layer header,
> the forwarding logic never sees the upper-layer header, and so is not
> able to filter on it."
>
> and
>
> "Network operators may filter traffic with extention header, because
> of the lack of fixed extention header size, the complexity of
> following header chains, and the inability of deployed routers to
> look sufficently deep into packets to see the upper-layer header."
>
> But, as a [ web / content ] operator, why would you allow in any traffic that seems suspicious?
>
> We have an updated version of this draft sitting in an edit buffer (and a corresponding recommendation draft), which we intend to submit in a few days (as soon as we figure out who has the most recent revision, why they didn't check it into svn, and who exactly was supposed to post it… :-P)
>
>
>> Speaking entirely selfishly: accelerating fragment headers, and AH+ESP
>> through firewalls that examine L4 data would be the two use-cases I'd
>> want to see most supported.
>
> So, yes, there *are* extensions that are useful -- ESP, AH / Mobility spring to mind.
>
> One of the updates to the draft suggests that devices be designed to be able to look N bytes into the packet to find the L4 info (where N is 64 / 128 / 256). This seems like a good compromise between extensibility and cost. Most *sites* on the Internet will continue to only allow traffic in that they are expecting though.
>
> As it is "hard" for machines / applications to know if they are emitting a packet that will traverse the big-I Internet they should assume that there will be a filter that will barf on EH headers and so not emit them.
>
> "For this reason, appplications and IPv6 stacks should avoid the use
> of extention headers whenever possaible, and applications should be
> designed to deal with the posibility that packets containing
> extention headers may not be delivered."
>
> What flavor of kink you get up to in the privacy of your own network is (largely) your own decision, but keep in mind that:
> 1: hardware is designed for the majority / profitable cases.
> 2: adding complexity to the protocol has a cost to all (bugs per kloc, limited developer resources, edge cases and operational considerations, endless threads on v6ops@ ).
>
>>
>> Or is the IPv6 Internet "web only"?
>>
>
> Nope. No-one said that, but sometimes it does seem that way, doesn't it? :-).
>
> W
>
>> regards,
>> RayH
>>
>
> --
> With Feudalism, it's your Count that votes.
>
>
--
It is impossible to sharpen a pencil with a blunt axe. It is equally vain
to try to do it with ten blunt axes instead.
-- E.W Dijkstra, 1930-2002
_______________________________________________
v6ops mailing list
v6ops at ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
More information about the Ipv6hackers
mailing list