Suresh, Please see in line below.
-----Original Message----- From: Suresh Krishnan [mailto:suresh.krish...@ericsson.com] Sent: Friday, August 13, 2010 4:13 PM To: Hemant Singh (shemant) Cc: Wes Beebee (wbeebee); Brian Haberman; IPv6 WG Mailing List Subject: Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt >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. Hmm, that's a very nebulous definition of the AN. It would be good to provide more details about the AN in the document so folks understand what L3 functions the AN can do - match IP functionality of the AN to the IPv6 node-req document so we know what all can the AN support. Since the AN IPv6 functionality is fuzzy, is the AN ever an IPv6 router? If not, then drop all text from the document that discusses not changing Hop Limit in the tunneled RS packet. The document also needs to explain other boxes in Figure 1 for what IPv6 network functionality do they support - especially the devices in the home. What is the link-local domain in Figure 1? Which device(s) can create a link-local address and issue DAD for the address? If the DSL modem in the home (whose specification lies totally in the DSL standards body) always first creates an IPv6 link-local address, issues a NS(DAD) and then sends an RS. Then the RS will always have a src IPv6 address and then the RA from the Edge Router can be unicast at L3 and L2 to the home. However, if the DSL standards bodies do not want to specify such behavior of the DSL modem, then why not consider another alternative. When the src IPv6 address in the received RS is the unspecified IPv6 address, the Edge Router encapsulates the RA in an outer packet with LIO destination option and sends the outer packet to the all-nodes destination. If an AN can capture an RS with all-routers destination, the AN can also capture a packet with all-nodes destination address. More than one AN receives the encapsulated RA, right? Each AN sees an LIO in destination option and only the AN whose line id matches the LIO processes the encapsulated RA and other ANs can drop the packet. Further, since section 5.2 says the AN does not need to process any downstream unicast RA's, what is the functionality on the AN for upstream RS's? I understand the AN can process multicast destined RS received on the AN upstream. Is the IP functionality on the AN sophisticated enough to also handle and process unicast RS? The AN does need to handle the unicast RS case and add an LIO. Also, a host can send multiple RS messages. So does the new LIO need extra fields like checksum or transaction id? > 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. Ah, OK. So when the unicast RA reaches the home node, are you saying the node initiates SLAAC and assigns one IPv6 address and as per RFC 4862, the node MUST issue a NS(DAD). What device in Figure 1 responds if a duplicate is found? Therefore what the document needs is to have a section that explains the IPv6 addressing of the deployment and basic address auto configuration operations before one can discuss RS and RA. Thanks, Hemant -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
