Subject: RFC 2461- issue list

From: Soliman Hesham <[email-masked]>
Date: Wed, 22 Oct 2003 23:19:01 -0400

Folks,

This is what I found initially. Please let us know if 
there are any issues that should be added to the list.

Please note that some of these issues might not necessarily
be addressed in this revision if they require non-backward 
compatible changes. The main requirement here is to be 
backward compatible with our changes. 

If you wish to express opinions, questions or suggestions  
please start a separate thread with the issue's header
in the subject field. 

Thanks, 
Hesham

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

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

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

Issue 4: Advertisement lifetime issues raised by Pete Barany

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

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

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

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. 

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

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Oct 2003 10:38:45 +0200 (CEST)

I have a high-level question first; is the intent to do these updates
and recycle the document as a draft standard?
Or to try to move it to full standard?

If recycle at draft is the goal, are there documents (such as MIPv6)
which contain extensions to the packet formats which should be folded
into the base ND spec at this point in time?

In addition to the MIP issues in your list there is (at least) the
definition of the R bit in the prefix option, and the advertisement
interval option.

   Erik

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 23 Oct 2003 14:02:04 -0700

hi Hesham,

here is another issue.

when a router includes a Prefix Information Option (section
4.6.2 of RFC 2461) in the Router Advertisement, and if the
router has an address configured from that prefix, I suggest
including the router's address in the 'Prefix' field. not
just the prefix. the Prefix Length field will still indicate
the prefix length and hosts should be able to figure out
the prefix.

we have had problems when two different interfaces of a
router use the same link local address. some host
implementations just check the source address and assume that
the current router is still reachable even when they move
between links attached to the two interfaces on the router.

we came across this issue at Connectathon 2002. the following
URL has some discussion on it

http://www.piuha.net/~jarkko/publications/mipv6/issues/issue278.txt

Mobile IPv6 already defines a Modified Prefix Information
option where the router's address is present in the prefix
field. I would like to see it in the Neighbor Discovery
specification itself. having the global unicast address in
the prefix field will help in movement detection.

Vijay

---

From: Brian Haberman <[email-masked]>
Date: Fri, 24 Oct 2003 13:43:46 -0400

Erik,
      The goal at this point is to recycle at DS.  I have a query
into the ADs as to whether or not we should consider moving it
to Full Standard.

      Given that target, the primary goal is to clarify issues in
the spec.  I feel that including some additional definitions, such
as the MIPv6 R bit, is reasonable.  I do not want to see wholesale
changes put in this spec from other specs.  Anything added to the
spec should not break backwards compatibility with existing
implementations.

      This applies to the update to 2462 as well.

Regards,
Brian

---

From: Alain Durand <[email-masked]>
Date: Fri, 24 Oct 2003 11:34:04 -0700

I had this question yesterday and I couldn't find an answer in RFC2460:

Is it valid for a host to send a packet with Hop Count set to zero?

	- Alain.

---

From: "JinHyeock Choi" <[email-masked]>
Date: Sat, 25 Oct 2003 21:59:57 +0900

Dear Vijay

Thanks for bring this up. 

Vijay Devarapalli wrote 
> hi,
>
> here is another issue. it involves both 2461 and 2462.
> 
> RFC 2461 says
>
>   Before a host sends an initial solicitation, it SHOULD delay the
>   transmission for a random amount of time between 0 and
>   MAX_RTR_SOLICITATION_DELAY.
>
> RFC 2462 says
>
>   If the Neighbor Solicitation is the first message to be sent from an
>   interface after interface (re)initialization, the node should delay
>   sending the message by a random delay between 0 and
>   MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY].
>
> lets assume a Mobile Node moves and attaches to a new
> link. it does router discovery and configures a Care-of
> address. the mobile node cannot send a Binding Update
> until it completes DAD for the Care-of address. these
> two random delays (before router discovery and before
> DAD) contribute a lot to the movement detection delay.
> I think this needs to be fixed.
> MAX_RTR_SOLICITATION_DELAY is 1 second. taking the worst
> case scenario, it could be 1 second before a sending
> router solicitation, one second before sending neighbor
> solicitation for DAD and then 1 second before DAD
> completes. the Binding Update cannot be sent until then.

Indeed these cause long handoff latency. And there is an another random 
delay before sending RA.  
 
> we had a long discussion on the Mobile IP mailing list.
> some argued that this needs to be done only when the
> interface is initialized and not when the mobile node
> attaches to a new link. others argued that this random
> delay is essential to avoid a DAD storm if a bunch of
> mobile nodes move at the same time.

We have not reached a consensus in mobileip mailing list. I wish we clarify 
this.  

Best regards

JinHyeock
1H>þ°¢¹"ž+¢êfj)bž	b²Ø©¿¨žµú+€fŠx¬¶¶Š÷‘z«ž²Û!¶Úlÿü0ÃXžµú+ƒùšŠYšŸùb²Ø§~â¦þ

---

From: "JinHyeock Choi" <[email-masked]>
Date: Sat, 25 Oct 2003 23:56:40 +0900

Dear Jim

Thanks for your detailed comments.

I may not be clear enough. This I-D assumes the scenario of a host moving from one link 
to another. In many cases, the term 'a host/node' is actually 'an MN'.

Kindly find my in line comments.   

> Comments on this draft.  I am unclear but it may be this work needs to
> be done in the mipshop WG within the Internet Area as I believe all that
> is required to resolve the problem statement in this draft is policy to
> use the current ND 2461 mechanisms and the extended ND mechanisms in
> MIPv6.  As the WG may realize I do not support merging MIPv6 ND changes
> back into to RFC 2461 so do not see need for that.  If this spec is to
> define and clarify the policy for use of the new prefix option in MIPv6
> ND to set RA R bit then I suggest that discussion be in mipshop WG where
> that is their focus. 
 
Thanks for your advice. It was not clear to me which WG had mandate over this work. 

> 1. Introduction 
>     
>    Movement detection (MD) is one of a series of stages in accomplishing
> 
>    MIPv6 handover. As defined in the MIPv6 specification [MIPv6], 
>    detection of movement is accomplished through reception of Router 
>    Advertisements (RAs) and Neighbor Advertisements (NAs), and 
>    comparison of these messages with previously received router 
>    information. 
> 
> Layer 2 can also note movement detection and more reliable and faster
> today. 

Layer 2 can only detect Link layer change. Layer 2 may act as a hint but can't confirm 
movement. For example, layer 2 by itself can't check the (partial) reachability of current 
default router.  
  
[Omitted]     
> 2.1 Link local scope of Router Address 
>  
>    The router address contained in an RA message is link-local scope. 
>    Neighbor Discovery [RFC 2461] only advertises a router's link-local 
>    address, by requiring this address to be used as the IP Source 
>    Address of each Router Advertisement. Hence its uniqueness can't be 
>    guaranteed outside of a link-instance.  
> 
> This is not true if the R bit is set then the full IP address is
> available and why it was put as option in MIPv6.  But, for most nodes on
> a link the default is that routers do not need to supply the full IP
> address in RAs.  But, there is a means and support to resolve this
> problem for Mobility.

I agree that R bit can solve this issue but the above part is to describe the problems. 
You present the solution too early. :-)  
 
[Omitted]  
>    For this, a host checks whether the prefix of its IP address is in 
>    the Prefix Information Option of Router Advertisement messages. But 
>    an unsolicited Router Advertisement message can omit some prefixes 
>    for convenience, for example to save the bandwidth.  
> 
> Then that network will suffer and if the nodes require those prefixes it
> is not an ommission of 2461 but bad network configuration and planning
> by the user.

In case of multiple prefixes on a WIRELESS link, it may take too much bandwidth to 
advertise all the prefixes all the time.  
     
>    So, checking the prefixes in an RA, an MN may make false assumption 
>    that the prefix of its current IP address is not supported in a new 
>    link, while that prefix is just omitted in that particular RA. 
> 
> But this is not the fault of 2461 and the R bit works when used and
> routers supporting MNs into its network should use the R bit.  There is
> no problem.

R bit by itself can't solve this problem. After Movement, if an MN can still hear its 
current default router (confirmed with R bit), it can assume that its CoA is still valid. 
But if an MN doesn't hear its current default router, MN is in a trouble described 
above. 
  
>    Moreover, even though a RA message contains all the Prefix 
>    Information Options, a host has no way to know it. There is no 
>    indication. 
> 
> Why?  Sure they do? 

When a RA arrives, an MN can't be sure that it contains all the prefixes. There always is 
a possibility that a prefix may be omitted in this particular RA. 
     
>    Hence, a host can't be sure that the prefix of its current IP address
> 
>    is not supported on the current link, even though the prefix is not 
>    contained in an RA message. 
> 
> There are clear administration rules for MN support for ND and MIPv6
> Extensions to ND. The problem is do we not feel MIPv6 documented these
> well enough or not?
>     
>    The problem is 1) an RA may omit some Prefix Information Options and 
>    2) even it has all the Prefix Information Options, there is no 
>    indication that it does. 
> 
> I cannot parse the conclusion for 2) at all?

As I described above, there is no indication in a RA which notifies this RA contains all the 
prefixes. 

>    The possible solution for the above is the RA with  
>    1) All the Prefix Information Options and  
>    2) The indication that it contains all the Prefix Information 
>       Options.  
> 
>    For 2), we may define a new bit in an RA message. We will give more 
>    detail in 3.1. 
> 
> This is not necessary and has been resolved by MIPv6. 
    
Actually mobileip WG doesn't feel that MD is under its work scope either. A new WG, 
DNA, currently BoF, will do this. . 
     
> 2.3 Lack of Solicitation Acknowledgement  
>     
>    In Router Advertisement messages, there is no solicitation bit, as in
> 
>    Neighbor Advertisement. So when a node receives a RA, it can's be 
>    sure it's the reply to its Router Solicitation. To confirm bi-
>    directional reachability, an additional NS/ NA exchange is mandatory.
> 
> Do not agree.  When a node gets an RA it then begins communication.  If
> that communications fails then the router is down and must be retried or
> must locate another router.  The IPv6 architecture did not implement
> such reacability with routers for a good reason and that is to support
> reduced discovery messages and bandwidth on an IPv6 link.   

Correct me if wrong. But RFC 2461 mandates hosts to confirm reachability with its default 
router. After movement, hosts have to confirm reachability and it entails NS/ NA exchange.
     
[Omitted] 
>    According to [RFC 2461], a router may advertise prefixes with L=0 and
> 
>    A=1. This implies that stateless address autoconfiguration is allowed
> 
>    for these prefixes [RFC 2462]. It is possible to show that in the 
>    absence of Address State on routers or ND proxying, duplicate 
>    addresses may be configured for a global address, when an address 
>    owner exists on another link of the same subnet.
> 
> This is point the draft missed early on.  Routers cannot provide same
> prefixes to two separate links. 

This point we'd better clarify. I think that Routers can provide the same prefix to two separate 
links when L bit if off. Kindly check the following example. 

A router has two interfaces to which two separate link are attached. For those interfaces, the 
router advertise the same prefix A:: with L bit off. There is nothing in RFC 2461 which bans
this. 

                          ____
                         |        |
                         |   R   |________________ 
                         |____|            A::
                             |
                             |  A::
                             |
      
I think that the usage of the prefix with L bit off is a little ambiguous. We'd better clarify it. 
 
> 3. RA Optimized for Movement Detection 
>     
>    Our goal is to design an RA in such a way that an MN can detect its 
>    movement efficiently, quickly and precisely with as little signaling 
>    as possible. As described above, the information contained in a 
>    current RA message is inconsistent and incomplete for movement 
>    detection. The following proposals seek to facilitate efficient 
>    movement detection by including all the necessary information in an 
>    RA message. 
> 
> There is no reason for this design and the problem has been solved by
> MIPv6.

Unfortunately this problem has not solved by MIPv6. Neither MIP6 WG is to work on it. 
DNA is to design a solution and, I think, this is a part of it.  
 
> 3.1 Complete RA  
>     
>    Since routers may neglect to send all prefixes in every
> advertisement, 
>    it is difficult for an MN to determine whether it is attached to a 
>    different subnet, when an RA received without its currently 
>    configured prefix. 
>     
>    Even though an RA contains all the Prefixes, an MN has no way to know
> 
>    it. There is no indication. So still ambiguity remains.  
>  
> Sure it does if the R bit is set for a router or L bit for host
> notification.
     
We have a disagreement here. R bit and L bit talk only about just one prefix. They don't say 
anything about the collection of all prefixes. I don't know how, with L and R bit, an MN can 
be sure a particular RA contains all the prefixes. 

>    If a router is able to send an indication that the RA it sends 
>    contains all of the valid prefixes for a link-instance, then 
>    reception of an RA which contains a different set of prefixes 
>    indicates the presence of a different subnet.  
> 
> This is to much overhead and the R bit already does this far better and
> why MIPv6 WG converged on the support of this new prefix option and why
> the IPv6 WG supported the change.  This draft is trying to reinvent that
> solution and it is not necessary.

IMHO, the purpose of R bit and Complete bit is different.  
     
[Omitted] 
>    For efficient Movement Detection, we propose a RA with  
>    1) AR's global IP address using R bit  
>    2) All the options (including all the Prefix Information Options) 
>    3) The indication that it has all the options (Complete bit) 
>    4) S bit (Solicitation bit) to confirm reachability without NS/ NA 
>       exchange 
> 
> I don't agree with the reachability suggestion but all the others exist
> today and what is needed is to define a policy when all this must
> execute.

There is nothing for 3), to indicate the completeness of a RA.  

Another thanks for your detailed and helpful comments. It clarifies my thoughts. 

Best regards

JinHyeock

LR¿¬(®H§‚
èº™šŠX§‚X¬¶*oê'~ŠàÙ¢ž+-«b½ä^ªç¬¶Èm¶›?ÿ0Ö'~Šàþf¢–f§þX¬¶)ß£ø©¿

---

From: Fred Templin <[email-masked]>
Date: Tue, 28 Oct 2003 11:35:07 -0800

Don't know about the sending host, but perhaps the next forwarding
hop should send an ICMPv6 parameter problem message (RFC 2463,
section 3.4) if it gets a packet with Hop Count = 0?

Trouble is, the original source of the IPv6 packet might be different
than the previous hop which made the mistake forwarding the packet
with Hop Count = 0. So, the ICMPv6 parameter problem message
might  be of little value to the original source.

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Fri, 31 Oct 2003 01:38:41 +0200 (EET)

> there are any issues that should be added to the list.

Oh, yes, I only now remembered one.  There was some confusion regarding 
redirects and how you can configure the nexthops.  See the thread I opened 
on "global/link-local nexthops and RFC2461" on 17 Jul 2003, also at:

http://www.atm.tut.fi/list-archive/ipng/msg09986.html

It may be that only a textual clarification is needed on the applicability 
of redirects in the presence of non-link-local nexthops, but if opted to 
do more, there could be some other work for to do as well (my gut feeling 
was that only the clarification was deemed necessary)

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