tun6bed4-devel Mailing List for 6bed4 (Page 2)
zeroconfig IPv6 tunnel
Status: Beta
Brought to you by:
vanrein
You can subscribe to this list here.
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(19) |
Dec
(5) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2012 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
(3) |
Jun
(12) |
Jul
(12) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(9) |
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: <ebi...@xm...> - 2012-06-21 12:05:34
|
The implemtation I am following up on has two deficiencies. - Only one target link layer address advertised. - No ability to find the route the peer is using. The first is a Doh. Icmpv6 supports specifying the same option multiple times. The second is also a Doh. We just need neighbor advetisements sent by consulting the neighbor cache. The standard behavior if someone has not specified a link layer address. Silly me for not implementing that. .................. With those changes the will work for any NAT scenario I can think of. And the algorithm is about as minimalistic as it gets, and reasonably proof against spoof packets doing something bad. Anyway here is a snapshot of my latest code. |
From: <ebi...@xm...> - 2012-06-20 01:40:55
|
The general problem. Stateful firewalls incoporated into many NAT devices only allow traffic to flow based on the 4 tuple <srcip,srcport,destip,destport>. In the case of 6bed4 I was trivially able to piece this by modifying the router to not filter all neighbor discovery traffic. Then on a peer. - Guess an address I can reach my neighbor at based on the embedded ipv4 address and port in my neighbors 6bed4 ipv6 address. - Send a packet to my neighbors potential address to poke a hole in my firewall. - Send a neighbor discovery packet through the router with the source source link layer address set to where I think I can be reached. - My neighbor replies to that address and neighbor discovery succeeds. ........ Alternatively if my neighbor is behind the same NAT device as I am that can be easily pierced as well. - Send a neighbour discovery request through the router without setting the source link layer address so the reply will also come through the router, to get my neighbors target link layer address option. - Wait for the neighbor advertisement from my neighbor. - Armed with a potential link layer ipv4 address and port where I can reach my neighbor perform neighbor discovery. Either directly or through the router. It is crazy simple adn for my simple test cases it works like a charm. With one round trip time for the case where I guess my neighbors address and two round trip times where I have to ask my neighbor their address. .................. I have attached the code and the setup for my test cases (based on network namespaces below). I have not cleaned up the code enough or added enough error handling that I would be happy releasing the code in general but it lets you see what I implemented. ..................... I took a skim through RFC 5245 "Interactive Connectivty Establishemnt (ICE)" and RFC 5389 "Session Traversal Utilities for NAT (STUN)" which seem document the best current practices for establishing connections directly through NATs. - RFC 5389 STUN essentially boils down to a request/reply protcol that reports your ip address. Your reflexive transport address. I have reflexing transport address discovery from neighbor discovery by replying to packets with an unspecified source address to the ipv6 link local address that corresponds to their v4 source address. - RFC 5245 ICE essentially talks about a procedure for exchanging lists of potential address that work for talking to each other and then trying them. With neighbor discovery without defining a new option I can only receive one address to try. But one address to try beyond your publicly visible addres in your ipv6 address is sufficient for most cases. So I don't see any major downsides. Furthermore I have yet to consider what contribution icmp6 redirects may make. And if all else fails .................................... Which is all a long way of saying. It looks like I have solved in a very simple manner the common firewall traversal problems in the context of 6bed4 with Neighbor discovery. And I don't anticipate 6bed4 having any problems keeping up in the NAT traversal areana. Eric |
From: <ebi...@xm...> - 2012-06-18 00:12:31
|
Don't hairpin traffic to the routers interfaceid. Signed-off-by: Eric W. Biederman <ebi...@xm...> --- router.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/router.c b/router.c index c12ee88..e7ab764 100644 --- a/router.c +++ b/router.c @@ -340,6 +340,10 @@ static inline bool prefix_6bed4 (struct in6_addr *ip6) { return memcmp (&v6listen, ip6->s6_addr, 8) == 0; } +static inline bool router_interfaceid(struct in6_addr *ip6) { + return ip6->s6_addr[10] == 0 && ip6->s6_addr[13] == 0 && + ip6->s6_addr[14] == 0 && ip6->s6_addr[15] == 0; +}; /* * Validate the originator's IPv6 address. It should match the @@ -568,7 +572,7 @@ void handle_4to6 (void) { if (v4v6hoplimit-- <= 1) { return; } - if (prefix_6bed4 (v4dst6)) { + if (prefix_6bed4 (v4dst6) && !router_interfaceid(v4dst6)) { relay_6bed4_plain_unicast (v4data, buflen, v4dst6); } else { handle_4to6_plain_unicast (buflen); -- 1.7.5.4 |
From: <ebi...@xm...> - 2012-06-18 00:10:15
|
I have been playing with this and I really don't like the current solution in 6bed4. As it currently stands the solution is enormously complex in it's implementation and it does not actually work to pierce any connection tracking firewall (like iptables) that tracks the entire <srcip,srcport,destip,destport> tuple. I believe it is possible to come up with a comparitively simple design that allows for making anypath that can work work. To get through firewalls that track the entire source and destination address we must attempt simultaneous connections from both sides. This is easy to arrange if we send an icmp packet through the router from one machine to another to get it started. I think we can/should use modified neigbour solict and neighbour advertisements for this packet started. The idea is we start off with a 4 way handshake to exchange possible ip:port addresses and to estabilish the existence of bidirectional routing connectivity (to foil most ipv4 source address spoofing). Then both machines simultaneously perform traditional neighbour discovery at each other to see which possible ipv4:port destinations will work. So in 2 round trip times or possibly 1.5 round trip times I believe we can estabilish bidirectional connectivity that bypasses the router if that bidirection connectivity is possible. There are a lot of dyanmic details in practice that make this process tricky. I have spent way too much time understanding the current code and playing with it to get it to the point where I can play with testing my idea. Unfortunately I am out of time for the next week or two, so I don't know if a solution that works in theory will work in practice. Since we are simply using just the unicast messages on the ports we care about it should be very effective and comparitively simple. Eric |
From: <ebi...@xm...> - 2012-06-17 23:52:38
|
Rick van Rein <ri...@op...> writes: > Hello Eric, > >> I would really appreciate being able to tell a 6bed4 address when I see >> one. Let me recommend using the format: >> >> ::64bd:PP:II:II > > This would still be guessing, of course, but it would be a useful hint. > > Instead of doing this, I am talking to RIPE about a /48 prefix that > can be used in an anycast setup. Anycast itself is not free from > questions, but we want to try it, and the entire 6bed4 design is > suitable for doing this. I am concerned that the problems of the non-debugability of asymetric paths through unicast addresses will repeat. But I don't see any reason why we should not try to get this to work. My request will be that we specify the protocol in such a way that the same client can be used with anycast addresses and without. With just a change in the initial address to contact. >> Using a well known value 64bd makes these 6bed4 addresess easy to spot >> from a mile away, and it makes it clear these are not MAC48 identifiers >> mapped into EUI64 identifiers. > > I'd like to show it to the Internet at large, not just within a mile ;-) > and the mapping that you propose overlaps with the EUI64 scheme. I like > to be able to exploit existing IPv6 stacks (for Ethernet) to simplify > the scheme, which is another way of simplifying the handling. Yes. The mapping I have choosen does not work when port:ipv4 is used as a MAC48. The value I have choosen does work as a modified EUI-64 as specified in RFC4291 IPv6 Addressing Architecture. >> The leading value of 64bd also has the nice property that it leaves the >> interface identifer in modified EUI-64 format and has the u and g bits >> clear indicating it is not assigned by IEEE aka universally unique and >> not a multicast group address. > > Nice one! > > You are almost proposing to revert the addressing scheme back to the way > it was in v00 of the draft. Interesting. The reasons for the changes > to the v01 format (EUI64-lookalikes) are here: > > http://sourceforge.net/mailarchive/forum.php?thread_name=20120302075921.GB23120%40newphantom.local&forum_name=tun6bed4-devel I think you would be better using an index into a path cache as your mac address. That gives you the same reuse of the kernels neighbour cache for dead path detection, but at the same time allows for a much more flexible implementation. I have been playing with the code in an attempt to get to the point where I can play with implementation ideas for a better neighbour discovery in 6bed4. It took some playing with the code before I understood why choose the identifier you choose. The exact mapping is problem the least of the problems and the big challenge is getting a working and simple neighbour discovery that can bypass the router. Eric |
From: <ebi...@xm...> - 2012-06-17 23:46:04
|
This function is reponsible for passing both v6 datagrams we receive on the tun socket and v6 data grams we receive via udp and need to hairpin out the v4 socket udp socket. Therefore we can not hardcode the source buffer so pass in the source buffer instead. Signed-off-by: "Eric W. Biederman" <ebi...@xm...> --- router.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/router.c b/router.c index 7aa8f3c..0410495 100644 --- a/router.c +++ b/router.c @@ -503,7 +503,7 @@ printf ("Writing IPv6, result = %d\n", * Hop Limit has been altered, and this is not part of the * checksum calculations. */ -void relay_6bed4_plain_unicast (ssize_t v4datalen, struct in6_addr *ip6) { +void relay_6bed4_plain_unicast (void *data, ssize_t datalen, struct in6_addr *ip6) { v4name.sin_port = htons (ip6->s6_addr [9] << 8 | ip6->s6_addr [8] ^ 0x02); uint8_t *addr = (uint8_t *) &v4name.sin_addr.s_addr; addr [0] = ip6->s6_addr [10]; @@ -515,7 +515,7 @@ printf ("Relaying over 6bed4 Network to %d.%d.%d.%d:%d, result = %d\n", ((uint8_t *) &v4name.sin_addr.s_addr) [3], ntohs (v4name.sin_port), sendto (v4sox, - v4data, v4datalen, + data, datalen, MSG_DONTWAIT, (struct sockaddr *) &v4name, sizeof (v4name))); } @@ -566,7 +566,7 @@ void handle_4to6 (void) { return; } if (prefix_6bed4 (v4dst6)) { - relay_6bed4_plain_unicast (buflen, v4dst6); + relay_6bed4_plain_unicast (v4data, buflen, v4dst6); } else { handle_4to6_plain_unicast (buflen); } @@ -622,7 +622,7 @@ printf ("Received plain unicast IPv6 data, flags=0x%04x, proto=0x%04x\n", v6tunc } // // Harvest socket address data from destination IPv6, then send - relay_6bed4_plain_unicast (rawlen - sizeof (struct tun_pi), v6dst6); + relay_6bed4_plain_unicast (v6data, rawlen - sizeof (struct tun_pi), v6dst6); } -- 1.7.5.4 |
From: Rick v. R. <ri...@op...> - 2012-06-16 09:12:15
|
Hello Eric, > I would really appreciate being able to tell a 6bed4 address when I see > one. Let me recommend using the format: > > ::64bd:PP:II:II This would still be guessing, of course, but it would be a useful hint. Instead of doing this, I am talking to RIPE about a /48 prefix that can be used in an anycast setup. Anycast itself is not free from questions, but we want to try it, and the entire 6bed4 design is suitable for doing this. > Using a well known value 64bd makes these 6bed4 addresess easy to spot > from a mile away, and it makes it clear these are not MAC48 identifiers > mapped into EUI64 identifiers. I'd like to show it to the Internet at large, not just within a mile ;-) and the mapping that you propose overlaps with the EUI64 scheme. I like to be able to exploit existing IPv6 stacks (for Ethernet) to simplify the scheme, which is another way of simplifying the handling. > The leading value of 64bd also has the nice property that it leaves the > interface identifer in modified EUI-64 format and has the u and g bits > clear indicating it is not assigned by IEEE aka universally unique and > not a multicast group address. Nice one! You are almost proposing to revert the addressing scheme back to the way it was in v00 of the draft. Interesting. The reasons for the changes to the v01 format (EUI64-lookalikes) are here: http://sourceforge.net/mailarchive/forum.php?thread_name=20120302075921.GB23120%40newphantom.local&forum_name=tun6bed4-devel Thanks again, more to follow, -Rick |
From: <ebi...@xm...> - 2012-06-15 21:20:11
|
I would really appreciate being able to tell a 6bed4 address when I see one. Let me recommend using the format: ::64bd:PP:II:II Having the port and the ipv4 address being contiguous should make it easier for software to process. Putting the ipv4 address in the bottom most bits allows address to be written like ::64bd:8080:12.34.56.78 to instead of their more typical ipv6 form of ::64bd:8080:0c22:384e Using a well known value 64bd makes these 6bed4 addresess easy to spot from a mile away, and it makes it clear these are not MAC48 identifiers mapped into EUI64 identifiers. The leading value of 64bd also has the nice property that it leaves the interface identifer in modified EUI-64 format and has the u and g bits clear indicating it is not assigned by IEEE aka universally unique and not a multicast group address. Also having the magic number in the highest bits of the address makes these addresses a clear subset of the addresses on a normal lan so you could if you choose overlap 6bed4 addresses and addresses from other sources in the same /64. Eric |
From: <ebi...@xm...> - 2012-06-15 20:44:45
|
Rick van Rein <ri...@op...> writes: > Hello Eric, > > Thank you _very_ much for your detailed thoughts. Although I am very > busy at the moment, I should find time to work through them in detail > next week. I just want to let you know that it's too much for an > instant reply. My quick impression is that you're making valuable > suggestions. Thank you. > One of the things taking some time at the moment is a project to port > the existing 6bed4 software to Android. That sounds handy. > Did you also try the software? I have read it I have not run it yet. This started out as just general research into what is possible and it turned into. Hmm. This sounds very close to something that is very simple and bullet proof. Eric |
From: Rick v. R. <ri...@op...> - 2012-06-15 19:54:09
|
Hello Eric, Thank you _very_ much for your detailed thoughts. Although I am very busy at the moment, I should find time to work through them in detail next week. I just want to let you know that it's too much for an instant reply. My quick impression is that you're making valuable suggestions. One of the things taking some time at the moment is a project to port the existing 6bed4 software to Android. Did you also try the software? Thanks for your feedback! -Rick |
From: <ebi...@xm...> - 2012-06-15 17:27:10
|
A few more suggestions. Sending Router solcitis: The 6bed4 router being stateless will never send unsolicited router advertisements. Therefore the 6bed4 client must have timers setup so that it requests the router to send new solicitations. Those timers are not standard ipv6 behavior so the spec needs to be extended. I would recommend the timers for router solicits be set based on 1/3 of the minimum of the prefix lifetimes so that there is a reasonable chance a router solicit will be issued before things timeout. I can see the practicality in infinite address timeouts, but since the addresses may not be used for ever that seems unfortunately naive. I expect wording similar to section "8.3.4 Sending Router Solicitations" in RFC5214 "Intra-Site Automatic Tunnell Addressing Protocol" should be adopted to deal with sending periodic router solicits. Router redirects: If it is desired to trust have a model where redirects may be trusted in 6bed4 I recommend adopting the scheme in section 3.2.2 "Host Triggered Redirection" of RFC2941 "IPv6 over Non-Broadcast Multiple Access (NBMA) Netowrks" where a will allow a client when it receives a redirect from the router to send a neighbour solicit to the router with a nonce so that the router can use in it's reply and allowing reasonable confidence that when we receive a redirect back with our nonce that it has not been forged. Eric |
From: <ebi...@xm...> - 2012-06-15 07:35:22
|
I have just taken a hard look at bed64 and I have a couple of thoughts and suggestions. - There should be a recommendation of what Reachable Time should be set to in router advertisements and on bed64 links to allow the neighbour reachability logic to both keep ports open and to detect when the udp port has timed out. Hmm you do mention tha the default neighbour cache times are sufficient in the current draft. A little more detail and a description of how the values work to keep NAT ports open might be useful. - bed64 creates has NBMA non-broadcast multi-access links. As such RFC2491 should be looked at and referred to.- - Using ipv4 address and udp port as the link layer address looks like a good solution. - Avoiding problems with spoofed ipv4 packets. Most commonly spoofed ipv4 packets result from a lack of source address validation at some point in the network. As such verifying that there is two way connectivity will frequently fix this issue. Fpr neighbour solicitations and router solicitations I recommend requiring the nonce option from RFC3971 Secure Neighbor Discovery. With a decent random number generator that should make replies impossible to spoof. For router solicitations this closes a pretty significant hole. For neighbour solictitations this prevents DOS attacks where you think a neighbour is reachable and they are not. - Stateless operation of 6bed4 routers: Ultimately this appears to be a critical property for 6bed4. Without state the routers can be simpler and can scale to larger numbers of packets processed per second. - Interface identifiers: I suggest you simply drop the concept of illegal port values Only going through an interface that strongly assumes ethernet will they even that even be a problem. And making some port numbers illegal looks like a good way to break in surprising ways on weird NAT implementations. - Well known vs providered assigned addresses: Automatic tunnel like 6to4 and Teredo without a well defined place of where do you look to find the problems and who do you blame have been undebuggable. 6rd on the other hand works well enough it is being rolled out by several vendors in production deployment, because they can isolate all of the bits within their own networks. Therefore I suggest 6bed4 learn from history and be designed to be used only with the gateway providers ivp6 addresses and to be primarily used with unicast ipv4 addresses going to those gateways. - Bootstrapping. I suggest a slightly modified form of the existing bootstrap mechanism. The router reply can not change the link level source ip address, or port as then the reply would not come back through the router. However routers are expected to reply with their unique link local ipv6 address. If we then perform neighbour discovery on that link local addres and take our interface identifer from neighbour discovery to that address we gain two things. . Avoidance of all vageries of global anycast routing. . Moving our link layer address determination into a the part of the process that is most likely to notice when our link local address changes - On link determination: 6bed4 should honor the on-link prefix bit in the prefix option in the router advertisement. That way a gateway with plenty of bandwidth can direct 6bed4 clients to always route through it. I expect that in many deployments most of the traffic wil be destined for real ipv6 addresses so that skipping the 6bed4 router will be a false optimization. I have been scratching my head trying to figure out the best way to handle establishing on-link connectivity. 6bed4 is slightly peculiar in the case of NBMA networks because the network is so big and the probability that a point to point connection setup is so high that we have to cope with what happens when the connections don't form on a regular basis. To make NAT traversal work most of the time through NAT requires a process where both nodes coordinate so that they are both poking holes in the NAT firewalls simultaneously, so in the try hard scenario they have poked simultaneous holes. If we can map ICE into the core ipv6 primitives I think it might be worth trying hard. Otherwise trying harder than neighbour discovery to the public ipv4 address and port of our neighbour feels silly. My gut feel is that the 6bed4 effort should be split into two parts. 6bed4-simple that does not worry about the challenges of talking to anything except the router, and 6bed4-bypass that figures out how to build on 6bed4-simple to reduce the latency of common conections. Or to put it another way your bypass route that invokes ipv4 multicast and has all kinds of magic conditions I find very scary. At the same time if there can be made an abstraction layer that does as well STUNbis + ICE for sip and xmpp so I could have the advantages of ipv6 sooner rather than later I figure I love that notion. Not that I actually believe it for a second, but a guy can dream. - Ports: It is probably obvious but clients should randomize as much as possible their listening ports. This creates the greatest chance of clients preserving their port number when traversing the NAT. As NATs like iptables preserve the source port when there is no conflict. Eric |
From: Joost L. <vla...@gm...> - 2012-05-02 13:56:34
|
Hi Rick, Great! Managed to compile and run! Unfortunately I didn't get it to work yet. I've attached a pcap of the session. The first three out of five packets are relevant: the last two are ARP packets. The first packet seems like it's a correct RS sent out to the 6bed4 router. The second packet seems like it's a correct RA received from the 6bed4 router. The third packet seems garbled, Wireshark can't make anything of it. Joost |
From: Rick v. R. <ri...@op...> - 2012-05-02 12:52:01
|
Hello Joost, > I tried downloading and compiling the code but failed. I put in some really overzealous things to please IANA, but I should remove that I suppose. > After downloading and running cmake . I got this message: > CMake Error at CMakeLists.txt:9 (ADD_EXECUTABLE): > Cannot find source file: > client.c Ah. CMake is an "external contribution" that I didn't check. Clearly I should. I always use plain configure/make. > So I symlinked client.c to peer.c and now i'm stuck at the following output: > In file included from /home/joost/dev/6bed4/client.c:50:0: > /home/joost/dev/6bed4/nonstd.h:10:2: error: #error "Build uses experimental Neighbor Discovery Option Type 253 for Destination Link-Layer Address" > /home/joost/dev/6bed4/nonstd.h:15:2: error: #error "Build uses experimental UDP port number 27629 or 0x6bed" This is handled with the command on the webpage (formally, I'm not allowed to include non-official port numbers that build automatically) so you would do sed -i -e 's/^#error/#warning/' nonstd.h > Do you have any hints (using a fresh ubuntu 12.04 install) I'm doing my build work on Debian, so you should be really close. Perhaps try plain configure/make if the above doesn't help. This is _very_ young software, okay? I've seen it do great things with peer2peer connectivity, but only in very limited tests. Any feedback on the software (including this) is warmly welcomed. Thanks for trying, -Rick |
From: Joost L. <vla...@gm...> - 2012-05-02 12:26:03
|
Hi Rick, I tried downloading and compiling the code but failed. After downloading and running cmake . I got this message: CMake Error at CMakeLists.txt:9 (ADD_EXECUTABLE): Cannot find source file: client.c So I symlinked client.c to peer.c and now i'm stuck at the following output: In file included from /home/joost/dev/6bed4/client.c:50:0: /home/joost/dev/6bed4/nonstd.h:10:2: error: #error "Build uses experimental Neighbor Discovery Option Type 253 for Destination Link-Layer Address" /home/joost/dev/6bed4/nonstd.h:15:2: error: #error "Build uses experimental UDP port number 27629 or 0x6bed" /home/joost/dev/6bed4/nonstd.h:20:2: warning: #warning "Build uses temporary IPv4 address information" [-Wcpp] /home/joost/dev/6bed4/client.c: In function ‘lookup_neighbor’: /home/joost/dev/6bed4/client.c:720:1: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘ssize_t’ [-Wformat] /home/joost/dev/6bed4/client.c:720:1: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘ssize_t’ [-Wformat] /home/joost/dev/6bed4/client.c: In function ‘handle_4to6_plain’: /home/joost/dev/6bed4/client.c:797:1: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘ssize_t’ [-Wformat] /home/joost/dev/6bed4/client.c: In function ‘handle_4to6_nd’: /home/joost/dev/6bed4/client.c:943:1: warning: format ‘%s’ expects a matching ‘char *’ argument [-Wformat] /home/joost/dev/6bed4/client.c: In function ‘handle_6to4_plain_unicast’: /home/joost/dev/6bed4/client.c:1133:2: warning: format ‘%d’ expects argument of type ‘int’, but argument 9 has type ‘ssize_t’ [-Wformat] /home/joost/dev/6bed4/client.c: In function ‘handle_6to4_nd’: /home/joost/dev/6bed4/client.c:1179:3: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘ssize_t’ [-Wformat] /home/joost/dev/6bed4/client.c: In function ‘regular_maintenance’: /home/joost/dev/6bed4/client.c:1436:3: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘time_t’ [-Wformat] /home/joost/dev/6bed4/client.c: In function ‘run_daemon’: /home/joost/dev/6bed4/client.c:1478:4: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘__time_t’ [-Wformat] /home/joost/dev/6bed4/client.c:1478:4: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘__suseconds_t’ [-Wformat] /home/joost/dev/6bed4/client.c:1478:4: warning: format ‘%d’ expects argument of type ‘int’, but argument 5 has type ‘__time_t’ [-Wformat] /home/joost/dev/6bed4/client.c:1478:4: warning: format ‘%d’ expects argument of type ‘int’, but argument 6 has type ‘__suseconds_t’ [-Wformat] /home/joost/dev/6bed4/client.c: In function ‘process_args’: /home/joost/dev/6bed4/client.c:1575:5: warning: format ‘%s’ expects a matching ‘char *’ argument [-Wformat] /home/joost/dev/6bed4/client.c:1595:5: warning: format ‘%s’ expects a matching ‘char *’ argument [-Wformat] /home/joost/dev/6bed4/client.c:1625:5: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘long unsigned int’ [-Wformat] /home/joost/dev/6bed4/client.c: In function ‘main’: /home/joost/dev/6bed4/client.c:1771:3: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘char *’ [-Wformat] /home/joost/dev/6bed4/client.c:1817:2: warning: #warning "Target system lacks support for controlling packet fragmentation" [-Wcpp] /home/joost/dev/6bed4/client.c:1872:3: warning: format ‘%s’ expects a matching ‘char *’ argument [-Wformat] make[2]: *** [CMakeFiles/6bed4client.dir/client.c.o] Error 1 make[1]: *** [CMakeFiles/6bed4client.dir/all] Error 2 make: *** [all] Error 2 Do you have any hints (using a fresh ubuntu 12.04 install) Joost On Mar 20, 2012, at 10:20 AM, Rick van Rein wrote: > Hello, > > I have released alpha-level code of the reference implementation > for v01 of the 6bed4 draft. Here are two public locations: > > https://sourceforge.net/p/tun6bed4/c-code/ci/04b2afa7ad27a97dc4add40c8ac85acceb444c9f/tree/ > > https://github.com/vanrein/6bed4 > > > The main facility added is the use of peer-to-peer communication, > including NAT traversal. This has been tested to work between > 6bed4 peer sites, at least for ping6 :-) > > There's more testing to be done -- linkage to the rest of the > IPv6 network, and supposedly some people prefer application-level > protocols like HTTP over ICMPv6. > > The conforming spec is now also available on SourceForge, but its > primary location is of course at IETF, > > http://tools.ietf.org/html/draft-vanrein-v6ops-6bed4-01 > > > Test reports are welcome. Especially with tcpdumps attached :) > > Keep in mind though -- unlike with v00 the peer can now switch > between remote communication endpoints, so you'll want to select > traffic to view based on the _local_ port number. That number is > picked at random by default, but it can be set manually with the > -p option. Gladly done :) Still, to fully reset NAT you'll want > to avoid using that. > > > Cheers, > -Rick > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > tun6bed4-devel mailing list > tun...@li... > https://lists.sourceforge.net/lists/listinfo/tun6bed4-devel |
From: Rick v. R. <ri...@op...> - 2012-03-20 09:15:32
|
Hello, I have released alpha-level code of the reference implementation for v01 of the 6bed4 draft. Here are two public locations: https://sourceforge.net/p/tun6bed4/c-code/ci/04b2afa7ad27a97dc4add40c8ac85acceb444c9f/tree/ https://github.com/vanrein/6bed4 The main facility added is the use of peer-to-peer communication, including NAT traversal. This has been tested to work between 6bed4 peer sites, at least for ping6 :-) There's more testing to be done -- linkage to the rest of the IPv6 network, and supposedly some people prefer application-level protocols like HTTP over ICMPv6. The conforming spec is now also available on SourceForge, but its primary location is of course at IETF, http://tools.ietf.org/html/draft-vanrein-v6ops-6bed4-01 Test reports are welcome. Especially with tcpdumps attached :) Keep in mind though -- unlike with v00 the peer can now switch between remote communication endpoints, so you'll want to select traffic to view based on the _local_ port number. That number is picked at random by default, but it can be set manually with the -p option. Gladly done :) Still, to fully reset NAT you'll want to avoid using that. Cheers, -Rick |
From: Rick v. R. <ri...@op...> - 2012-03-11 21:36:28
|
Hello, I'm proud to announce a new version of the draft for 6bed4. Finally, after months of pondering :) It is my intention to present it in Paris at the end of this month, and hopefully put it up for voting for acceptance. The list on which this will be discussed, is v6ops, to be found here: http://www.ietf.org/mail-archive/web/v6ops/current/maillist.html You are quite welcome to join the discussion, of course. I may need a few who are on my side :) for introducing yet another tunnel. I'm not the first one who claims to solve all possible problems ;-) and feedback on v00 has been very good to process. Well, I hope you all enjoy what I've brewn. I'm working on the C code to demonstrate these facilities; seen enough of it work (and had enough of it influence the spec) to be fairly certain that the spec is bullet-proof, but the tool is not at the level at which the implementation for v00 was. Once the software is stable, I won't mind it going into distributions, like I did with v00 -- as it'll be very capable of offloading the tunnel server through direct peer-to-peer connections. Thanks for all your continued support, Best wishes, -Rick |
From: Rick v. R. <ri...@op...> - 2012-03-02 07:55:37
|
Hello, I haven't been very active on this list, as the complexity and fluidity of the tunnel design process is very hard to capture in linear text and accurate phrasing. But things are now falling together rapidly, so it is time for an update. Soon to come: new C code. Quick to follow: a new draft. If you see anything missing below, then it should follow in the draft. You are of course welcome to provide new angles that I may be overlooking. For discussion, telephony is preferred. Major changes: 1. To offload the public 6bed4 server, support 6bed4 between peers 2. To simplify the tunnel, use more IPv6 stack facilities The public 6bed4 server would route all 6bed4 traffic if the current (first) draft were implemented, and that presents a scaling problem. Direct connections between peers are often possible, using the IPv4 address and UDP port revealed in the 6bed4-constructed IPv6 address. The public 6bed4 server then acts as a fallback for situations where the infrastructure fails on direct connections. Let's introduce the notion "6bed4 address" to represent a UDP port and IPv4 address that serve as a communication address for the 6bed4 tunnel client. The public 6bed4 server is simply one of the possible 6bed4 addresses, but direct routes can now also have addresses. Any peer would be visible at one or more 6bed4 addresses. To find if a 6bed4 address is suitable for direct communication, a Neighbor Solicitation is sent to it; when a Neighbor Advertisement is replied, then it is safe to assume that IPv6 in general works over that channel. All this is wrapped up in UDP and IPv4, just as it is done for communication with the public 6bed4 server. Since a 6bed4 address reveals to the tunnel how to route an IPv6 packet, it behaves like what is called a link-local address in IPv6 stacks. Such addresses are normally MAC addresses, but the general idea of IPv6 does not speak in such concrete terms until you tie it to a network interface type such as Ethernet. Still, many IPv6 stacks probably have a hard-coded assumption that link-local addresses are 6 bytes long; so I was happy to note that this is also the length of a 6bed4 address. A lucky coincidence. To cator the common case of Ethernet, it is probably best if a 6bed4 address never starts with 0x3333 (IPv6 multicast prefix) so let's construct a 6bed4 address with the UDP port up front, and explicitly ban that one port. (It might upset remote parties, so this is not a choice that can be made locally.) Now, let's turn to the 6bed4 interface. It may be setup with its 6bed4 address as a "hardware address" or, in case of simulating an Ethernet (tap) interface, its "MAC address". Once setup with an IPv6 address it would respond to Neighbor Discovery by specifying its link-local address, just what we need to test a route and do other plain IPv6 stuff. Neighbor Discovery and the adjoining cache (storing remote link-local addresses for tens of seconds, and initially trying at a known-to-have-worked link-local address) would start to work for us, and give a lot of resolution issues away for free. That's because the tunnel is integrating much better with the IPv6 architecture, IMHO. To integrate even better, we should change the address format from PREFIX64 | I.I.I.I | P.P | N.N to the usual link-local based form PREFIX64 | P'.P.I | 0xfffe | I.I.I.I Note how N.N has been replaced with 0xfffe -- by default, that is. There does not seem to be any problem with using other values in the place of 0xfffe, so that would change the default values for N.N but otherwise retain the flexibility with PREFIX64 | P'.P.I | N.N | I.I.I.I The other big change would be that the interface used to have a /112 prefix and will now have the common /64 prefix. The result of that is that every address that starts with PREFIX64 will be routed through the 6bed4 tunnel, even if no default route to fe80::/128 has been setup. This makes sense, as it exploits the neighbor cache and initiates Neighbor Solicitation. Handling a Neighbor Solicitation from the IPv6 stack is a somewhat complex task for the 6bed4 tunnel -- it should try a number of addresses, the ones previously described to have various distance metrics: 1. multicast to the LAN if remote and local IPv4 are the same 2. direct IPv4/UDP access 3. fallback to the public tunnel server The Router Solicitation is also still exceptional -- it must be sent before the interface goes up, as it will provide the "hardware address" for the interface. So the tunnel must take the initiative to send it, and interpret the response. It should find the server's findings of external UDP port and IPv4 address and put that into the hardware address, then bring up the tunnel interface and let the IPv6 stack run its own round of Router Solicitation -- to which it will respond the PREFIX64 for 6bed4 and let the IPv6 stack do its thing to construct an address in the default manner... and setup a /64 prefix so all 6bed4 traffic routes through the tunnel. Address changes could pose a problem when an address cannot be deprecated by non-root users -- the tunnel might have to be taken down. So be it. Keepalive can be used to work around this, and the tunnel could implement that, of course. I have appreciated all the detailed input in email discussions, but I needed offline time to make the concepts flow fluidly, detached from visual shapes or term definitions. I hope you agree that my radio silence has been worthwhile :-) I'm not really interactive yet, I fear. I am beating up the code, and will write a new draft version soon. If you feel like discussing matters from this email, please call -- it's much more interactive than email. Thanks for your interest! Cheers, Rick van Rein OpenFortress +31.53.4782239 (SIP available, ask or harvest ENUM) |
From: Timothy B. <tim...@fa...> - 2011-12-10 22:09:42
|
On 05/12/11 23:26, Rick van Rein wrote: > Hello Tim, > > Thanks for getting into this! Fragmentation is something that > I don't excell at, so this is really useful input. I'm trying > to summerise the situation, and conclude in A to E below what > seems to be the best approach. Do you agree? > > As I understand from IPv4: > 1. IPv4 permits silently dropping packets>576 bytes during fragment reassembly Yes, but one will not be using an IPv6 tunnel on such nodes, all major operating systems support larger packets. > 2. IPv4 path MTU discovery uses the DF-bit to avoid fragmentation Yes > 3. If the MTU of a leg along the path is exceeded, an ICMPv4 error is sent back > (type 3, code 4) It should happen, the standard says "MUST", but it often does not. How often? > 4. Routing is dynamic, so this can principally occur at any time Yes, however it is common for the small MTU to occur over statically routed links to single-homed customers. > Furthermore, for IPv6: > 5. IPv6 packets can only be fragmented and reassembled in end-points Yes > 6. An IPv6 packet that won't fit an MTU results in ICMPv6 (type 2, code 0) Yes > 7. Routing is dynamic, so this can principally occur at any time > > From this, I'm tempted to conclude: > > A. Due to 1. tunnel packets could silently but consistently disappear > _unless_ DF is set. Since that is unacceptable, the IPv4 level MUST > set the DF bit. No, unfortunately the opposite is the case. > B. With DF set, an ICMPv4 message informs the sender if an MTU along the path > is being exceeded. This ICMPv4 message (type 3, code 4) could be translated > to the corresponding ICMPv6 message (type 2, code 0) to inform the > IPv6 layer about fragmentation requirements. (I hope there will be enough > data available in the ICMPv4 message to make that possible, by the way.) It's usually not translatable, RFC792 states that 64 bits of the IP payload MUST be included, that is just the UDP header. Whilst RFC1812 states that as much as possible SHOULD be included, the reality is that just 8 bytes is common. > C. This means that the IPv4 layer never does any packet reassembly at all, No. > which is rather desirable for the packets to flow through quickly and > statelessly. It's also desirable as IPv4 fragment reassembly is unreliable with multiple anycast sources, the beginning of packet A could be attached to the end of packet B. > In addition, 6bed4 can process fragmentation issues in > a stateless manner, namely by direct translation of ICMP messages. No, see above. > D. From this, it would follow that an MTU in excess of 1280 is possible, > as long as the IPv6 client is aware of the risks involved, of needing to > fragment the packet. Backwards, setting a small IPv6 MTU increases the risk of IPv6 fragmentation being needed, but reduces IPv4 fragmentation. Reducing the MTU at endpoints avoids the risk of mis-configured firewalls dropping ICMPv6 Too Big as TCP will never attempt to send a packet larger than the MTU at either end, reducing the MTU at a router increases the risk of problems. A typical TCP implementation never sends fragmented packets. Did you mean the risk of having to retransmit? > In other words, 1280 is not a "MUST" for the MTU of > 6bed4, but rather a "SHOULD" with an explanation/warning against higher > MTU values. > > E. A remaining problem is that the minimum MTU for IPv6 is 1280 and IPv4 > does not guarantee that, let alone in a tunnel, so packets of 1280 or > even less might lead to ICMPv6 type 2, code 0 messages. That is a > nuisance, except that it won't happen in practice as the Internet has > support for near-1500 packet sizes. In that case we just let IPv4 fragmentation happen. > F. An alternative would be to set DF only on packets with an IPv6 MTU > in excess of 1280, and to rely on packet fragmentation to help a few > more IPv6 packets through IPv4 than would be possible with DF set. > I'd rather not: it adds complexity; it is ugly; it is not a complete > solution; an IPv6 application may well be able to scale down its > packets to an MTU below 1280 and achieve a much greater chance of > success. A ICMPv6 Too Big packet will not reliably result in smaller than 1280 byte packets, it certainly will not cause IPv6 layer fragmentation to smaller packets, it only results in a fragment header being perpended so that the packet can be fragmented after a IPv6 to IPv4 translator. RFC 1918 states: A node MUST NOT reduce its estimate of the Path MTU below the IPv6 minimum link MTU. RFC 2460 states: IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6. I suggest that the client MUST either honor the MTU specified in the router advertisement, which SHOULD be low enough to avoid excessive IPv4 fragmentation, or use IPv4 path MTU discovery, it SHOULD take precautions against IPv4 PMTU black-holes. The Relay MAY respond to IPv4 fragmentation by sending ICMPv6 Too Big or a router advertisement with a lower MTU. Relays SHOULD have a IPv6 MTU of 1280 for sending encapsulated packets unless either they perform IPv4 path MTU discovery (which will often/usually be impossible). Otherwise using larger packets will increase the risk of packet fragmentation and mis-reassembly due identification field collision. I do not think more complicated schemes are worthwhile to decrease the overhead from 7.91% to 7.13% (on Ethernet), compared to 5.32% for native IPv6 and 4.02% for IPv4. |
From: Rick v. R. <ri...@op...> - 2011-12-05 23:26:27
|
Hello Tim, Thanks for getting into this! Fragmentation is something that I don't excell at, so this is really useful input. I'm trying to summerise the situation, and conclude in A to E below what seems to be the best approach. Do you agree? As I understand from IPv4: 1. IPv4 permits silently dropping packets >576 bytes during fragment reassembly 2. IPv4 path MTU discovery uses the DF-bit to avoid fragmentation 3. If the MTU of a leg along the path is exceeded, an ICMPv4 error is sent back (type 3, code 4) 4. Routing is dynamic, so this can principally occur at any time Furthermore, for IPv6: 5. IPv6 packets can only be fragmented and reassembled in end-points 6. An IPv6 packet that won't fit an MTU results in ICMPv6 (type 2, code 0) 7. Routing is dynamic, so this can principally occur at any time From this, I'm tempted to conclude: A. Due to 1. tunnel packets could silently but consistently disappear _unless_ DF is set. Since that is unacceptable, the IPv4 level MUST set the DF bit. B. With DF set, an ICMPv4 message informs the sender if an MTU along the path is being exceeded. This ICMPv4 message (type 3, code 4) could be translated to the corresponding ICMPv6 message (type 2, code 0) to inform the IPv6 layer about fragmentation requirements. (I hope there will be enough data available in the ICMPv4 message to make that possible, by the way.) C. This means that the IPv4 layer never does any packet reassembly at all, which is rather desirable for the packets to flow through quickly and statelessly. In addition, 6bed4 can process fragmentation issues in a stateless manner, namely by direct translation of ICMP messages. D. From this, it would follow that an MTU in excess of 1280 is possible, as long as the IPv6 client is aware of the risks involved, of needing to fragment the packet. In other words, 1280 is not a "MUST" for the MTU of 6bed4, but rather a "SHOULD" with an explanation/warning against higher MTU values. E. A remaining problem is that the minimum MTU for IPv6 is 1280 and IPv4 does not guarantee that, let alone in a tunnel, so packets of 1280 or even less might lead to ICMPv6 type 2, code 0 messages. That is a nuisance, except that it won't happen in practice as the Internet has support for near-1500 packet sizes. F. An alternative would be to set DF only on packets with an IPv6 MTU in excess of 1280, and to rely on packet fragmentation to help a few more IPv6 packets through IPv4 than would be possible with DF set. I'd rather not: it adds complexity; it is ugly; it is not a complete solution; an IPv6 application may well be able to scale down its packets to an MTU below 1280 and achieve a much greater chance of success. Do you agree with A to E? How do you feel about F? Thanks, -Rick |
From: Timothy B. <tim...@fa...> - 2011-12-05 21:31:39
|
On 30/11/11 09:22, Joost Lek wrote: > On Nov 30, 2011, at 12:13 AM, Timothy Baldwin wrote: >> That could lead to a relay reassembling IPv4 packets before forwarding >> them, the IPv6 MTU should be limited to IPv4 MTU-overhead. The client >> MUST perform IPv4 MTU discovery reliably, this is difficult given some >> NAT routers don't issue ICMP Fragmentation Needed errors, but instead >> adjust the TCP MSS. >> >> The route from the relay to client is more difficult, IPv4 MTU discovery >> by the relay is impossible, and there is a risk that packets from >> different relays will have different identification fields and mixed up >> on reassembly. Perhaps the client could respond to IPv4 fragments with >> IPv6 Too Big. That won't work reliably, as middleboxes often reassemble packets. > I agree that the ideal situation would be to determine the IPv4 MTU and then set the IPv6 MTU to that, substracted by IPv4+UDP overhead. But as you already stated, determining IPv4 MTU is difficult at best, and will regularly prove to be impossible. With that option unavailable I agree with Rick in his view that 1280 should be a very reasonable default. > > On the subject of fragmented v4 packets: won't that be transparent for the tunnel client unless the DF bit is set? I can see that there will be a performance penalty to pay, but I think (reliable) connectivity should be the first priority. Unless the relay implements RFC4821 (and is therefore not stateless), I agree the best option is for it set DF=0. The point I was making is that IPv4 Fragmentation should be avoided by setting a small IPv6 MTU. Traditional path MTU discovery does not work for Anycast sources, the ICMP Fragmentation Needed packets will go to the wrong relay. IPv4 fragment reassembly is unreliable for anycast sources, consider the case of two relays each sending a packet to the same 6bed4 client, the IPv4 addresses of these packets will be identical, and there would be a 1 in 65536 the Identification field will be identical; if this occurs the IPv4 stack may incorrectly re-assemble the packets. This subject has been discussed extensively in relation to 6RD. It would be reasonable for the client to honor any MTU option in the router advertisement, so that operators of local service profile relays may increase the MTU. |
From: Timothy B. <tim...@fa...> - 2011-12-05 17:41:20
|
On 30/11/11 10:03, Rick van Rein wrote: > Hello Timothy, > > Welcome :) > >>> I don't see a benefit in deviating from the IPv6 protocol here and would say a minimum MTU of 1280 is required. If the MTU is too large, let the v6 layer handle the problem. >> That could lead to a relay reassembling IPv4 packets before forwarding >> them, the IPv6 MTU should be limited to IPv4 MTU-overhead. > Packet fragmentation at the IPv4 layer is always possible. IPv4 > was dimensioned for packets up to 576 bytes (after reassembly) as > per RFC 791 and may quietly drop larger ones. This deviates from > current practice, so it is a bit of a theoretical problem. > > What this means however, is that an MTU in excess of 576 is never > safe to assume; IPv6 on the other hand, requires a minimum MTU of > 1280. Combining these spells disaster for tunnels -- in theory. > > In practice, this should not be much of a problem. Virtuall all > current Internet is run over MTU 1500 networks, so fragmentation > at the IPv4 level would be highly exceptional. > > Fragmantation can occur within IPv6, even after path discovery. > This is the result of routing dynamicity. It is a risk that every > IPv6 layer should take into account. But it is also true that > 6bed4 increases that dynamicity. > >> The client >> MUST perform IPv4 MTU discovery reliably, this is difficult given some >> NAT routers don't issue ICMP Fragmentation Needed errors, but instead >> adjust the TCP MSS. > You are saying that the 6bed4 tunnel would have to perform IPv4 MTU > discovery if it were to support higher MTU's for IPv6, right? Are > you suggesting that 6bed4 needs to do more than merely pass the > MTU discovery attempts from a using IPv6 layer? If IPv4 MTU discovery does not happen, it will not pass the information on to IPv6. It is impossible to translate IPv4 Fragmentation Needed to IPv6 reliably. The only alternative to IPv4 MTU discovery is to set DF=1 and let the routers fragment as required. Now consider that it is common to find hosts connected to Ethernet LAN with a 1500 byte MTU, but after the local (NAT) router the connection is PPP over Ethernet, or some other link with a smaller MTU. If the 6bed4 clients choose a MTU of 1472 to just fit the Ethernet MTU, this will result in lots of IPv4 fragments which the relay will need to reassemble. This is far from the envisioned stateless relay service, and will require a far more costly hardware. Therefore either a small MTU should be used, or IPv4 path MTU detection. This MTU could be larger than the IPv6 minimum. > I'm afraid that IPv4-level fragmentation, which can arise as soon as a > path element has an MTU below 1500, is a fact of life that cannot be > avoided. I don't think this problem can be solved in the tunnel. It > is one of the ways of saying "native IPv6 is better". It can be avoided by ensuring the IPv6 MTU is small enough as per the draft, for 6bed4 it is only unavoidable if the IPv4 path MTU is less than 1308. This is most likely. |
From: Rick v. R. <ri...@op...> - 2011-12-01 15:27:14
|
Hey, > However the IPv4 WAN which will be between a lot of the other 6bed4 peer-to-peer connections has a few contradictions with the foundation IPv6 ND assumes: I'm going to address your concerns below, in as general terms as you are raising them. If you had a concrete example that might be helpful. Although it is likely that 6bed4 does not aim to be the rock-solid solution that native IPv6 would be. > there could be high latency, High latency is solved by a fallback to the Public 6bed4 Relay, with the ability to learn a slowly-arrived ND response with a lower metric at some later time. ND is only used to find an _alternate_ route, a more optimal one, and never to find the main one. > unknown NAT and firewall situations, I see it as an advantage of 6bed4 that it has no knowledge whatsoever about the NAT or firewall mechanisms, but simply tries the thing it wants to have done, namely send IPv6-UDP-IPv4 traffic. The ND is just an attempt to charter new territory; to boldly go where no-one has gone before. It should succeed precisely when IPv6-UDP-IPv4 is going to work, and the only assumption made with that is that the IPv4 router makes no distinction between ICMPv6-IPv6-UDP-IPv4 and other IPv6-UDP-IPv4. That is a pretty safe assumption for IPv4 NAT :-) > low bandwidth End nodes are not usually setup with guaranteed bandwidth, and it is impossible over arbitrary routes. OTH, the ND-found routes should have a shorter path and thus run into less restrictions of traffic. If not... well, perhaps native IPv6 is better than a tunnel, no surprises there. QoS over a tunnel would be very nice to offer, but a bit too far-fetched IMHO. It should certainly not be the cause of complicating the tunnel -> and making its acceptance drop on account of that. > and practically no multicast/broadcast capability. The 6bed4 spec only uses multicast on the directly attached LAN, for which it is not going to be a problem. And again, that is a bypass searching attempt, it will always be possible to go through the Public 6bed4 Relay if a local network is not configured to handle the protocols, e.g. actively blocking them in bridged firewalls. Cheers, -Rick |
From: Timothy B. <tim...@fa...> - 2011-11-30 22:21:53
|
On 26/11/11 13:02, Joost Lek wrote: > On Nov 26, 2011, at 1:49 PM, Rick van Rein wrote: > > I don't see a benefit in deviating from the IPv6 protocol here and would say a minimum MTU of 1280 is required. If the MTU is too large, let the v6 layer handle the problem. That could lead to a relay reassembling IPv4 packets before forwarding them, the IPv6 MTU should be limited to IPv4 MTU-overhead. The client MUST perform IPv4 MTU discovery reliably, this is difficult given some NAT routers don't issue ICMP Fragmentation Needed errors, but instead adjust the TCP MSS. The route from the relay to client is more difficult, IPv4 MTU discovery by the relay is impossible, and there is a risk that packets from different relays will have different identification fields and mixed up on reassembly. Perhaps the client could respond to IPv4 fragments with IPv6 Too Big. |
From: Joost L. <vla...@gm...> - 2011-11-30 17:17:05
|
Hi Rick, On Nov 30, 2011, at 11:18 AM, Rick van Rein wrote: > I do not agree that any host in the routing layer > should keep state. This would seriously degrade > their performance, and also the performance of the > layers built on top of it, due to the lookups that > have to be made in tables that grow with the > complexity of the network. > > Moreover, I am not sure what you are trying to > accomplish with this proposal. The mechanism of > Neighbor Discovery is extremely lightweight and > already does all it should do -- AFAIK. > > We already have an over-engineered tunnel protocol > named Teredo; I think 6bed4 should avoid taking > that path, but with the complexity that you are > introducing we would probably have to add lots > more. > > The power of 6bed4 is, IMHO, its simplicity. The > addition of ND is a necessity, but it actually is > to my disliking because it disrupts the elegant > simplicity of the v00 version. I think I understand where you're coming from and agree with your argument that neighbor discovery should add the least amount of complexity possible. However as you already stated ND will be a necessity for 6bed4 to be useful in a lot of deployment scenarios, so we're on the same page on this point too. Where I don't agree with you is the point ND is sufficient as a peer-to-peer addition to the v00 protocol. ND is written with one very relevant assumption: an underlying LAN or LAN-like network (ie: low latency, high availability, high bandwidth and broadcast or multicast capability). Of course when using ND for local-lan connections where two 6bed4 peers are on the same LAN and these same assumptions hold, using the ND protocol itself is fine. However the IPv4 WAN which will be between a lot of the other 6bed4 peer-to-peer connections has a few contradictions with the foundation IPv6 ND assumes: there could be high latency, unknown NAT and firewall situations, low bandwidth and practically no multicast/broadcast capability. I very much look forward to finding a solution for this problem, however I disagree with you that throwing plain ND messages wrapped in v4 packets is going to be it. I'm looking forward to having a look at your new proposal for v01, I have a feeling we're working towards a useful standard. Joost |