Hi Ian, sure. In the current MAP the BR gets configured via the DMR (as an IP address) - http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-01#section-4.3 That's not set in stone, but it's a reasonable way of doing things. A name could be another equivalent way.
Note: The working of this, incl DHCPv6, has been verified in trials also with the 1:1 mode and hooking up to a DS-lite AFTR, and an issue of compatibility, which you're voicing a concern about, hasn't come up. Regards, Woj. On 9 April 2013 17:59, <[email protected]> wrote: > Hi Woj, > > 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. > > Thanks, > Ian > > 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
