RE: RFC 2461- issue list

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------