Inline..
On Sat, 18 Dec 2004, Soliman, Hesham wrote:
> substantial > ----------- > > ==> this spec needs at least an IANA Considerations section, > stating at > least: > 1) the allocation guidelines for ND option types/codes > (Standards Action? > IETF Consensus?) > 2) that no IANA action is required for ICMPv6 types, > beyond updating > the ICMPv6 codepoints to refer to this RFC instead of > RFC2461 in their > registry.
=> ok. I didn't think IANA sections had to be included but I'll add 2) above.
Yes, in all new drafts will have to have an IANA Considerations section, even if empty .. and currently there's no policy on ICMPv6 ND assignments, so this doc needs to spell it out.
> > 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.)
=> There are three issues to consider: 1. The second option actually (evidently more implemented) seems strange. If the time is decremented, then why not reflect that in advertisements?
I see nothing strange there at all. E.g., if you advertise AdvValidLifetime of 1 hour, and the service is expected to continue to be available, it is natural that each advertisement has the same value.
2. One could argue that this is an implementation issue. The receiver will update the Valid Lifetime field each time it gets an adv. So does it matter if it's a different value each time or the same?
I don't understand what you're trying to say.
The first option is clearly meant to be used when renumbering a network at a specific time, and you want to convey that in the advertisement. The second is used everywhere else.
3. As Bob mentioned, this is already a DS and I'm not sure if we want to remove this now, especially if we don't know 100 % that it's not implemented.
KAME implements the first option, but I am not aware of anyone else.
No matter what, even if it stays, MUST for both is clearly inappropriate. MAY for the first might be OK.
> 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.
=> I don't know if anyone implements it, but they SHOULD ;) This is what the spec recommends, is it wise to change the (preumably) reocmmended mechanism because some don't follow it?
The idea of the implementation requirement is to remove those recommendations which implementations really don't want to do, or have proven to be too difficult to implement to make it worth the while. I think this is caused by the latter.
> semi-editorial
> --------------
>
> 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..
=> ok, suggestions are welcome.
Replace:
Load balancing is handled by allowing routers to omit the
source link-layer address from Router Advertisement packets,
thereby forcing neighbors to use Neighbor Solicitation
messages to learn link-layer addresses of routers. Returned
Neighbor Advertisement messages can then contain link-layer
addresses that differ depending on who issued the
solicitation.With:
Load balancing is handled by allowing nodes to omit the
source link-layer address from neighbor discovery packets,
thereby forcing neighbors to use Neighbor Solicitation
messages to learn link-layer addresses. Returned
Neighbor Advertisement messages can then contain link-layer
addresses that differ depending on who issued the
solicitation.> 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?
=> Hmm, ok let me take a good look at it. In general, it's an acceptable statement, of course in reality there is no way of securing it for large scale deployment. AFAIK SEND didn't secure redirects.
True, but IMHO the context of the word 'unauthenticated' is not clear.
SEND supports redirects.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
