Subject: [Softwires] I-D Action:draft-ietf-softwire-ipv6-6rd-07.txt

From: [email-masked]
Date: Mon, 22 Feb 2010 11:45:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Softwires Working Group of the IETF.

	Title           : IPv6 via IPv4 Service Provider Networks "6rd"
	Author(s)       : M. Townsley, O. Troan
	Filename        : draft-ietf-softwire-ipv6-6rd-07.txt
	Pages           : 18
	Date            : 2010-02-22

This document specifies an automatic tunneling mechanism tailored to
advance deployment of IPv6 to end users via a Service Provider's IPv4
network infrastructure.  Key aspects include automatic IPv6 prefix
delegation to sites, stateless operation, simple provisioning, and
service which is equivalent to native IPv6 at the sites which are
served by the mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-softwire-ipv6-6rd-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 22 Feb 2010 18:56:05 -0500

Hello,

I would be interested to know how traceroute from an IPv4 and IPV6 hosts
behind a CPE would work on 6rd in general and specifically with IPv4/IPv6
anycast addresses. I would be interested on actual details on source
addresses used for answers, what happens if different answers for the same
TTL traverse different BRs coming back based on the stateless nature, etc.

If there is an impact on the current way a client and an admin interprets
results, that should be documented.

Not sure if this was already discussed on the list. Given the widespread use
of traceroute as a diagnostic tool shouldn't at least some of these details
be covered on the draft?

In ds-lite there is a little discussion on that but given the stateful
nature of NAT that would be a different topic.

Regards,

Reinaldo

---

From: Ole Troan <[email-masked]>
Date: Tue, 23 Feb 2010 02:07:17 +0100

Reinaldo,

> nature of NAT that would be a different topic.

I can't think of anything which would affect traceroute. 6rd of course only affects IPv6 traceroute.
with multiple BRs it will appear like you have multiple output paths as well as inbound paths. so you may get asymmetric traffic, that's of course not uncommon. the access network will look like a single hop across the 6rd domain. the IPv6 SA that the BR uses will be a normal IPv6 unicast address.

we've recommended that the IPv6 subnet router anycast address is supported, but I wouldn't expect that one to be used as an SA.

to summarize, I don't think there is any impact here.

cheers,
Ole

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 22 Feb 2010 21:33:41 -0500

On 2/22/10 5:07 PM, "Ole Troan" <[email-masked]> wrote:

> with multiple BRs it will appear like you have multiple output paths as well
> as inbound paths. so you may get asymmetric traffic, that's of course not
> uncommon. 

Ole,

Thanks for the answer. There seems to be some differences here that you can
help clarify in the context of anycast.

These questions are based on the following from the draft (and section
around it) that in my reading advances an idea of fully stateless
deployment.

"As 6rd is stateless, any BR may be used at any time. "

In 6rd although one can use anycast, there is a need for the IGP to be
stable, correct? It cannot be fully stateless otherwise different packets
for the same (source, destination, protocol) tuple would use different BRs.
Traceroute packets with the same TTL, source and destination taking
different paths would be a subset of a more general problem.

But in general what are the anycast affinity requirements for such a
deployable solution? But more specifically when connection based protocols
like TCP that react to delay are used on top of it.

I'm familiar with the use of anycasting for DNS where request and responses
are idempotent, short-lived and over a connectionless protocol, therefore
not much an issue. 

And also use of TCP anycast as in this presentation
http://www.nanog.org/meetings/nanog37/presentations/matt.levine.pdf where
there are discussions on use and stability requirements.

Thanks,

Reinaldo

> the access network will look like a single hop across the 6rd
> domain. the IPv6 SA that the BR uses will be a normal IPv6 unicast address.
> 
> we've recommended that the IPv6 subnet router anycast address is supported,
> but I wouldn't expect that one to be used as an SA.
>

---

From: Ole Troan <[email-masked]>
Date: Tue, 23 Feb 2010 12:53:39 +0100

Reinaldo,

[...]

> different paths would be a subset of a more general problem.

the IGP does not need to be stable. just like in a 'native' IP network you prefer that packets for the same flow follow the same path. when that doesn't happen, e.g because of link failure or IGP instability then the behaviour of 6rd packets will be just like the native IPv4 packets. the same thing happens if you withdraw the anycast route on BR failure. 

> like TCP that react to delay are used on top of it.

there are of course operational issues here. and I would certainly not recommend load-balancing between BR's which are on different continents for example.

> there are discussions on use and stability requirements.

right, but that's for using an anycast address as a endpoint for a TCP session. here we only use anycast as a next-hop.

this is not Internet-wide anycast like e.g 6to4 uses. this is all intended to be contained within an SP. where you also have tight control over the anycast advertisements in the IGP. not that I don't think this would also work in an Internet context, but then we're back to 6to4 with all its issues.

cheers,
Ole

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 23 Feb 2010 13:36:41 -0500

Thanks for the answers.

On 2/23/10 3:53 AM, "Ole Troan" <[email-masked]> wrote:

> the IGP does not need to be stable. just like in a 'native' IP network you
> prefer that packets for the same flow follow the same path. when that doesn't
> happen, e.g because of link failure or IGP instability then the behaviour of
> 6rd packets will be just like the native IPv4 packets. the same thing happens
> if you withdraw the anycast route on BR failure.
> 
> there are of course operational issues here. and I would certainly not
> recommend load-balancing between BR's which are on different continents for
> example.
> 
> right, but that's for using an anycast address as a endpoint for a TCP
> session. here we only use anycast as a next-hop.
> 
> this is not Internet-wide anycast like e.g 6to4 uses. this is all intended to
> be contained within an SP. where you also have tight control over the anycast
> advertisements in the IGP. not that I don't think this would also work in an
> Internet context, but then we're back to 6to4 with all its issues.
> 
> cheers,
> Ole
>