Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt

From: Erik Nordmark <[email-masked]>
Date: Thu, 13 Jan 2005 10:55:36 -0800 (PST)

> On Tue, 14 Dec 2004, Pekka Savola wrote:
> 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?

The Solaris in.ndpd implements 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?

Solaris in.ndpd implements this.

> 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.

FWIW I think the intent was to say "zero is consistent with a nonp-zero value"
but "two different non-zero values are inconsistent".

> 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 ?

FWIW I don't see this implemented in in.ndpd.

If we really want this detailed level of implementation reports, IMHO we need
an implementation report form that asks these level of questions so
that it can be passed to the different implementors we know of (and advertised
to the list.)

   Erik

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 13 Jan 2005 13:56:46 -0500

> >> ==> 'or the source chooses to ignore unauthenticated Redirect
 > >>     messages' smells quite a bit from a leftover of IPsec 
 > AH times.  Reword?
 > >
 > > Can't SeND nodes choose to ignore redirects that aren't 
 > protected by SeND?
 > 
 > Sure.  I was just referring this editorially, that "unauthenticated" 
 > is often an overloaded term, referring to IPsec AH..

=> FWIW, I don't see any overload here. If you have a synonym
for it I'm fine with putting it in, but otherwise I don't see
a problem. There are so many misconceptions that it's hard to
write something that will be correctly understood by people
not very familiar with the Internet.

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.
===========================================================

---

From: [email-masked]
Date: Fri, 14 Jan 2005 08:37:54 +0200

Hi Jinmei,

> BTW: do we really need this level of detailed inspection to meet the
> two-implementation requirement for a DS?  When I raised a similar
> question when we discussed how we should deal with the M/O flags in
> rfc2462bis wrt this requirement, I was told that we usually only
> require a rougher level (e.g. whether there are more than two
> implementations that support NS/NA/RA/RS/Redirect messages without
> requiring line-by-line conformance to the corresponding RFC).  I
> personally prefer detailed inspection (if we can do that within a
> reasonable period), but I can live with the rougher version as a
> real-world compromise.  In any case, we should basically be consistent
> on the requirement level not to make a double-standard.

I agree with you on this.  As someone already has mentioned one implementation,
removing the text would be dangerous.  If we really wanted to remove it,
we should make a thorough search, via some other forums, to check, since
there are a lot of implementors not on this mailing list.

John