Hi Woj Its the same issue for DHCPv6, if the client dont send a DHCP_Solicit you dont get an address. Also, the RS similar to the DHCP_Solicit is used to "kick_start" the IP Sub session and as you know there are lots of hosts whom dont have a DHCPv6 client and will not have a DHCPv6 client.
The RS LIO is used to cater for hosts who do not have a DHCPv6 Client. Also the LIO is used to identify the subscriber line and tie rules etc to this sub line. Alan ________________________________ From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Wojciech Dec Sent: August-18-10 10:46 AM To: Suresh Krishnan Cc: Brian Haberman; IPv6 WG Mailing List Subject: Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt Hi Suresh, thanks for your reply. Continued inline... On 18 August 2010 16:03, Suresh Krishnan <suresh.krish...@ericsson.com<mailto:suresh.krish...@ericsson.com>> wrote: Hi Woj, Thanks for your comments. On 10-08-18 07:11 AM, Wojciech Dec wrote: Hi, I have a question or two to the draft authors who can hopefully clarify the expected context and working of this scheme, which at the moment is a bit unclear. In essence the problem this draft appears to be trying to solve is using RS/RA messages to induce state into intermediate or IP edge devices like what is done for DHCP, with the LIO being used to induce such state. All this is presumably meant to take place following an RS message sent by a client. Thus, my questions are: How does this solution cope in a case where the client does not send an RS? (or the RS sending has timed out)? The first sign of life from the client is either an RS or a DHCPv6 message. If the network does not see either of the messages, there will be no address allocated/prefix advertised to the client. The client will not have any connectivity. Hmm, but if the first sign of life is a DHCPv6 message from a client , then why would the RS LIO be needed ? Now, in the case of a non DHCPv6 client, given that such clients are do time out from sending RS messages, how does the solution cater to that? Just leaving clients with no connectivity seems like a highly undesirable proposition/outcome... -Woj. Thanks Suresh
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
