The question asked is what is the implementation affect. I know something about this hands on from coding it :--)
If it was just dhc client and dhc server that I will input can be changed rather easily to support a change in syntax and semantics, and as dhc for ipv6 is now just being deployed it will not be that painful to rev if that is what the dhc and ipv6 wgs want to do. That is my input on that end. Now if we started whacking basic architecture of dhc for IPv6 then I would give you a different answer. But the m and o bit also affect the code path that scans the ND packet and looks for the m and o bit as other bits in ND. Then there is code from addrconf to help resolve the if condtions of what to do or not do from the m and o bit. This code base can be integrated and varys from implementer to implementer from discussions with many of you over the years when we talk about implementing our beloved IETF specifications. This part of the m and o bit code is long before the dhc client begins processing and the code to do dhc client procesing for ipv6. If we get rid of the m and o bit it will affect three pieces of code: ND, Addrconf Selection, and then dhc. So it is not just changing dhc code. So if we change the bits or alter them this is what we are facing. I think before we know whether this is worth the change or doing it we need to be sure what we want to do and then and only then can determine implementation decision. The other option is keep the bits as is and then change how they are used or verify how they are used and that will only affect the indirection for Addrconf and dhc most likely. /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
