|
Mark Townsley wrote: "Is this a wan interface IPv6 address, or a lan-side delegated prefix? And, might we want both? Even a third that might be the management IPv6 address assigned to a loopback? If the scope is far less here, that's fine with me, but in principle I can imagine a BNG wanting to serve up (via DHCPv6 or PPP) or be aware of (for running BFD or whatever kind of thing the BNG might want to do with an RG) more than just one IPv6 address." I think this is one of the issues that has confused members of the WG who have attempted to review the document. Overall, the usage model underlying the document is unclear and this could potentially result in interoperability problems. For example, are we talking about prefix delegation, then presumably we are looking to utilize the attributes defined in RFC 4818. If we are not talking about prefix delegation, then are we utilizing the address assignment model of PPP IPv6CP or DHCPv6? If it is IPv6CP, then it would not seem to make sense for the IPv6-Address in question to be that of the client interface, since that is already determined by the attributes defined in RFC 3162 (Framed-IPv6-Prefix and Framed-Interface-Id). If we are utilizing the address assignment model of DHCPv6, then is the NAS acting as a DHCPv6 server? Since RADIUS is spoken between a NAS and a RADIUS server, if the DHCPv6 server does not reside on the NAS, then this raises questions about what entities are involved in the RADIUS protocol conversation, and whether authentication (or a Call Check) is taking place. Outlining the specific scenarios that under consideration and the requirements for a solution would help greatly in promoting progress on this document. |