Hi Xiaohu, 

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Xu Xiaohu
> Sent: Thursday, March 17, 2011 7:04 PM
> To: Templin, Fred L; [email protected]
> Cc: [email protected]
> Subject: Re: [Softwires] fwd: New 
> VersionNotificationfordraft-guo-softwire-6rd-ipv6-config-02
> 
> 
> > -----邮件原件-----
> > 发件人: Templin, Fred L [mailto:[email protected]]
> > 发送时间: 2011年3月18日 1:14
> > 收件人: Xu Xiaohu; [email protected]
> > 抄送: [email protected]
> > 主题: RE: [Softwires] fwd: New Version
> > Notificationfordraft-guo-softwire-6rd-ipv6-config-02
> > 
> > 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.
> 
> Hi Fred,
> 
> Thanks for this information. I will read your draft.
> 
> > 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.
> 
> 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?

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
[email protected]

> > 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.
> 
> 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
> 
> > Thanks - Fred
> > [email protected]
> > 
> > > -----Original Message-----
> > > From: [email protected]
> > > [mailto:[email protected]] On Behalf Of Xu Xiaohu
> > > Sent: Tuesday, March 15, 2011 7:12 PM
> > > To: [email protected]
> > > Cc: [email protected]
> > > Subject: [Softwires] fwd: New Version Notification
> > > fordraft-guo-softwire-6rd-ipv6-config-02
> > >
> > > 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 protected]]
> > > 发送时间: 2011年3月14日 17:45
> > > 收件人: [email protected]
> > > 抄送: [email protected]; [email protected]; [email protected]
> > > 主题: 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.
> > >
> > >
> > > _______________________________________________
> > > Softwires mailing list
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/softwires
> > >
> 
> _______________________________________________
> Softwires mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/softwires
> 
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to