Xiaohu, > First, as stated in the DHCPv6 specification [RFC3315], "...The client MUST > use a link-local address assigned to the interface for which it is requesting > configuration information as the source address in the header of the IP > datagram." Since the link-local address can not travel through the 6rd > domain, the CPE SHOULD act as a DHCPv6 relay agent. I think nobody will argue > against this conclusion.
do you only need "stateless" DHCPv6? if so, I think the DHCPv6 specifications should loosen up on the restrictions of which source and destinations can be used. then you can just use a global address as a source and the IPv6 address of the BR as the relay/server. (I believe this was Townsley's proposal via IM during the softwires meeting). > Second, as I mentioned during the presentation, relaying DHCP request > messages to All_DHCP_Servers multicast address by CPEs is not optimal in 6rd > scenario. Note that here what I said is "not optimal", rather than "not > possible". The CPE as a relay agent, could be upgraded to relay > information-request DHCPv6 messages (multicast) towards the 6rd BRs. However, > with this approach, the DHCPv6 servers would have to be located in the IPv6 > Interne > t, rather than in a 6rd site which is owned by the 6rd SP. In addition, this > usage will result in more traffic burden on the 6rd BRs. I don't quite see that this has to be the case. the DHCPv6 server can obviously also be part of the SP's network. it is just placed on an "IPv6 leg" of the BR or the BR acts as the DHCPv6 server. the multicast packets could very well be encapsulated in unicast L2 (IPv4) to the BR. > > Hence, we propose that the CPE as a DHCP relay agent, SHOULD know at least > one DHCPv6 server address. of course, the other option is to just have a DNS proxy on the CPE. in any case I would like to see these requirements in the next phase of the requirements for IPv6 routers in v6ops. and I'd like to start a discussion in DHC about this as well as some other clarifications needed for CPE routers. cheers, Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
