Hi Mikael, Our I-D.sun-softwire-lw4over6-dhcpv6-00 is trying to solve it in this way, using a separate dhcpv6 option to request the FQDN of lwAFTR. So that the dhcpv6 server can tell whether it is a lw4over6 client or a ds-lite client.
Best wishes Qiong On Tue, Jul 30, 2013 at 7:17 PM, Mikael Abrahamsson <[email protected]>wrote: > On Tue, 30 Jul 2013, Simon Perreault wrote: > > I see three options: >> >> If OPTION_MAP_BIND doesn't exist: >> >> Option 1: Send OPTION_S46_BRULE with EA-length = 0. But you don't get to >> benefit from meshing if you support it. >> >> Option 2: Send *two* OPTION_S46_BRULE, one with EA-length=0, and another >> with EA-length=N. You get to benefit from meshing, but then we need to >> specify how CPEs are to handle multiple BRULEs. >> >> If OPTION_MAP_BIND exists: >> >> Option 3: Send OPTION_S46_BRULE with EA-length=N and OPTION_MAP_BIND. >> >> The current consensus, as I understand it, is for option 3. >> > > So, I had some discussion regarding this over lunch, and I now think i > have some more insight. > > So, I have a few problems with the current way this is supposed to be > implemented. I would like to be able to support multiple transition > mechanisms using a static dhcp server configuration file. For instance: > > If I add option 212 to DHCP server config and the client wants a 6RD > relay, I give a static answer. If it wants something else, I have a static > answer for it, tftp server, whatever. If it's not in the config file, I > have no answer. Completely stateless and static, no logic needed. > > I would like to see DHCPv6 work the same way for this, regarding AFTRs. I > would like to see separate AFTR requests for different types of AFTRs. > Basically, the AFTR DHCP option should reflect what kind of AFTR is being > handed out. I don't want to have a single AFTR handle all protocols (not in > DHCP, not in real life), and I don't want magic depending on certain bits > in the answer to find out what kind of AFTR should be handed out. > > Why can't we have the client ask for lw4over6 if it wants it, and ask for > MAP-E or MAP-T or whatever it wants, instead of the DHCPv6 server trying to > figure out through logic what the client might be asking for? Of course, > people can implement logic if they want to (if client supports MAP-E, > lw4over6 and $NEWFOO, just give it pw4over6), otherwise just answer with > all things that is supported in the network. I would probably be good if > there was some kind of preference figure in there as well with the options, > so that the ISP can indicate preference to what mechanism should be used if > there are multiple doing basically the same thing. > > This would (I think) address what Ted Lemon was saying that the current > logic requirements is complicating the DHCPv6 server because it needs to > have intelligence to figure out what response to give depending on what > options are being asked for. Now it's possible to give out multiple answers > at the same time if the client asks for it. > > > -- > Mikael Abrahamsson email: [email protected] > ______________________________**_________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/**listinfo/softwires<https://www.ietf.org/mailman/listinfo/softwires> > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * ===============================================
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
