> -----邮件原件----- > 发件人: 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? > 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
