Hi Xiaohu, > -----Original Message----- > From: [email protected] [mailto:[email protected]] > 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 protected]; [email protected] > Subject: Re: [dhcwg] > [Softwires]fwd:NewVersionNotificationfordraft-guo-softwire-6rd > -ipv6-config-02 > > > > > -----邮件原件----- > > 发件人: Templin, Fred L [mailto:[email protected]] > > 发送时间: 2011年3月21日 23:47 > > 收件人: Ole Troan; Rémi Després > > 抄送: Xu Xiaohu; [email protected]; [email protected] > > 主题: RE: [Softwires] [dhcwg] > > fwd:NewVersionNotificationfordraft-guo-softwire-6rd-ipv6-config-02 > > > > Hi Ole, > > > > > -----Original Message----- > > > From: Ole Troan [mailto:[email protected]] On Behalf Of > > > Ole Troan > > > Sent: Monday, March 21, 2011 6:31 AM > > > To: Rémi Després > > > Cc: Xu Xiaohu; [email protected]; [email protected]; Templin, Fred L > > > Subject: Re: [Softwires] [dhcwg] fwd: > > > NewVersionNotificationfordraft-guo-softwire-6rd-ipv6-config-02 > > > > > > Remi, > > > > > > >> ... > > > >> 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? > > > > > > 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. > > > > 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. > > 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.
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 > attempt to assign the CE's WAN interface a stable IPv4 > address to achieve > the same goal? 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 [email protected] > Best wishes, > Xiaohu > > > > similar to BGP tunnelling. > > > > I don't really know anything about this. Does it do > > IPv6 prefix delegation and route optimization? > > > > Thanks - Fred > > [email protected] > > > > > cheers, > > > Ole= > > _______________________________________________ > dhcwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
