Subject: RE: RFC 2461- issue list

From: "Bound, Jim" <[email-masked]>
Date: Fri, 24 Oct 2003 00:03:34 -0400

Hesham,

Comments on the issues-list. Below for initial input.

My view is we should not add mobile requirements into the ND 2461 spec
at all.  Only if a specific field was changed like the reserved field
mentioned where MIPv6 used 1 bit.

My rationale for that is as follows:

ND is a core spec for IPv6 deployment now for many years and the only
deployed production IPv6 nodes are NOT Mobile nodes.  Mobile IPv6,
though I am huge supporter of MIPv6, has not been deployed in
production, or any method to do DNS discovery, and we should strongly I
state NOT add new untested and unproven features and extensions to a
spec that is solid well tested and now widely deployed, because of
Mobility.  This is an error and invalid approach to adding Mobility to
ND and Addrconf parts required for Mobility.  I believe SEND also is
only valid issue because of Mobility too.

So I strongly do not support putting MIPv6 enhancements back into 2461.
It will break testing, certification, for a technology that is not yet
even in production, and will not be until base IPv6 is deployed which is
in process.

Here is an example.  A user I work with has an IPv6 mandate and requires
2461 because it is DS and widely tested and debugged pretty well.  MIPv6
is listed as emerging but not mandated.  If we put MIPv6 parts into ND
then we have put emerging into a core IPv6 spec. That is not a good
standards or engineering strategy and definitely not a good
implementation strategy for nodes that do not do mobility, and most
nodes on the Internet today are not mobile and that is reality.  For
tomorrow we need to build additional specs for Mobility as we have done
for MIPv6 and add to ND as required not change ND.  This is not a good
deployment or standards strategy.

A good example is we circulated 3315 back to PS.  That made it emerging
per the user. They are correct but look what just happened.  They now do
not have a mandated addressing spec but an emerging one for the protocol
they are deploying and preparing for production.  This was not wise on
the IETFs part or we have become incompetent and the market simply
cannot trust our judgement here as an engineering organization?

More comments in line below.

> Issue 1: Mixed Host/Router behaviour
>          by Pekka Savola, May 2001
>          http://www.wcug.wwu.edu/lists/ipng/200105/msg00068.html
>          Erik Nordmark made a comment that the text could be clearer:
>          http://www.wcug.wwu.edu/lists/ipng/200105/msg00077.html

This is a clarity issue and fine for recycle.

> 
> 
> Issue 2: Check against the case of preferred lifetime > valid lifetime
>          by jinmei, Dec 2002
>          http://www.atm.tut.fi/list-archive/ipng/msg07250.html
> 
>          This thread contained a possible updates on the 
> router behavior of
>          sending router advertisements:
>          http://www.atm.tut.fi/list-archive/ipng/msg07402.html

I don't agree with this issue nor the thread and we should not change
router behavior for this but that is separate discussion.

> 
> Issue 3: On-link assumptions in 2461 considered harmful. 
>          This issue was raised by Alain and documented in:
>          draft-ietf-v6ops-onlinkassumption-00.txt
>          draft-ietf-v6ops-v6onbydefault-00.txt
> Also see related issue in section 2.4 of: 
> http://www.ctie.monash.edu.au/ipv6/draft-jinchoi-ipv6-cRA-00.txt

This is nothing more than a note and should not be put into 2461.  

> 
> Issue 4: Advertisement lifetime issues raised by Pete Barany

We can increase or decrease values or add extensions.  

> 
> Issue 5: Clarifying the use of the M and O flags
>          (raised by Rolf and others during V6ops meeting 
>           in San Francisco)

Fine clarity edits.

> 
> Issue 6: The prefix length field in the prefix option
>          and its consistency with the fixed prefix size 
>          (64 bits) in RFC 3513. 

This is old debate we can do it again I guess.

>          
> 
> SEND issues:
> 
> Issue 7: All the security discussions (e.g. assuming that AH
>          or ESP can be added to the ND messages) will need to
>          be put in the context of SEND. 
> 
> Issue 8: Security considerations section needs to consider issues
>          in: draft-ietf-send-psreq-04
> 
> Issue 9: The chicken and egg problem for ND security using IKE
>          as specified in: 
>          draft-arkko-icmpv6-ike-effects-02 
> 
>          and manual SAs issues addressed in:
>          draft-arkko-manual-icmpv6-sas-02

ND with IPsec is secure.  Mobile creates new attacks.  SEND should do
their own spec and add value to ND.  ND should not be updated.  I argue
and question the entire notion of SEND all the time.  Not going there
again.  It is simply not needed for non mobile environments.

>          
> MIP issues:
> 
> Issue 10: Reducing MIN_DELAY_BETWEEN_RAS from 3 seconds 
>          to 50 ms as specified in MIPv6 (many emails on the 
>          MIP mailing list in October and November 2002)
> 
> Issue 11: Eliminating the random delays required before sending
>           an RS when a mobile node does a handover to a new 
>           link. The random delay imposed by 2461 significantly
>           increases the movement detection time for mobile nodes
> 
> Issue 12: Eliminating the random delays required in 2461 when
>           a router sends a solicited RA. See :
>           draft-mkhalil-ipv6-fastra-04.txt
> 
> Issue 13: Impacts of the omission of a prefix option. 
>           section 2.2 in :
>         
> http://www.ctie.monash.edu.au/ipv6/draft-jinchoi-ipv6-cRA-00.t
xt
          describes the impacts of omitting a prefix option from
          an RA on movement detection for mobile nodes. RFC 2461 
          does not require options to be present in every RA.

>Issue 14: Link ids required to aid with movement detection.
          see:
http://www.ietf.org/internet-drafts/draft-pentland-mobileip-linkid-00.tx
t

All MIP issues should be done in MIP, NEMO, and MIPSHOP et al.  Not in
ND for reasons I stated in the front of this email.

>Finally, I recall (but not clearly) some discussions 
>on the clarity of 2461 when it comes to multihomed hosts. But
>I haven't managed to find the relevant thread(s) in the 
>archive. So if you have an issue to add please let me know. 

This is a very weak set of issues for anything but a recycle and MIP and
SEND and DNS should be done as separate drafts.  

/jim

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

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

---

From: Pekka Savola <[email-masked]>
Date: Fri, 24 Oct 2003 09:41:35 +0300 (EEST)

Hi,

My initial thought is also that we should not make RFC 2461bis (or
2462bis) include every extension specified since 1998.  Those can stay
very well in separate drafts.  Of course, we should still consider whether
we want to enable the base spec to give more flexibility (e.g., the
solicitation timers etc.) for those extensions.  There is a clear 
distinction between these two, IMHO.

Another thought: if we recycle RFC2461bis to DS, I think we should re-do
the implementation reports if we changed the code (not sure whether new
reports is _required_..).  This may not be a bad thing, as the current
implementation reports should (IMHO) be a bit more detailed than that..

However, there are some things which need addressing now.  Inline about 
two IMHO important classes of issues..

On Fri, 24 Oct 2003, Bound, Jim wrote:
[...]
> This is nothing more than a note and should not be put into 2461.  

On the contrary, I believe this will of critical for the success of IPv6, 
and MUST BE dealt with.  Whether the WG thinks it is just enough to 
explicitly state the tradeoffs here, or whether the spec needs to be 
changed is a different subject.

> again.  It is simply not needed for non mobile environments.

I think it may not have been clear what these issues imply.  To me, it
seems clear that we will not be creating a new "secure ND" out of
RFC2461bis.  However, now that we're identified the shortcomings of ND
from the SEND work, we MUST include (some) discussion on these subjects in
this spec.

This may also result in some changes or optional toggles to make "plain
ND" a bit more resistant to attacks, but that's not necessary as long as
the issues are documented so the implementors and the users of ND are
aware of them.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings