On Tue, 14 Dec 2004, Pekka Savola wrote:
In short, this still needs at least one revision. Jinmei also had some O/M/DHCPv6 consistency issues which probably need to be addressed. There is some specification which I don't think has been implemented and should be removed unless anyone jumps up. There is a normative reference to addr-arch which is still PS, and this is not acceptable.

I went through one implementation and have a couple of additional comments wrt suitability for DS/clarify.


1) section 6.2.5: when AdvSendAdvertisements changes to FALSE, you SHOULD send a final RA with zero Router Lifetime.

At least a couple of implementations do send out final RAs with zero lifetime when the RA process is killed, but do not have 'state' which monitors whether AdvSendAdvertisements gets disabled or not on an interface. (e.g., at HUP signal)

Are there implementations of this?

2) section 6.2.5: if system management disables IP forwarding, subsequent RAs MUST set the Router Lifetime to zero.

I've seen no one implementing this (though many implement checks whent the RA process starts up). This either requires polling forwarding status constantly, or providing some kind of notifications when IP forwarding changes from on to off. Implementations?

3) section 6.2.7: RA consistency says like:
    - Cur Hop Limit values (except for the unspecified value of zero).

It is ambiguous what the ()'s means. A couple of possibilities:
a) if "my Cur Hop Limit" is zero, ignore consistency completely
b) if "my Cur Hop Limit" is zero, allow the others to have zero Cur Hop Limit, otherwise it's inconsistent
c) if "my Cur Hop Limit" is non-zero, allow the others to have same Cur Hop Limit, otherwise it's inconsistent
d) if "my Cur Hop Limit" is non-zero, allow the others to have same Cur Hop Limit or zero, otherwise it's inconsistent


This needs to be clarified.

4) section 6.2.8: if the link-local address of the router changes, it should multicast a few RAs from the old address with zero router lifetime, and a few from the new address. (SHOULD).

I haven't seen this implemented.   Similar reasons as 2).  Anyone ?

--
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
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to