tun6bed4-devel Mailing List for 6bed4
zeroconfig IPv6 tunnel
Status: Beta
Brought to you by:
vanrein
Menu
▾
▴
tun6bed4-devel — Developer discussion related to 6bed4
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: Rick v. R. <ri...@op...> - 2014-10-15 12:51:11
|
Hello all, It’s been a long time, but 6bed4 has been in the pipeline all along — the pipe just got clogged a bit because our ARPA2.net project is taking off. There is a new Internet Draft for 6bed4, available here: https://datatracker.ietf.org/doc/draft-vanrein-6bed4/ This is probably the last draft before I can forward it to the RFC Editor. There have been a few changes: * The address format was said to be “wasteful” of IPv6 space * The top half now doesn’t mention a port; instead, 6bed4 now assumes a TBD default port for the 6bed4 Server * This reduced the required prefix to a size that I can request with a mere “experimental” level RFC (similar for the port) * The prefix sizes are in line with the sizes that are commonly stored in backbone routers * It will be possible to run your own 6bed4 Server even on a SOHO network, by just forwarding the TBD default port * There are clearly marked openings for multicast support over 6bed4 * There is a clearly marked opening for LAN-based Stateless Address AutoConfiguration of a local /64 under 6bed4 * There is no mention of anycast-based routing anymore; it is not required, but still possible * I detailed at length how “opportunistic peering” can be used to connect to peers * It is even possible to do this (or try to do this) without intervention from the 6bed4 Server * Incorporated a SEcure Neighbor Discovery nonce into messages to avoid replay and guessing It certainly isn’t the simple protocol anymore that it was initially, but I dare say it has matured into a very versatile little protocol! As always, your feedback is kindly appreciated. Cheers, -Rick |
|
From: Rick v. R. <ri...@op...> - 2013-12-31 12:28:49
|
Hey, > Thanks your guide, you had done so many fundamental research in ipv6 traversal, it will greatly promote ipv6 popularize in lots of fields. Gladly done. I want SIP to run over IPv6 more than anything else. Well, and get it secured of course. > I've checked your public tsp router side code, and found you noticed the tspc patch, is it gw6c or gogo6c client? very regret that it was losed with the site, do you have other copy for the client? Fixed the links by not making them point to the non-existent domain anymore. You should be able to download. The patch is relative to the TSP client for Debian. It basically makes tspc work according to the RFC. -Rick |
|
From: BOMB <bo...@gm...> - 2013-12-31 07:29:43
|
Hi, Rick, You are right, the authtication mechanism will be worked on ipv4 layer, just like tunnel broker, actuatlly the total service is the combination of tsp serving for control plain and 6in4 for dataplain, I will use 6bed4 as same. But a obvious fact is that, 6bed4 accually acts a dynamic and automatic tunnel negotiation mechanism for peers, no-authentication is better than authentication, however the authentication must be considered in most of business case, I was thinking this today, roughly there are 2 methods could be used, 1, iptables filter, the chain is working on whilte list, only datagrams for authenticated users can be transmitted. 2, routing table, the system will create a policy routing item for every connection, otherwise will be dropped . but the 2 methods will bring huge computing huge, imagin the item count is over 100k . Do you have better choices for authentication ? BOMB 2013-12-31 发件人： Rick van Rein 发送时间： 2013-12-30 22:00:53 收件人： tun6bed4-devel 抄送： 主题： Re: [6bed4-devel] Testbed for 6bed4 Hello, > I want to setup a free ipv6 service to public […] the only free bunnel broker is CITC tunnel broker Looking it up, I found that it uses TSP. As a predecessor to 6bed4, I have tried to create something I called “Public TSP”, which is still documented here, http://devel.0cpm.org/public-tsp/ although the expired domain name public-tsp.org now appears to be used for hip implants :) I left TSP because the software is not maintained (obvious bugs in the client are not fixed, not even when submitting patches) even when the software is incompatible with its own RFC (!) I did get far in implementing a TSP server in open source though, and it can still be found at http://git.arpa2.org/?p=public-tsp;a=summary Note that this will always lead to scaling problems, especially for free service. My main motivation was to tunnel SIP traffic, to permit end-to-end IPv6 communication. That relieves users from RTP proxy dependency, thus dependency on telco’s and SDP rewriting. SDP is ideally passed with encryption, so it can hold key material for SRTP encryption. The 6bed4 tunnel is perfect for SIP and other peer to peer protocols, in that it will make direct connections whenever possible. This is the only remedy to achieve scalability. The difference with Teredo is… well… that 6bed4 works. Sorry to say this, but the most-deployed IPv6 tunnel in the World is relying on an outdated model of NAT, which assumes a strict classification of types of NAT which has since been established as unreliable. As a result, you could get an IPv6 for your local end but still see 1/3 of remote hosts unreachable over IPv6. And it’s so much more smiple to simply try to send a packet directly and draw warranted conclusions from that ;-) -Rick ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ tun6bed4-devel mailing list tun...@li... https://lists.sourceforge.net/lists/listinfo/tun6bed4-devel |
|
From: BOMB <bo...@gm...> - 2013-12-31 00:39:22
|
Hi, Rick, Thanks your guide, you had done so many fundamental research in ipv6 traversal, it will greatly promote ipv6 popularize in lots of fields. I've checked your public tsp router side code, and found you noticed the tspc patch, is it gw6c or gogo6c client? very regret that it was losed with the site, do you have other copy for the client? Thanks, Bomb 发件人： Rick van Rein 发送时间： 2013-12-30 22:00:53 收件人： tun6bed4-devel 抄送： 主题： Re: [6bed4-devel] Testbed for 6bed4 Hello, > I want to setup a free ipv6 service to public […] the only free bunnel broker is CITC tunnel broker Looking it up, I found that it uses TSP. As a predecessor to 6bed4, I have tried to create something I called “Public TSP”, which is still documented here, http://devel.0cpm.org/public-tsp/ although the expired domain name public-tsp.org now appears to be used for hip implants :) I left TSP because the software is not maintained (obvious bugs in the client are not fixed, not even when submitting patches) even when the software is incompatible with its own RFC (!) I did get far in implementing a TSP server in open source though, and it can still be found at http://git.arpa2.org/?p=public-tsp;a=summary Note that this will always lead to scaling problems, especially for free service. My main motivation was to tunnel SIP traffic, to permit end-to-end IPv6 communication. That relieves users from RTP proxy dependency, thus dependency on telco’s and SDP rewriting. SDP is ideally passed with encryption, so it can hold key material for SRTP encryption. The 6bed4 tunnel is perfect for SIP and other peer to peer protocols, in that it will make direct connections whenever possible. This is the only remedy to achieve scalability. The difference with Teredo is… well… that 6bed4 works. Sorry to say this, but the most-deployed IPv6 tunnel in the World is relying on an outdated model of NAT, which assumes a strict classification of types of NAT which has since been established as unreliable. As a result, you could get an IPv6 for your local end but still see 1/3 of remote hosts unreachable over IPv6. And it’s so much more smiple to simply try to send a packet directly and draw warranted conclusions from that ;-) -Rick ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ tun6bed4-devel mailing list tun...@li... https://lists.sourceforge.net/lists/listinfo/tun6bed4-devel |
|
From: Rick v. R. <ri...@op...> - 2013-12-30 14:00:50
|
Hello, > I want to setup a free ipv6 service to public […] the only free bunnel broker is CITC tunnel broker Looking it up, I found that it uses TSP. As a predecessor to 6bed4, I have tried to create something I called “Public TSP”, which is still documented here, http://devel.0cpm.org/public-tsp/ although the expired domain name public-tsp.org now appears to be used for hip implants :) I left TSP because the software is not maintained (obvious bugs in the client are not fixed, not even when submitting patches) even when the software is incompatible with its own RFC (!) I did get far in implementing a TSP server in open source though, and it can still be found at http://git.arpa2.org/?p=public-tsp;a=summary Note that this will always lead to scaling problems, especially for free service. My main motivation was to tunnel SIP traffic, to permit end-to-end IPv6 communication. That relieves users from RTP proxy dependency, thus dependency on telco’s and SDP rewriting. SDP is ideally passed with encryption, so it can hold key material for SRTP encryption. The 6bed4 tunnel is perfect for SIP and other peer to peer protocols, in that it will make direct connections whenever possible. This is the only remedy to achieve scalability. The difference with Teredo is… well… that 6bed4 works. Sorry to say this, but the most-deployed IPv6 tunnel in the World is relying on an outdated model of NAT, which assumes a strict classification of types of NAT which has since been established as unreliable. As a result, you could get an IPv6 for your local end but still see 1/3 of remote hosts unreachable over IPv6. And it’s so much more smiple to simply try to send a packet directly and draw warranted conclusions from that ;-) -Rick |
|
From: Rick v. R. <ri...@op...> - 2013-12-30 13:48:48
|
Hi, > I want to setup a free ipv6 service to public, Excellent! You are aware of RFC 7059 I suppose? It compares tunnel mechanisms. (And sorry for advertising my own scribblings!) > and think the tunnel broker may be a suitable approach, so I researched some transition project, it seems that most of providers use gogoserver as transition infrestucture, That infrastructure has rather noticeable scaling issues, because *all* traffic flows through it. Also, depending on server implementation, it could be possible to hijack a connection from behind the same NAT. > but I have no monty to offer the software, the only free bunnel broker is CITC tunnel broker, they use a python tool as demon broker and a kernel modul ddtb as udp-ipv6 transition, but very awful that the system must create a tunnel interface and set 2 iptables policies and 1 routing for every connection, I wondered what the problem was until you said “for every connection” :-) > and due to bind a port, the maximum capacity 2^16 is also a gap, so I continuously search the possible approches and found your RFC proposal, it really a talented and perfect method to resolve NAT traversal, *bow* thank you! > whatever cone or symmetrical, it will bring to complexity and mistake to consider every technical details, your thinking is a perfect compromise for the transition, and in fact 2^6 ipv6 addresses is enough to many units . …and if not, you can always opt for another 6bed4 lease. > So next step, I'll extended the authentication based on your RFC, may be the combination of tb authentication method and your thinking is a very perfect solution to public ipv6 service, I think I will make it online soon . I suppose it is possible to add authentication… the think I had in mind for that is simply setting the IPv4 addresses you can use. You might use any protocol (“pop before 6bed4”, grinn) to authenticate. It would be rather disturbing to add it to 6bed4, so I left it out. I’d love to hear your progress in this matter, so please keep posting any updates you go through! Cheers, -Rick |
|
From: BOMB <bo...@gm...> - 2013-12-30 13:12:27
|
Hi, Rick, Thanks your warm and detailed answers. I want to setup a free ipv6 service to public, and think the tunnel broker may be a suitable approach, so I researched some transition project, it seems that most of providers use gogoserver as transition infrestucture, but I have no monty to offer the software, the only free bunnel broker is CITC tunnel broker, they use a python tool as demon broker and a kernel modul ddtb as udp-ipv6 transition, but very awful that the system must create a tunnel interface and set 2 iptables policies and 1 routing for every connection, and due to bind a port, the maximum capacity 2^16 is also a gap, so I continuously search the possible approches and found your RFC proposal, it really a talented and perfect method to resolve NAT traversal, whatever cone or symmetrical, it will bring to complexity and mistake to consider every technical details, your thinking is a perfect compromise for the transition, and in fact 2^6 ipv6 addresses is enough to many units . So next step, I'll extended the authentication based on your RFC, may be the combination of tb authentication method and your thinking is a very perfect solution to public ipv6 service, I think I will make it online soon . Thanks, Bomb 发件人： Rick van Rein 发送时间： 2013-12-30 18:30:17 收件人： tun6bed4-devel 抄送： 主题： Re: [6bed4-devel] Testbed for 6bed4 Hello Bomisme, > Do you have the help docs for setup a test bed ? > The basic testing instructions for 6bed4 are here: http://devel.0cpm.org/6bed4/ If they leave anything open, please ask for what you need to know. > Assume that: > 1, Intranet Peer -> NAT Router -> Internet -> 6bed4 Tunneling Server > That is the usual setup of a self-help client. > 2, General Intranet Peer with RADVD Solicit (not 6bed4) -> NAT Router With RADVD and 6bed4 client -> Internet -> 6bed4 Tunneling Server > With radvd, you mean the daemon that supports stateless autoconfiguration, right? The suggested use of 6bed4 is to use the last bits in support of DHCPv6. In 6bed4 v2, which is currently the only version available as an implementation, it is not possible to free the full /64 for local use, but v3 will probably... alas, see the spec and see if it suits you! http://tools.ietf.org/html/draft-vanrein-6bed4 is the latest/v3 spec (since I started with another name, the numbering is confusing, due to IETF numbering policy) Please note that 6bed4 is undergoing a final transition (into a textually improved spec and with updated implementation) before I submit it to the RFC Editor, and that this has not been implemented in software yet -- which is the main reason for the wait. The new 6bed4 only requires a well-known /32 and a fixed UDP port, so it treads much lighter on Internet infrastructure. This is a clear desire in the community ;-) -Rick ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ tun6bed4-devel mailing list tun...@li... https://lists.sourceforge.net/lists/listinfo/tun6bed4-devel |
|
From: Rick v. R. <ri...@op...> - 2013-12-30 10:30:14
|
Hello Bomisme, > Do you have the help docs for setup a test bed ? > The basic testing instructions for 6bed4 are here: http://devel.0cpm.org/6bed4/ If they leave anything open, please ask for what you need to know. > Assume that: > 1, Intranet Peer -> NAT Router -> Internet -> 6bed4 Tunneling Server > That is the usual setup of a self-help client. > 2, General Intranet Peer with RADVD Solicit (not 6bed4) -> NAT Router With RADVD and 6bed4 client -> Internet -> 6bed4 Tunneling Server > With radvd, you mean the daemon that supports stateless autoconfiguration, right? The suggested use of 6bed4 is to use the last bits in support of DHCPv6. In 6bed4 v2, which is currently the only version available as an implementation, it is not possible to free the full /64 for local use, but v3 will probably... alas, see the spec and see if it suits you! http://tools.ietf.org/html/draft-vanrein-6bed4 is the latest/v3 spec (since I started with another name, the numbering is confusing, due to IETF numbering policy) Please note that 6bed4 is undergoing a final transition (into a textually improved spec and with updated implementation) before I submit it to the RFC Editor, and that this has not been implemented in software yet -- which is the main reason for the wait. The new 6bed4 only requires a well-known /32 and a fixed UDP port, so it treads much lighter on Internet infrastructure. This is a clear desire in the community ;-) -Rick |
|
From: BOMB <bo...@gm...> - 2013-12-30 04:06:06
|
Hi, Do you have the help docs for setup a test bed ? Assume that: 1, Intranet Peer -> NAT Router -> Internet -> 6bed4 Tunneling Server 2, General Intranet Peer with RADVD Solicit (not 6bed4) -> NAT Router With RADVD and 6bed4 client -> Internet -> 6bed4 Tunneling Server Thanks, Bomb |
|
From: BOMB <bo...@gm...> - 2013-12-30 04:03:59
|
Hi, Do you have the help docs for setup a test bed ? Assume that: 1, Intranet Peer -> NAT Router -> Internet -> 6bed4 Tunneling Server 2, General Intranet Peer with RADVD Solicit (not 6bed4) -> NAT Router With RADVD and 6bed4 client -> Internet -> 6bed4 Tunneling Server Thanks, Bomb BOMB 2013-12-30 |
|
From: Rick v. R. <ri...@op...> - 2012-09-21 19:38:34
|
Hello Eric, > Contratulations on getting the addresses. Thanks :) I haven't forgotten your input by the way... Your thought of using STUN actually seems possible, if you add TURN and apply RFC 6156. It's not as symmetric though; sent and received data differ. Also, the user accounts complicate things for end users. > I will just repeat my general impression that 6bed4 is a wonderful idea, > and that attempts to bypass the 6bed4 gateway are likely too much pain > for too little gain. Interestingly, your suggestion of Secure Neighbor Discovery is now playing through my mind... because ideally we'd connect other IPv6 ranges to a 6bed4 peer (provided the other peer can support it with an interface that just doesn't happen to be the default) and I'm playing with the thought of using Redirect messages for that, with some form of security. This could redirect a 6bed4 peer's attempt to reach a native address to a 6bed4 address that lives on the same machine; this bypasses the public service even for those classes of traffic. We should have the new addresses setup on Monday, and I hope to have an adapted tunnel code tested and ready to go at that time too. Anytime now :) Cheers, -Rick |
|
From: <ebi...@xm...> - 2012-09-21 09:45:21
|
Rick van Rein <ri...@op...> writes: > Hello, > > The 6bed4 tunnel will be presented at RIPE65, the European meeting > of core network engineers. It is scheduled on Tuesday morning in > a session of 3 lectures: > > Tuesday, 25 September 09:00 – 10:30 > Plenary > > * SLAACer or Prisoner of State > Paul Ebersman, Infoblox > > * RFC 5549 > Stefan Plug and Arien Vijn, AMS-IX > > * IPv6 for the Masses — with 6bed4 > Rick van Rein, OpenFortress > > Those of you visiting RIPE65 are quite welcome. I will be there > all week to talk about the tunnel. > > > By the way... I am aware that the v01 spec expired last week. It > seemed useless to me to prolong it with the potential of a lot of > feedback next week. > > > Also by the way... RIPE has reserved a /48 for 6bed4, as an > experimental range for anycast. We can use this for the coming > year. We also have an anycast-ready /24 in IPv4, so expect a > new daemon in the coming days, as soon as this infrastructure > is in place on our first node. After that, we can handle any > additional node without changing addresses. Contratulations on getting the addresses. I will just repeat my general impression that 6bed4 is a wonderful idea, and that attempts to bypass the 6bed4 gateway are likely too much pain for too little gain. Eric |
|
From: Rick v. R. <ri...@op...> - 2012-09-20 08:21:22
|
Hello, The 6bed4 tunnel will be presented at RIPE65, the European meeting of core network engineers. It is scheduled on Tuesday morning in a session of 3 lectures: Tuesday, 25 September 09:00 – 10:30 Plenary * SLAACer or Prisoner of State Paul Ebersman, Infoblox * RFC 5549 Stefan Plug and Arien Vijn, AMS-IX * IPv6 for the Masses — with 6bed4 Rick van Rein, OpenFortress Those of you visiting RIPE65 are quite welcome. I will be there all week to talk about the tunnel. By the way... I am aware that the v01 spec expired last week. It seemed useless to me to prolong it with the potential of a lot of feedback next week. Also by the way... RIPE has reserved a /48 for 6bed4, as an experimental range for anycast. We can use this for the coming year. We also have an anycast-ready /24 in IPv4, so expect a new daemon in the coming days, as soon as this infrastructure is in place on our first node. After that, we can handle any additional node without changing addresses. Cheers, -Rick |
|
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 |
|
From: <ebi...@xm...> - 2012-07-23 14:20:41
|
Rick van Rein <ri...@op...> writes: >> - 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. > > Note that odd *external* UDP ports are said to be illegal. This is at > the outside of NAT. > > The reason to ban odd port numbers on all nodes is to be able to show > one's address to a node that assumes ethernet semantics for the 6bed4 > interface. It seems a waste to disable interoperability with existing > stacks; this is why odd external UDP ports are banned. > > This is not a conceptual beauty, but it is the sort of pragmatics that > I'm willing to incorporate because 6bed4 is a transitional technique. The trade off is breaking some clients in myserious ways, instead of implementing an indirection table mapping mac addresses to ipv4 address and ports. Banning odd ports is a BAD idea. It means hosts will not be able to assume they have a working 6bed4 tunnel. Your reference implementation does not even handle the case when the NAT takes your even port and gives you an odd port. It is a bug you won't find in testing, it is a bug that will make people decide your protocol is flaky and deprecate it. So I disagree with the restriction to only use even ports in the strongest possible terms. On the flip side you can interoperate as ethernet with existing stacks with one simple layer of indirection. You can go farther and do a clean implemenation that doesn't claim to be eithernet and not even need that layer of indirection. But for the sake of a bit I don't want to see a protocol lost. Eric |
|
From: <ebi...@xm...> - 2012-07-23 13:46:47
|
Rick van Rein <ri...@op...> writes:
>> And ultimately you have what is effectively a whole new protocol.
>
> This might be a bit over the edge, I fear ;-) and you say you agree.
> On Tue, Jul 03, 2012 at 06:33:49PM -0700, Eric W. Biederman wrote:
>>
>> I have started playing the idea of encoding the ICE offer/answer
>> exchange as an STUN message and then I can let ICE/STUN take care
>> of trying different paths and finding one that works, and agreeing
>> on a common route.
>
> Interesting!
I have something working at this point, although not quite finished, I
haven't coded up the message-integrity check attribute of the
verification attribute but that is essentially orthogonal from the rest
of the work. It takes about a 3rd more code than your version of peer.c
but the code is absolutely bored when it comes to peircing my NAT test
cases.
The packet flow:
A B
ipv6 port 3478 <----------ice offer----------- ipv6 port 3478
ipv6 port 3478 ----------ice answer----------> ipv6 port 3478
ipv4 6bed4 port <-----stun binding request----> ipv4 6bed4 port
ipv4 6bed4 port <-----stun binding reply------> ipv4 6bed4 port
ipv4 6bed4 port <== shortcut tunnel traffic ==> ipv4 6bed4 port
The ipv6 address does not need to be a 6bed4 address. This allows any
host to bypass the 6bed4 router if it has the ability to receive traffic
on a ipv4 udp port. Only the ice offer/answer packet exchange go
must go through the 6bed4 router.
Currenlty I am running I am not buffering traffic and running traffic to
it's destination over the 6bed4 tunnel, until a shortcut tunnel forms.
The awesome and terrible feature of the shortcut tunnels is that traffic
is not sent over them until round trip reachability is confirmed, which
looks like it means just in time for a small flow to be completely
routed over the 6bed4 router while the tunnel is forming. Ugh. So I
expect I may need to delay the initial traffic to a host a little, to
get the tunnel to be useful to short bursts of traffic.
On the side of debugability I have coded up a ICMPv4 to ICMPv6 converter
and started storing sync the hop_count and the traffic_class between v4
and v6. And I have explicitly not configured an address on the 6bed4
router interface.
Which seems to give me parity on debugability with traceroute over ipv4
and ipv6. I can traceroute from an ipv6 host and see all of the ipv4
hops past the 6bed4 router. Likewise I can traceroute on the 6bed4
client side and see all of the hops on the way to the 6bed4 router. My
traceroutes through the 6bed4 router give me a router name other than
the generic 6bed4 name so I can tell which router I am dealing with.
It is kind of fun seeing a traceroute before and after the shortcut
tunnel forms.
Eric
|
|
From: <ebi...@xm...> - 2012-07-23 07:03:32
|
Rick van Rein <ri...@op...> writes: >> Reading through RFC 5245 Interactive Connectivity Establishment I came >> across a nasty observation. >> >> In some NATs you can not create a new hole faster than once ever 20ms. >> >> Which makes NAT holepunching something that has to be done a lot more >> carefully than I would have guessed. > > I am *so* done with NAT and IPv4... I can understand the feeling. I want to point out some specific things to take into consideration for future desgins. RFC6296 IPv6 to IPv6 Network Prefix Translation. All that changes is one IPv6 address in the IPv6 header. RFC6204 Basic Requirements for IPv6 Customer Edge Routers. This recommends following RFC6092 for packet filtering and it recommends deploying RFC4193 Unique Local addresses. The birthday paradox suggests that once there are above 1 million (10^6) users using ULAs there will be duplicate ULA prefixes. RFC6092 IPv6 CPE Simple Security. This recommends using at least address indepedent filtering, and possibly address dependent filter for IPv6 flows. Which means that many of the same challenges that existed in IPv4 will exist in a fully deployed IPv6. Where IPv6 improves upon the current situation is that there is no need for address sharing, and as such there is no excuse for implementing endpoint dependent translation. Without endpoint dependent translation (the EVIL of symmetric NATs) peer to peer communication will always be possible. Eric |
|
From: <ebi...@xm...> - 2012-07-12 11:01:05
|
Rick van Rein <ri...@op...> writes: > Hello Eric, > > Thanks again for your feedback. You've been so productive that I had > to allocate some serious time, causing the delay in the response. > > You picked up that the name is not bed64 but 6bed4, right? Yes. I'm not certain why I wrote bed64 in the initial subject line. >> However I do think this is a fun way to experiment with ICE and a very >> interesting way of coping with implementing NAT traversal outside >> end applications, so I am going to keep playing with this as time >> permits. So far except for tunnel setup speeds this looks very >> promising, and the least NIH that I have found. > > Meanwhile, my line will be to provide a working tunnel based on what > I already have. Delivering is more important to me, so I will be > a bit more conservative. As stated above, several of your > suggestions are directly usable, but not all are. I want to > thank you for all of them, and made quite a few notes for further > processing; I am interested in hearing what you will cook up! Sounds like a reasonable plan. > Once again, my apologies for the slow response. I'm afraid 6bed4 is > only one of my activities... no surprise there, I suppose ;-) No surprise there. Let me recommend to you rfc5128 "State of peer to peer communication across NATs", for it's vocabularly in talking about NATs. The vocabulary is much more specific and much more relevant then the vocabulary from RFC3489 STUN. Not that you want to fight NATs issues. But some at least when talking about bypass solutions it comes up. What is your vision for the set of problems you see 6bed4 solving? I think I have seen part of your vision when you said "Think alone of what it could do for peer-to-peer exchange of files in solutions (such as SIP, or chat, or YaCy) that are now fighting NAT traversal issues." You also mentioned not wanting to include both a full ipv4 stack and a full ipv6 stack, in thin embedded clients. The problem that is near and dear to my heart, is that when I talk to someone at a distance (say 2000 Kilometers) over a VOIP phone it works well if the RTP packets flow direction from my phone to the other parties. If the packets go through a relay connections are unreliable, and essentially undebugable. So I am very interested in figuring out which technologies will make those direct connections possible and easy to achieve. IPv6 is one of those technologies and ICE looks like it may be another. Eric |
|
From: Rick v. R. <ri...@op...> - 2012-07-12 08:50:11
|
Hello Eric, Thanks again for your feedback. You've been so productive that I had to allocate some serious time, causing the delay in the response. You picked up that the name is not bed64 but 6bed4, right? > - 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. The possible values are 0 for unspecified, or another value to set a valid time for a route. Such a time depends on assumptions about the NAT router, which is not generally available at the location where the 6bed4 client is run. It would be awkward to specify that "some value" should be set, without specifying what value. > 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. Agreed. I can mention the times that are common in practice, that makes sense to me. > - bed64 creates has NBMA non-broadcast multi-access links. > As such RFC2491 should be looked at and referred to.- Thanks, I hadn't seen this RFC before. I will read it and integrate its suggestions as well as I can -- and then refer to it. > - Using ipv4 address and udp port as the link layer address > looks like a good solution. Thanks. > - 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. This is what is done with Neighbor Solicitation + Advertisement. > Fpr neighbour solicitations and router solicitations I recommend > requiring the nonce option from RFC3971 Secure Neighbor Discovery. Interesting suggestion. Copying it would be a MUST when responding, and sending it initially a MAY or SHOULD. I had looked at Secure ND but found it was patented and therefore useless -- but that does not seem to apply to the nonce. I would also include the Timestamp. > 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. Some perspective on this: We never send to an untrusted address, but only to a router address determined out-of-band and hopefully securely, the target address itself or a LAN peer. As for the router address, we have a /24 into which we allocate it, so it is a fixed address. What you are worried about is the reply; keep in mind that guessing both the timing and UDP port and IP address for a client take quite some effort; but I do agree that Nonce/Timestamp options improve on that. As you seem to have grasped, it is never possible to divert peer traffic to an arbitrary IPv4 address by bombarding a victim with Neighbor Advertisements. The influence of adding Secure ND to those would be to thwart DoS attacks. > - 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. Yes, I think routing protocols should be stateless, to avoid drowning in administration. > - 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. Note that odd *external* UDP ports are said to be illegal. This is at the outside of NAT. The reason to ban odd port numbers on all nodes is to be able to show one's address to a node that assumes ethernet semantics for the 6bed4 interface. It seems a waste to disable interoperability with existing stacks; this is why odd external UDP ports are banned. This is not a conceptual beauty, but it is the sort of pragmatics that I'm willing to incorporate because 6bed4 is a transitional technique. > - 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. 6bed4 Cannot assume that it runs entirely within one AS, but an ISP is still able to route 6bed4 exactly as they like; beyond the ISP-internal scope, it will run into the complexity of the broad Internet. The advantage of an anycast address is the advantage of zero config operation, which IMHO is a vital part of 6bed4. It is difficult to debug 6to4, but according to research by the ISP Column the differences between forward and return routes are not the primary cause of problems; for 6to4 it was mainly that users run it behind NAT for which it hasn't been designed. I have been thinking about this, and it may make sense to setup some infra that is explicitly intended for debugging; not aiming to control it all, but at least to find a problem if it exists. For reasons of routability we have a /24 for anycast, and use only the .1 in it for 6bed4. It is easy enough to define behaviour for a .2 as well, possibly based on a /64 prefix that is local to the network. This would make it possible to (1) detect the node being used, (2) detect route changes, (3) send back to the original node. (It would even be possible for end users to prefer this address over an anycast address in the IPv6 space, at the expense of a change of their external address whenever anycast routing changes.) > - Bootstrapping. I suggest a slightly modified form of the existing > bootstrap mechanism. I'm not completely confident that I understand you here. Are you proposing to split the current Router Discovery into a phase of Router Discovery (providing the /64 prefix) and Neighbor Discovery (provoding our externally observed address/port as an LLaddr)? > . Avoidance of all vageries of global anycast routing. Please explain? > . 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 I think I will get this if I understand what you mean exactly. > - 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. There is currently no statement on this, indeed. Note that "real IPv6 traffic" always travels through the 6bed4 gateway; only 6bed4 to 6bed4 can be optimised with direct routes. > 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, If an attempt fails on one end, it will send through the router and mostly that would provide a response which is then permitted directly due to the hole opened by the initially failed attempt. At that time, the direct connection should be open in both directions. This will only fail on what is usually classified as symmetric NAT. > 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. I went through the same thoughts; ICE is not designed for this sort of thing and ND seemed to be just the right fit. > 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. Hmmm, a more complex spec to derive at potentially simpler software. This could be done by rearranging MUST (for direct route attempts) to SHOULD. The disadvantage would be that direct routes would only work if both endpoints supported it, which causes more attempts than warranted, and also retries. This is why it is currently a MUST. Furthermore, I'd like to learn what node operators think; I do not expect them to be as open to IPv6 traffic without bypasses. It is true that no work has currently been done to exploit direct links between 6bed4 nodes if at all possible, but trying to contact a 6bed4 peer over a 6bed4 interface if at all possible has been my angle. Setting up an interface with the proper /64 for 6bed4 as a low-priority route that looks like a locally attached interface would help a lot though. Normal routing rules would then do the right thing. And given the simplicity (zero config) of 6bed4 I would not be surprised if it got popular in distributions. Think alone of what it could do for peer-to-peer exchange of files in solutions (such as SIP, or chat, or YaCy) that are now fighting NAT traversal issues. > Or to put it another way your bypass route that invokes ipv4 multicast > and has all kinds of magic conditions I find very scary. This is the LAN flavour, right? You're being subjective when you call it scary ;-) but do note that this is optional in v01 because it might scare more people than just you. If your node decides not to use it, then you have nothing to fear. > 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. :) At least for SIP, I am working very hard to realise it. The whole 6bed4 tunnel was designed to enable SIP over IPv6. I'm also doing other transitioning work in that field, including the necessary translation between IPv4- and IPv6-based SIP/RTP. http://devel.0cpm.org/sitemap.html > - 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. I'm inclined to leave that as an implementation issue, not to be mentioned in a specification which basically declares the boundaries of proper conduct. On Fri, Jun 15, 2012 at 10:20:27AM -0700, Eric W. Biederman wrote: > > 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. What is currently done, is assume that the routes live forever. Then, if outgoing traffic gets mapped to a different external UDP port, it will lead to a response with a corrective Rtr Adv. The client for v01 incorporates a keepalive timer to keep NAT traversal open, and indeed make the route's time infinite. > I can see the practicality in infinite address timeouts, but since the > addresses may not be used for ever that seems unfortunately naive. As soon as we've standardised an RFC and have a final prefix assigned, the addresses are actually static. Just like 2002::/16 for 6to4 or 2001::/32 for Teredo. The addresses can be used as long as the 6bed4 interface is up, and sends keepalives as part of being up. The routes are tied to the interface, and will drop if the interface goes down. Before the interface goes down, the route, prefix, address are basically forever-lasting. > Router redirects: > > If it is desired to trust have a model where redirects may be trusted in > 6bed4 I recommend Secure ND is a good suggestion, indeed. Redirects are treated as suggestions, and lead to a normal ND process; Secure ND was discussed above. On Fri, Jun 15, 2012 at 02:19:58PM -0700, Eric W. Biederman wrote: > > 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 We'll get an experimental IPv6 anycast range assigned on Sep 3, 2012. This is a /48 range that we can recognise as use of 6bed4. On Sun, Jun 17, 2012 at 04:45:51PM -0700, Eric W. Biederman wrote: On Sun, Jun 17, 2012 at 05:12:18PM -0700, Eric W. Biederman wrote: I will process your patches separately. Probably after my holiday, which lasts until July 30. Thanks! On Sun, Jun 17, 2012 at 04:52:25PM -0700, Eric W. Biederman wrote: > > 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. Agreed -- see above. > 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. Yes, that can be done. I've already run into an admin who preferred to run 6bed4 on his own IPv4 address instead of locally diverting the anycast address. I'm not sure if this should be part of the spec, or just of the software. On Sun, Jun 17, 2012 at 05:10:01PM -0700, Eric W. Biederman wrote: > > 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. Symmetric NAT is not going to work, that is a known problem. If it is *just* a firewall, then the fact that a node sends out UDP between then known internal and external nodes should suffice. > 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. This is currently done, under the assumption that a packet send will usually lead to a response in a short time. Explained above. > 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). This is the ICE idea, right? On Tue, Jun 19, 2012 at 06:40:31PM -0700, Eric W. Biederman wrote: > > The general problem. Stateful firewalls incoporated into many NAT > devices only allow traffic to flow based on the 4 tuple > <srcip,srcport,destip,destport>. Symmetric NAT is a problem, symmetric firewalls are not. Please note that port changes constitute a potential change of machine and/or user, and could therefore lead to security problems. > I have attached the code and the setup for my test cases (based on > network namespaces below). Thanks -- I will look into it along with the patches. On Tue, Jul 03, 2012 at 05:27:04PM -0700, Eric W. Biederman wrote: > > There are two issues that using anycast addresses can trigger that both > impact debugging, and until I had those two issue conflated. > > - Anycast addresses are a good way to trigger assymetric routing. > - Anycast addresses hide which machine is the router in your path. > > Assymetric routes can happen with ipv4 and they are a pain, because > getting a reverse traceroute requires tracing from the other side. Yes, and this can be solved by using the .2 in the /24 and being setup with a locally available IPv6 address in the 6bed4 router's AS. Another return route could even be selected by communicating over IPv6, using the locally availabe IPv6 address of whatever target 6bed4 router's AS you'd like. > Having multiple routers at very different places in the network > operated by different people report the same address in traceroute > makes figuring out who to blame for slow traffic a real challenge. Agreed, hence the idea towards a tracing solution. > So I suggest adding: "ICMP time exceeded errors MUST NOT be reported > with a 6bed4 address." to make it possible to figure out whose 6bed4 > router is malfunctioning. Interesting. Especially when combined with the IPv6 address that does point to the target to blame. On Tue, Jul 03, 2012 at 05:30:20PM -0700, Eric W. Biederman wrote: > > Reading through RFC 5245 Interactive Connectivity Establishment I came > across a nasty observation. > > In some NATs you can not create a new hole faster than once ever 20ms. > > Which makes NAT holepunching something that has to be done a lot more > carefully than I would have guessed. I am *so* done with NAT and IPv4... On Tue, Jul 03, 2012 at 05:45:46PM -0700, Eric W. Biederman wrote: > > I took a quick look and the complexity of stateless nat64 looks to > be about 1000 lines of code or about the same as your original 6bed4 > tunnel that did not directly attempt to connect peer endpoints. > See http://www.litech.org/tayga/ NAT64 is typically used on a LAN or by an ISP; it is not generally considered an option for the Internet as a whole, so it does not function to provide "IPv6 for the masses" which is the intention of 6bed4. > This does indicate that you would need to implement ICE aka RFC5245 in > your VOIP clients but RFC5245 is required for proper IPv6 support > anyway, and the implementation if not the specification is pretty > simple. You're clearly a fan of ICE ;-) and the way of publishing multiple LLaddr in a single ND message is intruiging. On Tue, Jul 03, 2012 at 06:11:42PM -0700, Eric W. Biederman wrote: > > You have to add support for multiple source and destination addresses. > You have to require support for nonces, and use them to prevent > problems with source address spoofing. The nonces may indeed solve the matter with symmetric NAT, to ensure talking to the same process as before. > You have to change the semantics so that you don't trust source and > destination addresses that have been provided until you have verified > them. This is basically what happens with a Redirect; and it is done through Neighbor Discovery. > And there are a whole host of slight differences in semantics that > you have to handle very carefully. This is what I seriously dislike... I've tried all along to stay within the existing protocols as much as possible, with the only diversion being the source LLaddr suggested in the Rtr Adv. > And ultimately you have what is effectively a whole new protocol. This might be a bit over the edge, I fear ;-) and you say you agree. On Tue, Jul 03, 2012 at 06:33:49PM -0700, Eric W. Biederman wrote: > > I have started playing the idea of encoding the ICE offer/answer > exchange as an STUN message and then I can let ICE/STUN take care > of trying different paths and finding one that works, and agreeing > on a common route. Interesting! > However I do think this is a fun way to experiment with ICE and a very > interesting way of coping with implementing NAT traversal outside > end applications, so I am going to keep playing with this as time > permits. So far except for tunnel setup speeds this looks very > promising, and the least NIH that I have found. Meanwhile, my line will be to provide a working tunnel based on what I already have. Delivering is more important to me, so I will be a bit more conservative. As stated above, several of your suggestions are directly usable, but not all are. I want to thank you for all of them, and made quite a few notes for further processing; I am interested in hearing what you will cook up! Once again, my apologies for the slow response. I'm afraid 6bed4 is only one of my activities... no surprise there, I suppose ;-) Cheers, -Rick |
|
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-04 01:34:02
|
There are a lot of scenarios other that Ipv6 transitions that involve Point to Point tunnels in a mesh over a Non-Broadcast Multi-Access network. VPN and the like. In those tunnels you can work very hard to achieve multicast and broadcast parity with existing ipv6 links or you can take the line that you simply have a lot of point to point connections that give you connectivity, and you have the ability to create a new point to point connection at need. In the startup configuration of these kinds of networks you bootstrap with a tunnel to some well known central point so you have connectivity. Then you create tunnels to other endpoints on demand. I have started playing the idea of encoding the ICE offer/answer exchange as an STUN message and then I can let ICE/STUN take care of trying different paths and finding one that works, and agreeing on a common route. It looks like a general approach that is going to be simple and easy to implement. I don't know if it is going to be really useful in the 6bed4 design scenario. Having to throttle hole punching to 20ms or slower looks like it is going to be a real drag on tunnel creation speed and my hunch is that most transitive internet connections will be over before a tunnel can be established. However I do think this is a fun way to experiment with ICE and a very interesting way of coping with implementing NAT traversal outside end applications, so I am going to keep playing with this as time permits. So far except for tunnel setup speeds this looks very promising, and the least NIH that I have found. Eric |
|
From: <ebi...@xm...> - 2012-07-04 01:11:54
|
So I took a good hard look at what it would take to get ICMPv6 relatively safe and have the property that it worked reasonably well over the NATed internet. You have to add support for multiple source and destination addresses. You have to require support for nonces, and use them to prevent problems with source address spoofing. You have to change the semantics so that you don't trust source and destination addresses that have been provided until you have verified them. And there are a whole host of slight differences in semantics that you have to handle very carefully. And ultimately you have what is effectively a whole new protocol. If ipv6 was likely to run over networks with these perverse characteristics on a regular basis it would be worth specifying the necessary extensions. As IPv6 is mostly likely to run over ethernet links and other similar links that have similar properties I just don't think it makes sense to upgrade Neighbor Discovery to the extent it is barely recognizable. Instead something simpler should be implemented. Eric |
|
From: <ebi...@xm...> - 2012-07-04 00:45:58
|
I took a quick look and the complexity of stateless nat64 looks to be about 1000 lines of code or about the same as your original 6bed4 tunnel that did not directly attempt to connect peer endpoints. See http://www.litech.org/tayga/ I think with just a little care by mapping all of the v4 addresses into the ipv4 compatible addresses aka ::ffff:0:0/96 you can use only ipv6 addresses and apis and still talk over the ipv4 network with no noticabley code size difference as compared to 6bed4. This does indicate that you would need to implement ICE aka RFC5245 in your VOIP clients but RFC5245 is required for proper IPv6 support anyway, and the implementation if not the specification is pretty simple. Eric |
|
From: <ebi...@xm...> - 2012-07-04 00:30:34
|
Reading through RFC 5245 Interactive Connectivity Establishment I came across a nasty observation. In some NATs you can not create a new hole faster than once ever 20ms. Which makes NAT holepunching something that has to be done a lot more carefully than I would have guessed. Eric |
|
From: <ebi...@xm...> - 2012-07-04 00:27:20
|
There are two issues that using anycast addresses can trigger that both impact debugging, and until I had those two issue conflated. - Anycast addresses are a good way to trigger assymetric routing. - Anycast addresses hide which machine is the router in your path. Assymetric routes can happen with ipv4 and they are a pain, because getting a reverse traceroute requires tracing from the other side. Having multiple routers at very different places in the network operated by different people report the same address in traceroute makes figuring out who to blame for slow traffic a real challenge. So I suggest adding: "ICMP time exceeded errors MUST NOT be reported with a 6bed4 address." to make it possible to figure out whose 6bed4 router is malfunctioning. Eric |