Subject: RE: RFC 2461- issue list

From: Soliman Hesham <[email-masked]>
Date: Fri, 24 Oct 2003 05:52:44 -0400

[moved this to ipv6 list]

Nick, 

Thanks, I'll add this to the list. 

Hesham

 > -----Original Message-----
 > From: Nick 'Sharkey' Moore [mailto:[email-masked]]
 > Sent: Friday, October 24, 2003 3:28 AM
 > To: [email-masked]
 > Cc: Soliman Hesham
 > Subject: Re: RFC 2461- issue list
 > 
 > 
 > On 2003-10-22, Soliman Hesham wrote:
 > > 
 > > This is what I found initially. Please let us know if 
 > > there are any issues that should be added to the list.
 > 
 > G'day Hesham,
 > 
 > 	I don't think this is on your list (cut-n-paste from
 > the opti-dad draft):
 > 
 > |	An NA with O=0,S=0 and no LLAO may [Note 1], however cause
 > |	the NC entry to be set to STALE, causing NUD to be
 > |   	performed on the address.
 > |
 > |   [Note 1] RFC 2461 is unclear on this, with [RFC2461 
 > 7.2.5] specifying
 > |        "the advertisement prompts future Neighbour Unreachability
 > |        Detection [...] by changing the state in the cache entry"
 > |        whereas [RFC2461 Appendix C] specifies the state as 
 > "unchanged".
 > |        Many arguments have been made on the list (see
 > |        
<ftp://playground.sun.com/pub/ipng/mail-archive/ipng.199912>)
|        for one interpretation or the other. For the purposes of this
|        draft, I have assumed that either behaviour is possible.

... but maybe this should be clarified.

cheers,

-----Nick

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

---

From: Soliman Hesham <[email-masked]>
Date: Sat, 25 Oct 2003 06:06:41 -0400

> > There is also the process issue on what can be added to
 > > a DS, given the requirements on moving from PS to DS
 > > (having every option interop tested and some level of 
 > > deployment), which might stand in the way of adding 
 > > new extensions from a PS/draft.  
 > 
 > You are allowed to add things that have been at PS for 6 months with
 > interoperability test results i.e. things that could move to DS in
 > their own right. 

=> Excellent, thanks for the clarification. I guess
this would definitely qualify the R and H bits in
the RA to be included. I'll check to see if the 
RA interval option was ever interop tested. 

Hesham

 >    Erik

---

From: Soliman Hesham <[email-masked]>
Date: Mon, 27 Oct 2003 07:32:51 -0500

> > no R bit. always include the global address configured from the
 > > prefix instead of just the prefix. the prefix can always be
 > > obtained using the prefix length field.
 > 
 > Two issues:
 >  - The router might not have an address in every prefix it 
 > advertises.
 >    Should a host still that the prefix field is indeed a useful
 >    address for the router in that case?
 >  - Existing routers do not put their address in the prefix 
 > option even
 >    when the router has an address in that prefix.
 >    Should a host still that the prefix field is indeed a useful
 >    address for the router in that case?
 > 
 > If we want to add this to 2461bis I think we must add the 
 > "R" bit as well.

=> Yes, given that we can put the R bit in the spec this 
seems like a good way to move forwad. Vijay, I'm assuming
that you don't have an objection to adding the R bit 
anyway. So let's do that. 

Hesham