Thread: [6bed4-devel] Comments and thoughts on bed64
zeroconfig IPv6 tunnel
Status: Beta
Brought to you by:
vanrein
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: <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 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: 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-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: 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 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: Timothy B. <tim...@fa...> - 2012-07-05 23:50:22
|
On 15/06/12 08:35, Eric W. Biederman wrote: > - 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. It's easy to know who to blame for a broken Teredo relay - the ISP providing (non-Teredo) IPv6 connectivity, a particular IPv6 host will use the same Teredo relay for connection to all Teredo clients.. If the IPv6 ISP isn't operating a relay they can solve the problem by running one. Teredo does however have other problems. Also almost all the references broken 6to4 relays I can find refer to de-encapsulating IPv4 anycast relays, and I scanned all 110 web sites in the Alexa top 1000 that have a IPv6 address on the domain from a 6to4 address and found no 6to4 blackholes. Richard Barnes also found the same with World IPv6 day participants, https://labs.ripe.net/Members/rbarnes/world-ipv6-day-asymmetric-6to4-measurements. This would suggest that ISPs that provide IPv6 service make sure 6to4 works, but many that don't provide IPv6 don't care about 6to4. > 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. A public profile with well known addresses will become increasingly useful as the IPv6 transition progresses, providing reliable IPv6 connectivity between hosts on a IPv4 only ISP and hosts on a IPv6 ISP that runs a 6bed4 router. I so suggest the problems be fixed: If a flag is set (such as setting the IP version to 4) the 6bed4 router should rewrite the beginning of the IPv6 source address to it's own unicast prefix when de-encapsulating. A traceroute implementation could use this to trace though a 6bed4 router from a 6bed4 client. 6bed4 routers should include their unicast IPv4 address and a nonce specific to the client in all IPv4 packets they send. If 6bed4 routers receive a IPv4 encapsulated IPv6 packet with a correct nonce they should de-encapsulate and forward it even if IPv4 source address doesn't match. The nonce could be a hash of a secret and the client 6bed4 address prepended with a number identifying which secret was used (to allow rekeying). The clients could then locate a router near the remote end by sending a ICMPv6 Echo Request and recording the unicast IPv4 address in the response. This could be extended to allow stateful routers that use a unicast IPv4 address, such routers could be placed where they can not use the anycast address as a source address and provide service to a small IPv6 network. With the majority of traffic kept away from routers discovered using IPv4 anycast, the performance problem of routers discovered by Ipv4 anycast diminishes, this however leaves the problem of completely broken 6bed4 routers. This could be worked around by a client by using a unicast address of a working router. If any NAT is cone or port-preserving, or the router is running a local profile service based on the unicast address the 6bed4 address will be correct; otherwise the client will need to scan for the correct port. Or would a social solution to the problems of broken routers be more practical? Anycast DNS does work. Perhaps better measurements of the number of broken de-encapsulating 6to4 relays are needed? > - 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. No, since one is still using a router chosen by IPv4 anycast routing. However it does allow issuing a provider assigned IPv6 address to a multihomed customer. > > > . 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. Or in many deployments, such a typical broadband network, skipping the 6bed4 router is only beneficial if the hosts are on same link. |
From: <ebi...@xm...> - 2012-07-23 14:50:15
|
Timothy Baldwin <tim...@fa...> writes: > On 15/06/12 08:35, Eric W. Biederman wrote: >> - 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. > It's easy to know who to blame for a broken Teredo relay - the ISP > providing (non-Teredo) IPv6 connectivity, a particular IPv6 host will > use the same Teredo relay for connection to all Teredo clients.. If the > IPv6 ISP isn't operating a relay they can solve the problem by running > one. Teredo does however have other problems. I stopped and took a good hard look at Teredo, and not running a Teredo relay does not appear to be the only reason Teredo fails. If the data from http://www.potaroo.net/ispcol/2011-04/teredo.html is at all representative. Teredo not only gives up early when it has preconceived notions that it is behind a sucky NAT that it can't work with, but Teredo also fails to setup tunnels to the local Teredo relay. > Also almost all the references broken 6to4 relays I can find refer to > de-encapsulating IPv4 anycast relays, and I scanned all 110 web sites in > the Alexa top 1000 that have a IPv6 address on the domain from a 6to4 > address and found no 6to4 blackholes. Richard Barnes also found the same > with World IPv6 day participants, > https://labs.ripe.net/Members/rbarnes/world-ipv6-day-asymmetric-6to4-measurements. > This would suggest that ISPs that provide IPv6 service make sure 6to4 > works, but many that don't provide IPv6 don't care about 6to4. That seems reasonable. 6to4 isn't totally beautiful but on a good day 6to4 works. There are failure modes where 6to4 mysteriously works in only one direction but those failure modes seem to be rare. It used to be common to have to go half way around the world to get a 6to4 relay, and that was also very strange. I expect poking at router servers and looking glass servers could explain why you don't have a local 6to4 router just like they roughly can explain just about any routing problem. >> 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. > A public profile with well known addresses will become increasingly > useful as the IPv6 transition progresses, providing reliable IPv6 > connectivity between hosts on a IPv4 only ISP and hosts on a IPv6 ISP > that runs a 6bed4 router. > > I so suggest the problems be fixed: > > If a flag is set (such as setting the IP version to 4) the 6bed4 router > should rewrite the beginning of the IPv6 source address to it's own > unicast prefix when de-encapsulating. A traceroute implementation could > use this to trace though a 6bed4 router from a 6bed4 client. Simply using not replying with a 6bed4 ipv6 address in icmp errors achieves this without a flag. > 6bed4 routers should include their unicast IPv4 address and a nonce > specific to the client in all IPv4 packets they send. If 6bed4 routers > receive a IPv4 encapsulated IPv6 packet with a correct nonce they should > de-encapsulate and forward it even if IPv4 source address doesn't > match. Including a nonce specific to a client requires keeping client specific state which limits scalability, and reliability. > The clients could then locate a router near the remote end by sending a > ICMPv6 Echo Request and recording the unicast IPv4 address in the > response. The Teredo trick of using an Echo Request to find the closest router is very clever. Having looked at that idea in some detail now a much less clever and much more effective technique is to simply send a request to setup a tunnel to the destination ipv6 address. It works or it doesn't and it is unaffected by unrelated policy like allowing icmp echo requests. > With the majority of traffic kept away from routers discovered using > IPv4 anycast, the performance problem of routers discovered by Ipv4 > anycast diminishes, this however leaves the problem of completely broken > 6bed4 routers. This could be worked around by a client by using a > unicast address of a working router. If any NAT is cone or > port-preserving, or the router is running a local profile service based > on the unicast address the 6bed4 address will be correct; otherwise the > client will need to scan for the correct port. > > Or would a social solution to the problems of broken routers be more > practical? Anycast DNS does work. Perhaps better measurements of the > number of broken de-encapsulating 6to4 relays are needed? I think a social solution to broken routers is more acceptable. Hey your router is causing a black hole. I am going to filter you in BGP, go get your act together. >> 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. > > Or in many deployments, such a typical broadband network, skipping the > 6bed4 router is only beneficial if the hosts are on same link. If someone cares and deploys a 6bed4 router semi-locally I expect that is true. On the flip side I would prefer that someone would actually deploy native ipv6 instead. Largely the time for tunnels is past. It looks to me like 6bed4 will be the solution for people on hold out ISPs. Eric |