Hi Thomas,
On 10-08-26 08:37 AM, Thomas Narten wrote:
I htink Woj is right and raises some fundamental issues.
Yes. And nobody said anything to the contrary. I problem is that the
issue is orthogonal to the mechanism described in the RS mark draft.
Even if draft-krishnan-6man-rs-mark was never written, this problem
would still exist. I have tried to put the issue down in a draft so that
we can discuss a workable solution. I would appreciate your comments on
the draft.
http://www.ietf.org/id/draft-krishnan-6man-rs-lost-00.txt
The RS/RA mechanism *assumes* that routers send out periodic multicast
advertisements. Having nodes send out an RS to solicit RAs is a sort
of optimization, intended to prod routers into sending out an RA
immediately. But the sending of RSes is NOT a fundmental part of RAs.
Right. And in this specific scenario routers DO send out periodic
multicast advertisements as expected.
Once a node has obtained an RA, the basic model assume that a node
need not send any additional RSs out. Periodic RAs will supply the
info it needs. This is made clear in RFC 4861, which says:
I am not sure I agree with you on this one. Again, quoting from
scripture (Section 6.3.7 of RFC4861):
"Responses to solicited advertisements may contain more information
than unsolicited advertisements."
seems to indicate that the original ND spec anticipated the possibility
that the periodic multicast RAs could contain less information that the
solicited RAs.
Once the host sends a Router Solicitation, and receives a valid
Router Advertisement with a non-zero Router Lifetime, the host MUST
desist from sending additional solicitations on that interface, until
the next time one of the above events occurs.
where the "above events" refers to things like the interface
restarting, attaching to a link again, etc.
In other words, once a node has received RAs, the protocols do not
require it to send additional RSs, even if it doesn't recieve RAs.
The only reason RSes are there in the first place is to handle
restarting nodes, who want to get an RA immediately instead of waiting
for the next periodic one.
This is not a flaw in ND. This was the intended design in an intended
operating environment.
What is proposed in Suresh's draft is a configuration that simply
doesn't match a normal network. Namely, a single broadcast domain, but
RAs tailored to individual clients.
I have to say that such networks are not uncommon and not limited to
Broadband Forum access networks. e.g. A wireless lan network with
multiple SSIDs and different vlans upstream to reach the router needs to
act in exactly the same way in order to keep prefixes separate between
the SSIDs.
I am not yet convinced that the IETF needs to (or should) support such
a configuration, as it is clear that even with the proposed option,
there are other issues with the target environment.
The Edge Router in the draft will be required to send unicast RAs to
all individual devices. It will need to maintain sufficient state to
do so, even if the Edge router restarts. Replacing the edge router
with some other router will cause problems because the new router
won't have the missing state, and there is no clear way to rebuild it.
What is the BBF solution to this problem? Has it thought this through?
A far better solution is for the AN node to have enough of an IP stack
on it so that it can source RAs and provide the right information.
Just because some "don't want to do this" (for cost or other reasons)
doesn't mean we should support it, especially if we don't think the
approach will be reliable or robust in practice. We should only bless
an approach if we think it can be made to work in practice.
This draft is a request for allocation of a destination option for
implementing a BBF specific mechanism. It is specifically not a request
for the IETF to bless the mechanism. The mechanism has been described in
the draft to provide the background for the usage, as requested by the WG.
The way I see it, without this option, SLAAC-only hosts will be left
without any way of obtaining an address in these specific deployments.
Thanks
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
