is source address binding more valuable for IPv6?

>>>>> Pascal Hambourg <pascal.mail.DeleteThis@plouf.fr.eu.org> writes:

IS> Do I understand it correctly, that the 6to4 and Teredo tunneling
IS> transition mechanisms work by establishing ``implicit'' tunnels,

PH> Yes, you can say that.

IS> and, thus, are subject to the already existing IPv4 routing,

PH> The tunneling packets are.

IS> while 6in4 routes the packets via the chosen IPv6 provider?

PH> 6in4 is just the encapsulation method (protocol 41) used by 6to4,
PH> and one of the encapsulation methods used by some IPv6 tunnel
PH> brokers (which are what you call "IPv6 providers" I guess).

Yes, thanks for the clarification. I've meant specifically the
latter.

IS> Thus, it seems sensible for a single host to always implement
IS> Teredo or 6to4, even if as an addition to 6in4, in order to utilize
IS> the existing IPv4 routing. (Consider, e. g., two friends with
IS> hosts connected to the network of some IPv4 provider; the use of
IS> 6in4 implies that the traffic will be routed via yet another,
IS> possibly distant, IPv6, provider, while with either Teredo or 6to4,
IS> the packets will be routed directly via the IPv4 provider's
IS> network, resulting in lower latency, bandwidth consumption, etc.)

PH> IPv4 routing between two hosts may not be straightforward either.

Indeed. But then it'll be the thing that ``the customers'' have
to live with.

IS> May it therefore make sense for all the IPv6-compatible network
IS> software to support source IPv6 binding?

PH> Not more than for a classic multihomed IPv4 host, IMO.

Yes. However, since of the above, it seems to me that IPv6
multihoming may be somewhat more useful. (Please forgive me if
my thoughts aren't quite clear at this time.)

As an example, please consider a home network that uses both
6to4 addresses (to utilize the IPv4 routing) /and/ the addresses
obtained thanks to a tunnel broker (to be independent of the
IPv4 address, especially if it isn't static; or since there may
ocassionally be IPv6-networks lacking both 6to4 routing and IPv4
connectivity whatsoever.)

PS. My colleges are surprisingly eager to learn IPv6:

http://theory.asu.ru/~ivan/ipv6-test1/

--
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-ipv6-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

I'm less familiar with Teredo, but there is a 6to4 scenario where an
IPv4-based 6to4 host wants to access a native IPv6 host. In this
scenario, the two hosts must communicate via a 6to4 "relay" that handles
encapsulation/unencapsulation between 6to4 encapsulated IPv6 and native
IPv6. Dependent upon on how "close" routing-wise the 6to4 relay is both
hosts, it is possible for the routes taken between the two hosts to be
very inoptimal and asymmetric.

If both end-points are IPv4 hosts with 6to4 encapsulated IPv6, then yes,
the route taken can be as optimal as the IPv4 route.

Bill Cerveny

On Thu, 20 Aug 2009 12:34 +0200, "Pascal Hambourg"
<pascal.mail RemoveThis @plouf.fr.eu.org> wrote:
> Hello,
>
> Ivan Shmakov a écrit :
> > Do I understand it correctly, that the 6to4 and Teredo tunneling
> > transition mechanisms work by establishing ``implicit'' tunnels,
>
> Yes, you can say that.
>
> > and, thus, are subject to the already existing IPv4 routing,
>
> The tunneling packets are.
>
> > while 6in4 routes the packets via the chosen IPv6 provider?
>
> 6in4 is just the encapsulation method (protocol 41) used by 6to4, and
> one of the encapsulation methods used by some IPv6 tunnel brokers (which
> are what you call "IPv6 providers" I guess).
>
> > Thus, it seems sensible for a single host to always implement
> > Teredo or 6to4, even if as an addition to 6in4, in order to
> > utilize the existing IPv4 routing. (Consider, e. g., two
> > friends with hosts connected to the network of some IPv4
> > provider; the use of 6in4 implies that the traffic will be
> > routed via yet another, possibly distant, IPv6, provider, while
> > with either Teredo or 6to4, the packets will be routed directly
> > via the IPv4 provider's network, resulting in lower latency,
> > bandwidth consumption, etc.)
>
> IPv4 routing between two hosts may not be straightforward either.
>
> > May it therefore make sense for all the IPv6-compatible network
> > software to support source IPv6 binding?
>
> Not more than for a classic multihomed IPv4 host, IMO.
>
>
> --
> To UNSUBSCRIBE, email to debian-ipv6-REQUEST RemoveThis @lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster RemoveThis @lists.debian.org
>


--
To UNSUBSCRIBE, email to debian-ipv6-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

>>>>> Bill Cerveny <debian-v6 DeleteThis @21st-century-networks.com> writes:

[...]

> I'm less familiar with Teredo,

IIUC, the same considerations apply to Teredo as well.

> but there is a 6to4 scenario where an IPv4-based 6to4 host wants to
> access a native IPv6 host. In this scenario, the two hosts must
> communicate via a 6to4 "relay" that handles
> encapsulation/unencapsulation between 6to4 encapsulated IPv6 and
> native IPv6.

Actually, the 6to4 to IPv6 route and the reverse one may be
different. See below.

> Dependent upon on how "close" routing-wise the 6to4 relay is both
> hosts, it is possible for the routes taken between the two hosts to
> be very inoptimal and asymmetric.

So, it may be beneficial for the IPv4 + IPv6 gateways to always
be configured for 6to4. With the route having a more specific
prefix (/16) than that to the IPv6 provider (tunnel broker; /3),
it will take precedence over the native IPv6 route for 6to4
destinations. (The implied 6to4 network doesn't have to be
used, except for the gateway, of course.)

When routing the packets the other way (6to4 to native IPv6),
only the explicit routing will help, though.

> If both end-points are IPv4 hosts with 6to4 encapsulated IPv6, then
> yes, the route taken can be as optimal as the IPv4 route.

Or both of the routes, to be precise.

--
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-ipv6-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

> I'm less familiar with Teredo,

Teredo has a mechanism for optimising traffic to double-stack hosts.
You can set up a ``host-specific relay'', essentially an unnumbered
Teredo interface. Traffic to Teredo hosts will be routed as Teredo
packets (UDPv4), with no need to have a local Teredo address.

With miredo, just say

RelayType cone

in your /etc/miredo.conf. If you're behind a NAT, you may need to say

RelayType restricted

instead.

Juliusz


--
To UNSUBSCRIBE, email to debian-ipv6-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

>>>>> "JC" == Juliusz Chroboczek <jch.DeleteThis@pps.jussieu.fr> writes:

BC> I'm less familiar with Teredo,

JC> Teredo has a mechanism for optimising traffic to double-stack
JC> hosts. You can set up a ``host-specific relay'', essentially an
JC> unnumbered Teredo interface. Traffic to Teredo hosts will be
JC> routed as Teredo packets (UDPv4), with no need to have a local
JC> Teredo address.

JC> With miredo, just say

JC> RelayType cone

JC> in your /etc/miredo.conf. If you're behind a NAT, you may need to
JC> say

JC> RelayType restricted

BTW, miredo.conf(5) discourages the use of such a mode:

--cut: miredo.conf(5) --
restricted mode
This mode is identical to the cone mode documented above,
with the exception that direct Teredo bubbles will be sent.
Theoretically (see RFC4380) this permits operation of a
Teredo relay from behind a restricted-port NAT. In
practice, this makes NAT traversal extremely unreliable.
This setting is present for backward syntax compatibility of
the miredo.conf file. PLEASE DO NOT USE THIS MODE.
--cut: miredo.conf(5) --

JC> instead.

However, when the traffic has to pass from one host to another
behind the very same NAT, the traffic is going to be routed via
that NAT. Unfortunately, there apparently are some NATs which
don't allow such a trick.

--
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-ipv6-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org