Hi Hemant,
-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email protected]]
Sent: Saturday, August 14, 2010 5:05 PM
To: Suresh Krishnan; 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
Suresh,
Please see in line below.
-----Original Message-----
From: Suresh Krishnan [mailto:[email protected]]
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?
The AN functionality is defined in the BBF documents. I am not
sure we should cut and paste it from there. The document in question
(TR-101) is listed as a normative reference in this draft.
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?
No. The ethernet aggregation network will ensure (using MAC learning)
that only the specific AN that has the sender attached will get the RA
packet.
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?
I am not sure I understand the problem. The original RS packet is sent
unchanged. IMHO, the LIO does not need any additional fields.
> 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?
None of the devices do. The goal of the LIO is to make sure that two
different subscriber lines never get the same prefix for SLAAC. If you
are talking about duplicate link-locals, there is a different solution
proposed for it. Please see
draft-costa-6man-dad-proxy-00
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.
As I said, the deployment models are covered in the BBF TR-101
document update for IPv6. It is listed as a normative reference.
Thanks
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
