Hi Woj Don't you have that same problem regardless of the LIO?
If you have an IPv6 host directly connected to say your loving Residential Gateway and it sends 3 RS messages you have the same issue, right? Also, the likelihood of losing 3 RS messages are highly unlikely, you would have better probability doing the Lottery and winning! BR Alan ________________________________ From: Wojciech Dec [mailto:wdec.i...@gmail.com] Sent: August-19-10 7:59 AM To: Alan Kavanagh Cc: Ole Troan; Suresh Krishnan; Brian Haberman; IPv6 WG Mailing List Subject: Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt SInce the WG is being asked to adopt a draft it would seem rather natural to explain the context of the usage more clearly, especially as it appears that this usage context has a rather serious pitfall when used alongside a regular IPv6 client (leaving such a client with no connectivity after an RS timeout). -Woj. On 18 August 2010 18:01, Alan Kavanagh <alan.kavan...@ericsson.com<mailto:alan.kavan...@ericsson.com>> wrote: Hi Ole I believe its also true in that the host tx the RS and Edge node then responds with the RA as oppose to the Edge node txing the RA. This is really a BBF issue on how the BNG operates and should be taken up in BBF. Alan -----Original Message----- From: ipv6-boun...@ietf.org<mailto:ipv6-boun...@ietf.org> [mailto:ipv6-boun...@ietf.org<mailto:ipv6-boun...@ietf.org>] On Behalf Of Ole Troan Sent: August-18-10 11:12 AM To: Suresh Krishnan Cc: Brian Haberman; IPv6 WG Mailing List Subject: Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt Suresh, >> that wasn't quite the question I asked. DHCPv6 has a well defined mechanism >> to periodically retry, while RS client sending simply timeout. This would >> seemingly leave such clients in the proposed scheme with no connectivity. > > I do see your problem, but that problem is common to all existing SLAAC > clients and is not specific to LIO. If your problem is "RFC4861/62 compliant > clients give up after retransmitting an RS 3 times", I am not sure what this > draft can do about it. I think the main difference is that for all other SLAAC hosts, they will receive a multicast RA which will trigger SLAAC. is that also going to happen in this case? cheers, Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org<mailto:ipv6@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org<mailto:ipv6@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
