Hi Fred, > -----邮件原件----- > 发件人: Templin, Fred L [mailto:[email protected]] > 发送时间: 2011年3月18日 23:17 > 收件人: Xu Xiaohu; [email protected] > 抄送: [email protected] > 主题: RE: [Softwires] fwd: > NewVersionNotificationfordraft-guo-softwire-6rd-ipv6-config-02 > > 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?
I agree that it should work. However, I wonder what's the advantage of native IPv6 prefixes over IPv4-embeded ones? Best wishes, Xiaohu > > 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
