HI Woj, Thanks for that. So we actually aren't too far apart. There needs to be a DMR (or equivalent) that has the IPv6 address of the BR.
But, this is one thing that's been confusing me since the publication of (I think v03), where the DMR is no longer described, or mentioned anywhere in the MAP base draft. However it does still exist in the MAP DHCP option draft. But neither of the drafts actually describes what it is and how to use it. The current map 05 draft only discusses the use of an IPv4 route, which I think is misleading – the IPv6 address of the BR is also needed (as Ole's pointed out in his mail). A DMR, or something functionally equivalent is necessary, but this is not just an IPv4 route. It has to have the v6 address of the BR, used to build a tunnel. The v4 route points then to that tunnel. So, the reason that I said it's incompatible is that the current text in the MAP base draft doesn't describe any way of getting the v6 address of the BR other than those that can be provided with a BMR and FMRs. I.e. An IPv4 default route with an IPv4 next hop which is in a map domain which the CPE has an FMR for. lw4o6, which doesn't use mapping rules cannot calculate the v6 address of the concentrator from a v4 next hop address. I realise that this is not how it is meant to work (and you've confirmed that), but this is the only way that you could make it work given the text that is actually in the draft and that's what I think needs to be changed. This would bring the MAP/lw4o6 & unified CPE drafts back in line… … then we can have the discussion about what the best DHCP mechanism to provision the client with the v6 address of the concentrator is :-) Cheers, Ian From: Wojciech Dec <[email protected]<mailto:[email protected]>> Date: Tuesday, 9 April 2013 18:46 To: Ian Farrer <[email protected]<mailto:[email protected]>> Cc: Suresh Krishnan <[email protected]<mailto:[email protected]>>, Softwires-wg <[email protected]<mailto:[email protected]>>, Yong Cui <[email protected]<mailto:[email protected]>>, Ralph Droms <[email protected]<mailto:[email protected]>> Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-05 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]<mailto:[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]<mailto:[email protected]>> Date: Tuesday, 9 April 2013 13:09 To: Ian Farrer <[email protected]<mailto:[email protected]>> Cc: Suresh Krishnan <[email protected]<mailto:[email protected]>>, Softwires-wg <[email protected]<mailto:[email protected]>>, Yong Cui <[email protected]<mailto:[email protected]>>, Ralph Droms <[email protected]<mailto:[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]<mailto:[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]> [mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
