Hello, Thomas Narten and 6MAN folks. I made a presentation for our draft "draft-cha-ipv6-ra-mo-00.txt" at the 6MAN session in Dublin IETF. This draft aims to clarify the handling of the M/O flags of IPv6 RA. Though I got several comments during my presentation, I could not figure out what you really pointed out. So, I decided to ask you again why you think that the issues which the draft addresses are neither clear nor considered as worthy to be discussed in the 6MAN wg. First of all, I would like to give a brief summary for the draft. Existing specification (RFC2462) does not give a method on how to revoke DHCPv6 clients once they were invoked by the M or O flags of RA messages. Let us think about the case that a administrator wants to change network policy from stateful addressing via DHCPv6 to stateless one. Although the admin clears M flag of RA messages and reconfigure(or shutdown) the DHCPv6 server, the DHCPv6 clients keep operating. Even after all bindings expire and stateful addresses are invalidated, the client will keep searching another stateful servers by sending SOLICITs, because the DHCPv6 protocol does not care about values of RA flags. If the intention of the restriction that DHCPv6 clients should be invoked at the transition from FALSE to TRUE of the M or O flag of RA is that waste of resources of network infrastructure and host devices caused by useless DHCPv6 operation can be prevented and stateful addresses can be configured automatically by the administrative policy, we believe that our draft has value to supplement missing parts which existing specification and implementations have. The second issue (which is likely less important) is concering conflicts M/O flags from different routers which belongs to differnt administrative domains. Existing IPv6 stack implementations such as linux are assumed to comply with handling of the M/O flags of RA in the RFC2462. So, they just keep the most recent M/O values without considering senders of RA messages. This point does not expose serious problems though it does not provide consistent informations about the availability of the DHCPv6 service. Since we would like to support revocation of DHCPv6 clients at the transition of M or O flag from TURE to FALSE, the handling of the flags is reworked in our draft to avoid the iteration of invoking and revoking of the clients. Because we believe that the issues are obvious and clear, we would like to ask why 6MAN folks do not agree with our points. Please give your opinions.
Thank you in advance. Joseph HyunWook Cha Software Engineer Network System Division SAMSUNG Electronics, Inc. If you do not stand firm in your faith, you will not stand at all. - Isaiah 7:9 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
