Pekka, all,
Sorry for the delay in resolving this but there were too many comments
and too little time! Seems like most of your comments were clearly addressed
by me or other people on the list and most are being put in the next rev
(thanks).
But I'm going to address the unresolved ones so far. Please let me know if I
missed any.
First of all, we seem to agree that very detailed comments on implementation
are not the best way to go, so I'm leaving out your comment on changing
link layer addresses for routers and whether it is implemented.
I'm aiming to submit the next rev ASAP (less than a week).
Here are the rest:
> > > AdvValidLifetime
> > > The value to be placed in the Valid
> > > Lifetime in the Prefix Information
> > > option, in seconds. The
> > > designated value
> > > of all 1's (0xffffffff) represents
> > > infinity. Implementations
> MUST allow
> > > AdvValidLifetime to be
> specified in two
> > > ways:
> > >
> > > - a time that decrements in
> > > real time,
> > > that is, one that will
> result in a
> > > Lifetime of zero at
> the specified
> > > time in the future, or
> > >
> > > - a fixed time that
> stays the same in
> > > consecutive advertisements.
> > >
> > > ==> AFAIK, the first option has not been implemented; I've
> > > at least not seen
> > > in done. Therefore unless someone shows that there are two
> > > implementations
> > > of this, this must be removed. (The same for
> > > AdvPreferredLifetime, and a bit
> > > in section 6.2.7.)
=> We were told this is implemented in Solaris I believe.
>
> > > A proxy MAY multicast Neighbor Advertisements when
> its link-layer
> > > address changes or when it is configured (by system
> management or
> > > other mechanisms) to proxy for an address. If there
> are multiple
> > > nodes that are providing proxy services for the same set
> > > of addresses
> > > the proxies SHOULD provide a mechanism that prevents
> > > multiple proxies
> > > from multicasting advertisements for any one
> address, in order to
> > > reduce the risk of excessive multicast traffic.
> > >
> > > ==> does anyone implement this SHOULD? Note that this does not
> > > give hints how to even go about doing that. If not, remove.
> >
=> As mentioned earlier by Erik, this is a requirement on other specs
using proxy ND. MIPv6 is an example of such protocol. I think this makes
sense as a requirement. So let's keep it.
> > > Inbound load balancing - Nodes with replicated
> > > interfaces may want
> > > to load balance the reception of incoming
> packets across
> > > multiple network interfaces on the same
> link. Such nodes
> > > have multiple link-layer addresses assigned
> to the same
> > > interface. For example, a single network
> driver could
> > > represent multiple network interface cards
> as a single
> > > logical interface having multiple link-layer
> addresses.
> > >
> > > Load balancing is handled by allowing
> routers to omit the
> > > source link-layer address from Router
> > > Advertisement packets,
> > > [...]
> > >
> > > ==> this is conflicting. The first para discusses
> generic inbound
> > > load balancing, the second load balancing that applies only to
> > > routers w/ RAs. How do hosts perform inbound load balancing?
> > > Needs text tweaking..
> >
=> Erik responded:
Leaving the first paragraph as is, since it is basically explaining the
term,
and adding something before the second paragraph that "Neighbor Discovery
allows a router to load balance traffic towards itself if the router has
multiple MAC addresses by ..."
=> I think this is fine so I'll add it to the doc.
> > > A router MUST limit the rate at which Redirect messages
> > > are sent, in
> > > order to limit the bandwidth and processing costs
> incurred by the
> > > Redirect messages when the source does not correctly
> > > respond to the
> > > Redirects, or the source chooses to ignore
> > > unauthenticated Redirect
> > > messages. More details on the rate-limiting of ICMP
> > > error messages
> > > can be found in [ICMPv6].
> > >
> > > ==> 'or the source chooses to ignore unauthenticated Redirect
> > > messages' smells quite a bit from a leftover of IPsec AH
> > > times. Reword?
> >
=> I don't see this as a synonym for IPsec, let's not change it.
> Unlike in IPv4 Router Discovery the Router Advertisement messages
> do not contain a preference field. The preference field is not
> needed to handle routers of different "stability"; the Neighbor
> Unreachability Detection will detect dead routers and switch to a
> working one.
>
> ==> preference has been plugged back, though not for stability
> reasons. I'd suggest just removing this paragraph.
=> Again, we didn't get any agreeing comments and two people
disagreed. I think we should leave this in.
The rest of your comments will make it to the next revision.
thx,
Hesham
===========================================================
This email may contain confidential and privileged material for the sole use
of the intended recipient. Any review or distribution by others is strictly
prohibited. If you are not the intended recipient please contact the sender
and delete all copies.
===========================================================
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
