Ian, > To (hopefully) prevent a long, cross purpose discussion, could you describe > how you see that the BR address should be configured for MAP 1:1? It's > described as a possible use case in the appendix, but it only covers how to > provision the client, not how it learns the BR.
what I meant by an IPv4 default route was something like: 0.0.0.0/0, Tunnel0, 2001:db8::1 i.e. the BR IPv6 address as next-hop. is that OK? (the alternative would be an IPV4 address, which would force the BR to have an address within the MAP domain). cheers, Ole > From: Wojciech Dec <[email protected]> > Date: Tuesday, 9 April 2013 13:09 > To: Ian Farrer <[email protected]> > Cc: Suresh Krishnan <[email protected]>, Softwires-wg > <[email protected]>, Yong Cui <[email protected]>, Ralph Droms > <[email protected]> > Subject: Re: [Softwires] Working group last call for > draft-ietf-softwire-map-05 > > Hi Ian, > > a default route appears to be by far the best way to model the reachability > of destinations outside of the MAP domain, and actually *any* IP domain (i.e. > this is not a MAP specific aspect). > > > On 5 April 2013 21:03, <[email protected]> wrote: >> Hi, >> >> I have one comment about the current version: It is using an IPv4 default >> route as the method for sending traffic out of the MAP domain. This is >> likely to cause provisioning complexity and conflicts with two other related >> drafts: >> >> 1, The unified CPE draft is looking for the presence of a configured BR/AFTR >> v6 address as the mechanism for whether to configure 'binding mode' (i.e. >> MAP 1:1 in this case). A v4 default route isn't easily compatible with this. > > Could you elaborate on what incompatibility you see? > This is a case of an implicit default route (much as is also the norm in say > PPP connections). > >> >> 2, For DHCP based provisioning, the updated OPTION_MAP (described in the >> unified CPE draft) + RFC6334 give a method for configuring basic softwire >> functionality using just a DHCPv6 server. This doesn't provide any way of >> distributing IPv4 default routes. Therefore, to provision a MAP 1:1 client, >> you would need to deploy the DHCPv4 over DHCPv6 infrastructure just for this >> single DCHPv4 option. This is, of course assuming that the DHCPv4 over >> DHCPv6 method (draft-scskf-dhc-dhcpv4-over-dhcpv6) is the agreed mechanism >> for v4 over v6 provisioning. > > This appears back to front. RFC6334 is naturally the DS-lite AFTR option, and > an AFTR does not equal a BR, (nor a Lw46 gateway). I believe that that the > use of rfc6334 is unnecessary, and the unified CPE does not need to depend on > it, esp given that it will need additional options anyway. In short, it makes > little sense for a unified CPE to use both rfc6334 + some new option. > >> >> I raised this point in Orlando (See Ole's comment on using RFC6334 as the >> DMR in the minutes). I think that this change would fix the two points above. > > IMO The unified CPE notion needs to be fixed (and it is something I have > commented on previously): It's not unification by dumping all the existing > stuff together, but a) a functional rationalization (all solution share the > same functions) and b) a unified configuration method (which likely excludes > things like rfc6334, given its applicability to only one solution) > > Regards, > Woj. >> >> Thanks, >> Ian >> >> >> >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On >> Behalf Of Suresh Krishnan >> Sent: Dienstag, 26. März 2013 05:23 >> To: Softwires WG >> Cc: Yong Cui; Ralph Droms >> Subject: [Softwires] Working group last call for draft-ietf-softwire-map-05 >> >> Hi all, >> This message starts a two week softwire working group last call on >> advancing the draft about providing Mapping of Address and Port with >> Encapsulation as a Standards Track RFC. The authors believe that this >> version has addressed all the issues raised on the document. The latest >> version of the draft is available at >> >> http://www.ietf.org/id/draft-ietf-softwire-map-05.txt >> http://tools.ietf.org/html/draft-ietf-softwire-map-05 >> >> Substantive comments and statements of support/opposition for advancing this >> document should be directed to the mailing list. Editorial suggestions can >> be sent directly to the authors. The chairs will send in their comments as >> well during the last call period. This last call will conclude on April 9, >> 2013. >> >> Regards, >> Suresh & Yong >> _______________________________________________ >> 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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
