Subject: [Softwires] fwd: New Version Notification for draft-guo-softwire-6rd-ipv6-config-02

From: Xu Xiaohu <[email-masked]>
Date: Wed, 16 Mar 2011 10:12:19 +0800

Hi all,

An updated version of draft-guo-softwire-6rd-ipv6-config is available at
http://tools.ietf.org/html/draft-guo-softwire-6rd-ipv6-config-02.

Abstract:
The 6rd [RFC5969] linktype does not support IPv6 link-local
addressing, multicast and 6rd nodes are off-link from each other.
The host configuration protocol DHCPv6 [RFC3315] relies on link-local
addressing and multicast to function.  This document specifies how
DHCPv6 can be used across a 6rd link.

Any comments are welcome.

Best wishes,
Xiaohu

-----邮件原件-----
发件人: IETF I-D Submission Tool [mailto:[email-masked]] 
发送时间: 2011年3月14日 17:45
收件人: [email-masked]
抄送: [email-masked]; [email-masked]; [email-masked]
主题: New Version Notification for draft-guo-softwire-6rd-ipv6-config-02

A new version of I-D, draft-guo-softwire-6rd-ipv6-config-02.txt has been
successfully submitted by Ole Troan and posted to the IETF repository.

Filename:	 draft-guo-softwire-6rd-ipv6-config
Revision:	 02
Title:		 IPv6 Host Configuration in 6rd
Creation_date:	 2011-03-14
WG ID:		 Independent Submission
Number_of_pages: 5

Abstract:
The 6rd [RFC5969] linktype does not support IPv6 link-local
addressing, multicast and 6rd nodes are off-link from each other.
The host configuration protocol DHCPv6 [RFC3315] relies on link-local
addressing and multicast to function.  This document specifies how
DHCPv6 can be used across a 6rd link.

The IETF Secretariat.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Mar 2011 10:14:12 -0700

Hi Xiaohu,

I'm just seeing this draft for the first time, and I noticed that it is asking
the CE router to act as a combined DHCP client/relay. Sections 4.1 and
4.2.3.1 of the VET spec provide a detailed description of how to do that,
and the same considerations apply to what you are trying to accomplish.

When you start dealing with DHCPv6-allocated addresses and prefixes,
however, you also have to consider how that will interact with the IPv6
routing system. For that, your CEs would either have to engage in a
proactive dynamic IPv6 routing protocol (e.g., RIPng, OSPFv3, etc.)
or somehow discover more-specific IPv6 routes on-demand of data traffic.
Section 5.14 of the VET spec specifies a new on-demand dynamic IPv6
routing protocol based on redirection that applies to ISATAP and VET,
but I think would also apply equally to your use case.

One question about your draft. If the CE acting as a combined client/relay
forwards a DHCP request to 6rd BR A (via the 6rd anycast address), what
happens if subsequent DHCP renwals are directed to 6rd BR B? I don't
think it is disasterous as long as the BR's communicate with each other,
but you might want to say that somewhere.

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Xu Xiaohu
> Sent: Tuesday, March 15, 2011 7:12 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Softwires] fwd: New Version Notification 
> fordraft-guo-softwire-6rd-ipv6-config-02
> 
> Hi all,
> 
> A new version of I-D, 
> draft-guo-softwire-6rd-ipv6-config-02.txt has been
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 18 Mar 2011 10:03:47 +0800

> -----邮件原件-----
> 发件人: Templin, Fred L [mailto:[email-masked]]
> 发送时间: 2011年3月18日 1:14
> 收件人: Xu Xiaohu; [email-masked]
> 抄送: [email-masked]
> 主题: RE: [Softwires] fwd: New Version
> Notificationfordraft-guo-softwire-6rd-ipv6-config-02
> 
> Hi Xiaohu,
> 

Hi Fred,

Thanks for this information. I will read your draft.

> but I think would also apply equally to your use case.

This draft (draft-guo-softwire-6rd-ipv6-config-02) only discusses about how
to support stateless DHCPv6 service in 6rd scenario. Hence, IMHO, a
proactive dynamic IPv6 routing protocol is not needed. Did I misunderstand
your point? 

> but you might want to say that somewhere.

Since only the stateless DHCPv6 service is now considered in this draft, the
synchronization among BRs is not required. Would this usage cause any
concern?

Best wishes,
Xiaohu

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 18 Mar 2011 08:17:27 -0700

Hi Xiaohu, 

> Sent: Thursday, March 17, 2011 7:04 PM
> To: Templin, Fred L; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Softwires] fwd: New 
> VersionNotificationfordraft-guo-softwire-6rd-ipv6-config-02
> 
> 
> > -----邮件原件-----
> > I'm just seeing this draft for the first time, and I 
> noticed that it is
> asking

Oh, I may have read too fast; I see now that you are only asking
about stateless at the current time. But, why not also do stateful
DHCPv6 prefix delegation (and maybe also stateful DHCPv6 address
configuration)? A 6rd tunnel should be able to support that the same
as for an ISATAP tunnel.

Then, 6rd end sites can use true native IPv6 prefixes instead of the
IPv4-embedded ones. Should this be added to the draft?

Thanks - Fred

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 21 Mar 2011 09:53:05 +0800

Hi Fred,

> 发送时间: 2011年3月18日 23:17
> 主题: RE: [Softwires] fwd:
> NewVersionNotificationfordraft-guo-softwire-6rd-ipv6-config-02
> 
> Hi Xiaohu,
> 

I agree that it should work. However, I wonder what's the advantage of
native IPv6 prefixes over IPv4-embeded ones?

Best wishes,
Xiaohu

---

From: Ole Troan <[email-masked]>
Date: Mon, 21 Mar 2011 09:21:59 +0100

Xiaohu, Fred,

> native IPv6 prefixes over IPv4-embeded ones?

I also agree that it should work (and should be a requirement for a solution). similar to "BGP tunnelling (aka softwire mesh), any of the automatic tunnelling mechanisms could be used as transport for "native addressed" IPv6 service (e.g. ISATAP, 6to4, 6rd, ...).

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Mon, 21 Mar 2011 14:15:16 +0100

Le 21 mars 2011 à 09:21, Ole Troan a écrit :
> ...
> any of the automatic tunnelling mechanisms could be used as transport for "native addressed" IPv6 service (e.g. ISATAP, 6to4, 6rd, ...).

Since 6to4 addresses have a transition-specific format, I don't think they can be considered as native.
(OTOH, that is legitimately that 6rd addresses can be called native because they cannot be distinguished from IPv6 addresses that are routed by ISP's without any tunnel anywhere.)

Since ISATAP only concerns IID's, an ISATAP address
- is native address if the IID is prefixed by a native /64.
- is a transition-specific address if it starts starts with the 6to4 prefix 2002::/16.

Do we agree on this more detailed analysis?

Cheers,
RD

---

From: Ole Troan <[email-masked]>
Date: Mon, 21 Mar 2011 14:30:43 +0100

Remi,

> Do we agree on this more detailed analysis?

I think we're talking about different things.

what I think Fred was suggesting was that it should be possible to delegate prefixes using DHCPv6 PD (and addresses for that matter) over various types of tunnels. the prefixes/addresses delegated/assigned would then be entirely independent of the link-layer addressing (IPv4), and purely use the automatic tunnelling mechanism for transport. similar to BGP tunnelling.

cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 21 Mar 2011 08:46:36 -0700

Hi Ole, 

> From: Ole Troan [mailto:[email-masked]] On Behalf Of 
> Ole Troan
> Sent: Monday, March 21, 2011 6:31 AM
> To: Rémi Després
> Cc: Xu Xiaohu; [email-masked]; [email-masked]; Templin, Fred L
> Subject: Re: [Softwires] [dhcwg] fwd: 
> >> any of the automatic tunnelling mechanisms could be used 
> as transport for "native addressed" IPv6 service (e.g. 
> ISATAP, 6to4, 6rd, ...).
> > 
> > 
> > Since 6to4 addresses have a transition-specific format, I 
> don't think they can be considered as native.
> > (OTOH, that is legitimately that 6rd addresses can be 
> called native because they cannot be distinguished from IPv6 
> addresses that are routed by ISP's without any tunnel anywhere.)
> > 
> what I think Fred was suggesting was that it should be 
> possible to delegate prefixes using DHCPv6 PD (and addresses 
> for that matter) over various types of tunnels. the 
> prefixes/addresses delegated/assigned would then be entirely 
> independent of the link-layer addressing (IPv4), and purely 
> use the automatic tunnelling mechanism for transport.

Right; in that case, the IPv4-embedded IPv6 addresses
are used as next-hop addresses in forwarding table
entries only, and rarely get used as source/destination
addresses of packets sent over the wire.

Returning to Xiaohu's question, there are several
advantages to using non-IPv4-embedded native IPv6
prefixes:

1) native IPv6 prefixes that do not include an IPv4
   embedded address can remain in service even if the
   CE's WAN interface IPv4 address changes.
2) no ISP-interior IPv4 addresses are exposed to the
   outside world.
3) there would be more stability in name-to-address
   resolution databases (e.g., the global DNS).
4) there would less incidence of site renumbering,
   since the CE could always request and receive the
   same (set of) native IPv6 prefixes.
5) multi-addressing is possible if the CE wants to
   request multiple IPv6 prefixes.

> similar to BGP tunnelling.

I don't really know anything about this. Does it do
IPv6 prefix delegation and route optimization?

Thanks - Fred

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 22 Mar 2011 15:08:44 +0800

> 发送时间: 2011年3月21日 23:47
> 收件人: Ole Troan; Rémi Després
> 抄送: Xu Xiaohu; [email-masked]; [email-masked]
> 主题: RE: [Softwires] [dhcwg]
> fwd:NewVersionNotificationfordraft-guo-softwire-6rd-ipv6-config-02
> 
> Hi Ole,
> 

Hi Fred,

Thanks for your explanation. I understand the advantages now.

In your approach, to obtain stable IPv6 prefixes for CEs, some routing
protocol should be run between the CE and the BR while the BR would have to
maintain a lot of routes for the delegated native IPv6 prefixes. Could we
attempt to assign the CE's WAN interface a stable IPv4 address to achieve
the same goal?

Best wishes,
Xiaohu

> > Ole=

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 22 Mar 2011 07:29:47 -0700

Hi Xiaohu, 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Xu Xiaohu
> Sent: Tuesday, March 22, 2011 12:09 AM
> To: Templin, Fred L; 'Ole Troan'; 'Rémi Després'
> Cc: [email-masked]; [email-masked]
> Subject: Re: [dhcwg] 
> [Softwires]fwd:NewVersionNotificationfordraft-guo-softwire-6rd
> -ipv6-config-02
> 
> 
> 
> > -----邮件原件-----
> maintain a lot of routes for the delegated native IPv6 
> prefixes.

The routing protocol in this case would be DHCPv6
prefix delegation. To spread the load, we simply
add more BRs, and make them communicate with each
other either directly in a full mesh or via a set
of gateways in a partial mesh.

> Could we

That is indeed the 6rd approach as I understand it,
and it is dependent on an IPv4 network in which IPv4 
addresses rarely if ever change and IPv4 source
address spoofing is disabled. It also requires care
so that looping based on the IPv4-embedded IPv6
prefixes is disabled. Finally it also doesn't work
in the presence of NATs, and path MTU discovery is
dependent on properly-sized links in the middle of
the network and/or ICMPs being returned by anonymous
routers in the middle of the network.

Thanks - Fred

> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 22 Mar 2011 08:05:54 -0700

Hi again Xiaohu, 

> of gateways in a partial mesh.

This might bear a few more words of explanation. By "the routing
protocol in this case would be DHCPv6 prefix delegation", what I
mean is that the BR acting as a Delegating Router should register
a "link up" event when a CE acting as a Requesting Router asks it
for a prefix delegation, and the BR should maintain that link as being
up until the CE either moves away or dies. On the backhaul network
that connects BRs, then, I am assuming something like an iBGP
instance where all BRs advertise their links that are up and withdraw
their links that have gone down.

Fred

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 23 Mar 2011 13:24:09 +0800

Hi Fred,

> 发送时间: 2011年3月22日 23:06
> 收件人: Xu Xiaohu; 'Ole Troan'; 'Rémi Després'
> 抄送: [email-masked]; [email-masked]
> 主题: RE:
> [Softwires][dhcwg]fwd:NewVersionNotificationfordraft-guo-softwire-6rd-ipv6
> -config-02
> 
> Hi again Xiaohu,
> 

Without any routing protocol, there should be some keep-alive mechanism
running between the BR and the CE at least. Otherwise, the route for the
delegated prefix could be pointed to an invalid or even a wrong next-hop (i.
e., CE). Is my understanding right?

Best wishes,
Xiaohu

> [email-masked]=

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 23 Mar 2011 08:20:51 -0700

Hi Xiaohu, 

> From: Xu Xiaohu [mailto:[email-masked]] 
> Sent: Tuesday, March 22, 2011 10:24 PM
> Subject: 
> re:[Softwires][dhcwg]fwd:NewVersionNotificationfordraft-guo-so
> ftwire-6rd-ipv6-config-02
> 
> Hi Fred,
> 
> > -----邮件原件-----

Usually, routing protocols require some form of hello
messaging to maintain link states. We could use DHCP
lease renewals for this purpose, but I wouldn't want
to set so short a lease lifetime. So, the CE could
send periodic "pings" to the BR in the data plane,
and the BR could respond back with ACKs to let th
CE know that it is stil alive.

Does this address the question?

Thanks - Fred