Re: [6bed4-devel] Comments and thoughts on bed64

[Timothy B. <tim...@fa...>]

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.