On Aug 13, 2010, at 1:13 PM, Suresh Krishnan wrote: > Hi Hemant, > Thanks for the comments. Please see responses inline > > On 10-08-13 01:44 PM, Hemant Singh (shemant) wrote: >> Right. I proposed to encapsulate the return RA message since the >> document proposes encapsulating the RS. > > The return RA message cannot be encapsulated as a large majority of the > Access Nodes do not have an IPv6 address (or even an IP stack for that > matter). They are performing some layer 3 functions without having a complete > IP stack. > >> We get the drift that this >> document is trying to bring ND to another feature parity that DHCPV6 >> supports - it's DHCPv6 PD. So ND SLAAC should also support assignment >> of a PD like DHCPv6 does. > > Personally, I think SLAAC should stay simple and I do not support this > SLAAC-PD idea. In either case, this needs to be a separate discussion. > >> However, I cannot accept this document in its current state to be a 6man >> WG work item because this document has a MUST in section 6.2 for sending >> a multicast RA with unicast L2 address. I and Wes have already blocked >> the LastCall for such a doctored (L3 destination is multicast but L2 >> destination is unicast) multicast packet document in v6ops >> (draft-gundavelli-v6ops-l2-unicast). > > This is not a last call of the document :-). I am not sure that the issues > you bring up against that document apply in this case. Can you specify what > exactly is the issue with unicasting the RA. >
I don't understand either. Why is it an issue for a sender node to transmit a packet on the link-layer as a unicast message, if its known there is only one receiver. I've not seen a single valid argument and so its fine, one is entitled for their opinions. Regards Sri -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
