On Thu, Oct 07, 2010 at 10:06:33AM +0200, mohamed.boucad...@orange-ftgroup.com wrote: > FWIW, one of the deployment use cases we are considering is the distribution > of the DS-Lite serviced customers among several (geo distributed) AFTRs by > combining the search domain name dhcpv6 option (Code 24) and a generic FQDN > conveyed in the AFTR name option. This would allow for a more controlled > load distribution among deployed AFTRs.
In this case, your AFTR FQDN option would no longer be an FQDN. The use of the domain search option to locate a not-fully-qualified AFTR endpoint is not defined. I would be surprised if this behavior was general. But it also sounds like you don't intend on configuration the AFTR IP address option? This then does not comply with the earlier versions of the draft; you would be locking out clients that do not implement the NAME option. In order to allow clients to implement to minimum requirements, servers are required to implement (and in operation, offer) the IP address...clients are only required to implement the address option. Furthermore, if you have the DHCPv6 server infrastructure to deliver different search paths to clients based upon geo-location, why do you lack the DHCPv6 server infrastructure to deliver different AFTR endpoints by IP address? Surely these are identical problems? I suspect you could simply configure the AFTR endpoint location in the DHCPv6 server by using a domain name, next to the adjusted search path you wish to advertise. -- David W. Hankins BIND 10 needs more DHCP voices. Software Engineer There just aren't enough in our heads. Internet Systems Consortium, Inc. http://bind10.isc.org/
pgp3jdyj0y2Um.pgp
Description: PGP signature
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
