Subject: Optimistic DAD draft ...

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 15 Oct 2002 12:58:00 +1000

G'day IPng-ers,

	One of the big issues in getting low-latency
handovers working for IPv6 mobility is the long delay
involved in completing DAD.

One option is to allow the Mobile Node to communicate
while the address is still Tentative (optimistically assuming
that DAD will succeed), but to adjust its ND / SAA
behaviour in order to minimize disruption in case
of an address conflict (and maintain correct interoperation
with unmodified nodes).

	We've kicked the idea around a little on mobile-ip,
and I've formalized my thoughts into an internet draft,
which should get published soon.  In the meantime, you can
find it at <http://www.ctie.monash.edu.au/ipv6/fastho.htm>
(tentatively titled draft-moore-ipv6-optimistic-dad-00).

        I'd be interested in your opinions on the draft,
and its potential suitability for standards track.

cheers,
        Nick
-- 
Nick 'Sharkey' Moore                    <[email-masked]>
Research Fellow, CTIE                   Tel: +61 3 9905 3707
Monash University,  Australia           Fax: +61 3 9905 5358  
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 15 Oct 2002 13:21:16 -0700

Without having read the draft, it occurs to me that the whole idea of
DAD latency impacting hand-offs is a self inflicted problem. From the
perspective of 'failure to plan on your part does not constitute an
emergency on my part', it would seem the prudent thing for a MN to do is
establish DAD for all candidate prefixes well before it is ready to
start using them. I realize this creates extra traffic if the node
doesn't end up moving, but it also prevents a node from stepping on
someone else that was actively using an address. Which is more
important, making sure a node can move quickly, or making sure a
stationary node is not interrupted???

Tony

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Nick 
> 'Sharkey' Moore
> Sent: Monday, October 14, 2002 7:58 PM
> To: [email-masked]
> Subject: Optimistic DAD draft ...
> 
> 
> G'day IPng-ers,
> 
> that DAD will succeed), but to adjust its ND / SAA behaviour 
> in order to minimize disruption in case of an address 
> conflict (and maintain correct interoperation with unmodified nodes).
>

---

From: Pekka Savola <[email-masked]>
Date: Tue, 15 Oct 2002 23:31:31 +0300 (EEST)

On Tue, 15 Oct 2002, Tony Hain wrote:
> [...] it would seem the prudent thing for a MN to do is
> start using them. [...]

Isn't there a problem with how this could be done, as currently specified?

One can't perform DAD before being on the link.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 15 Oct 2002 13:35:32 -0700

True, but the term 'hand-off' implies a make-before-break process, else
the MN is just establishing itself on a new link. Given it has the
opportunity to be aware of multiple links, it can decide when to switch.
I am arguing that it complete DAD 'before' it makes that decision, not
after.

Tony

> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Tuesday, October 15, 2002 1:32 PM
> To: Tony Hain
> Cc: 'Nick 'Sharkey' Moore'; [email-masked]
> Subject: RE: Optimistic DAD draft ...
> 
> 
> establish DAD 
> > for all candidate prefixes well before it is ready to start using 
> > them. [...]
> 
> > > handovers working for IPv6 mobility is the long delay involved in 
> > > completing DAD.
> > > 
> which should 
> > > get published soon.  In the meantime, you can find it at 
> > > <http://www.ctie.monash.edu.au/ipv6/fastho.htm>
> > >         I'd be interested in your opinions on the draft, and its 
> > > potential suitability for standards track.
> > > 
> > > 
> > > cheers,
> > >         Nick
> > > --

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 15 Oct 2002 14:46:55 -0700

Hello Tony,

It is possible to have nice handoffs even with
break-before-make, as long as "break" is not
too lengthy.   If the determination about the
destination network is available in time, completing
DAD before switching is a good idea -- whether or
not the handoff is "break-before-make".

This is under discussion within the seamoby working
group.  We have a draft about it, and an optimistic
DAD scheme.  When my head rises more than an millimeter
above water, I'll read the draft in the Subject: line
(glub, glub).

Regards,
Charlie P.

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 15 Oct 2002 15:11:35 -0700

Hi Tony,

> I am arguing that it complete DAD 'before' it makes that decision, not

I don't think we can consider all "handoffs" as 'make-before-break'.
There exists some link-layer technologies that allow this,
but not all have such capability. 

Completing DAD before handover requires either movement anticipation
or make-before-break, both of which are not widely applicable.
Therefore solving DAD latency for general case is a valid
approach, imo.

alper

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Wed, 16 Oct 2002 08:05:31 +1000

On Tue, Oct 15, 2002 at 01:21:16PM -0700, Tony Hain wrote:
> start using them.

Absolutely. If only more link-layers made this possible!

Unfortunately, in practice, MNs often move unexpectedly
due to the vagaries of RF propagation. 

> Which is more

The draft attempts to address this, by making sure that the
Optimistic MN will not interrupt established connections even
in the case of collision.

cheers,

-----N

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Wed, 16 Oct 2002 08:18:18 +1000

> not the handoff is "break-before-make".

Yep ... the mobileip stuff deals with this with a kind
of "Neighbour Discovery by Proxy" ... I'll obviously
have to come over and have a look at what seamoby is
up to as well!

> When my head rises more than an millimeter

:-) It's a short one, honest! No snorkel required ...

-----N

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 15 Oct 2002 15:18:34 -0700

inline

> [mailto:[email-masked]] On Behalf Of Charles 
> E. Perkins
> Sent: Tuesday, October 15, 2002 2:47 PM
> To: [email-masked]
> Cc: 'Pekka Savola'; 'Nick 'Sharkey' Moore'; [email-masked]
> Subject: Re: Optimistic DAD draft ...
> 
> 
> 
> Hello Tony,
> 
> too lengthy.   

It seems like this would be a bigger latency concern than DAD.

> If the determination about the

Maybe I just don't understand the technology well enough, but I from my
limited perspective it would seem that the current GGSN would know which
radio system the MN was attached to, and therefore could figure out the
candidate set of destinations for a hand-off. That list could be
forwarded to the MN, so personal policy and signal strength could be
applied to sort the list to come up with the best candidates. With that
an out of band predictive DAD could be done. This would make much more
sense than moving, stepping on an existing node, then backing off. It
seems that a little bit of overhead traffic is better than dropping 2
connections.  

> > True, but the term 'hand-off' implies a make-before-break process, 
> > else the MN is just establishing itself on a new link. Given it has 
> > the opportunity to be aware of multiple links, it can 
> decide when to 
> > switch. I am arguing that it complete DAD 'before' it makes that 
> > decision, not after.
> > 
> > Tony
> > 
> handovers working 
> > > > > for IPv6 mobility is the long delay involved in 
> completing DAD.
> > > > >
> while the 
> > > > > address is still Tentative (optimistically assuming that DAD 
> > > > > will succeed), but to adjust its ND / SAA behaviour 
> in order to 
> > > > > minimize disruption in case of an address conflict 
> (and maintain 
> > > > > correct interoperation with
> > > unmodified nodes).
> > > > >
> and I've 
> > > > > formalized my thoughts into an internet draft,
> > > which should

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Wed, 16 Oct 2002 08:24:18 +1000

> It seems like this would be a bigger latency concern than DAD.

1000ms is a long time by anyone's standards!

> candidate set of destinations for a hand-off.

If only the networks we are experimenting with were so civilized!
There's a lot of interest in getting MIPv6 working on 802.11 
networks though ...

-----N

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 15 Oct 2002 15:26:55 -0700

inline

> From: Alper E. YEGIN [mailto:[email-masked]] 
> Sent: Tuesday, October 15, 2002 3:12 PM
> To: [email-masked]; 'Pekka Savola'
> I don't think we can consider all "handoffs" as 
> 'make-before-break'. There exists some link-layer 
> technologies that allow this, but not all have such capability. 

Then DAD latency should be the least of the concerns. 

> 
> Completing DAD before handover requires either movement 
> anticipation or make-before-break, both of which are not 
> widely applicable. Therefore solving DAD latency for general 
> case is a valid approach, imo.

My argument is that all MNs anticipate movement, and establish DAD
before they really make the move. Yes this will generate some overhead
if the node doesn't move, but that is a minor cost in the grand scheme
of things.

Tony 

> involved 
> > > > > in

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 15 Oct 2002 15:43:29 -0700

> Then DAD latency should be the least of the concerns. 

Not really. For example 802.11b (link-layer) handover can take
something like 200ms, and DAD would take 1sec on that link. 
People are already working on shrinking link-layer handover
latency, and some should do the same for DAD as well.

> if the node doesn't move, but that is a minor cost in the grand scheme

We cannot assume all MNs can "anticipate movement". Not all link-layers 
have this capability.

alper

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 15 Oct 2002 16:20:46 -0700

Alper E. YEGIN wrote:
> ...

A MN 'can anticipate movement' because that is what it does by
definition. What it may not be able to figure out is the candidate list
of where it may end up. The fact that some link layer implementations
have chosen not to expose knowledge of potential alternatives is
possibly due to a lack of requirements to do so. I know the 802.11
implementation I am using is fully aware of the candidate set of layer 1
associations, though it doesn't attempt to bind the IP stack until I
select one. It would be easy for it to bind IP to all, but prioritize to
the selected one until it was out of range. If it did so, all possible
destinations could have run a full DAD in the background, well in
advance of the move.

Even if the MN implementation chose not to associate with all possible
layer 1 neighbors, the ones it does have an association with will also
be able to hear a partial list of the candidate set, and could provide
that to the MN if the implementation provided a path from the layer 1
receiver to a control plane process. 

It is true that a standards effort can not assume that all
implementations will provide a full spectrum of capability, but it is
also true that it MUST NOT assume that ignoring a collision avoidance
system will not really do any harm. If people want to be mobile, but a
specific link-layer doesn't provide the tools to make that work
correctly without problems, the link-layer will fade from the market
place. 

Tony

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 15 Oct 2002 19:57:03 -0700

Tony,

> of where it may end up.

What I really meant was this second one..

> The fact that some link layer implementations
> associations,

..by listening to the baecons. But even that would require your wlan
card to scan all the channels. They don't normally do that, until
they really have to (i.e., current radio conditions are deteriorating),
or your management application tells it to do so, because while scanning,
it has to hold the data traffic. A card usually has only one transceiver.

> though it doesn't attempt to bind the IP stack until I

I don't think this is as easy as it sounds. Your MN has to:
- collect a list of candidate access points (a costly scanning operation)
- somehow map this information to associated prefix information, and an
  agent on the associated IP subnet (how?)
- send a proxy-DAD request to that server (this protocol needs to be
defined)
... and make sure this process concludes before your MN has to handover.

> system will not really do any harm. If people want to be mobile, but a

Sure. Actually, my comment is not against what you are saying here.
I guess an approach like a proxy-DAD can be a candidate solution
to this problem. Another candidate is server-based DAD that I'm
currently working on. It involves a server keeping track of
currently used IP addresses on a subnet, and assisting mobiles
that know how to consult this server.

alper

---

From: Greg Daley <[email-masked]>
Date: Wed, 16 Oct 2002 14:24:20 +1000

Hi Alper,

> that know how to consult this server.

Certainly Optimistic DAD is not particularly useful until you
actually get to the link, but I think it provides a good
fallback behaviour for mobile devices on networks which
aren't willing to keep state.

Stateful mechanisms are certainly more of a candidate for
predictive and non-local address acquisition (may be matched
with Predictive (Fast) Handovers, Hierarchical MIPv6).

These are infrastructure based solutions though.  MIPv6
principally operates on a low-infrastructure access network model.

Optimistic DAD requires implementation only in the current node,
and works with a predictable worst case performance on stock
RFC 2461/2462 networks without additional support.

I'm not sure which systems will gain a following, but I think
that DAD's current 'timeout == success' philosophy will not
stay around long.

Greg Daley

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Oct 2002 12:54:34 +0300 (EEST)

On Tue, 15 Oct 2002, Nick 'Sharkey' Moore wrote:

A few comments on some portions of the draft.

On the general approach, first:

 1) the draft needs to spell out much more clearly how the modifications 
to RFC2461/RFC2462 (and whether they have been done) affect on the 
behaviour on the links where there have or haven't been upgraded nodes.

 2) I'm not sure if this is the right approach.  Something better suited
could be found, I believe, in adding functionality to first-hop routers'
ND cache behaviour; a router could answer directly which could be
interpreted like "don't use that address, I just recently saw it used here
by another node.. but if you're really sure you want it, perform DAD as
specified in RFC2461/2".

Two particular nits:

1) [DUPONT] has had a revision.

2)

   Optimistic DAD is a useful optimization because DAD is far more 
   likely to succeed than fail, by a factor of at least 10,000,000,000
   to one[SOTO].  This makes it worth a little disruption in the failure
   case to provide faster handovers in the successful case, as long as
   the disruption is recoverable.

==> this is totally, and completely wrong.  [SOTO] only provide analysis 
in *some* cases, in particular autoconfigured vs privacy addresses.  For 
manually assigned addresses, I believe the ratio is closer to 1:10 or 
1:100 (unmeasurable, of course).

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Fri, 18 Oct 2002 08:41:34 +1000

On Thu, Oct 17, 2002 at 12:54:34PM +0300, Pekka Savola wrote:
> in *some* cases, in particular autoconfigured vs privacy addresses.

I see what you mean. I need to make it clear that [SOTO] and I are
referring to strongly random addresses ... this is a requirement
for my Optimistic DAD draft anyway for exactly this reason.

Do you this it is fair to say:

   DAD is far more likely to succeed than fail FOR RANDOMLY
   AUTOCONFIGURED ADDRESSES, by a factor of at least 10,000,000,000
   to one[SOTO].

Do you think it would be advisable for me to add:

   Optimistic DAD MUST NOT be used for manually configured addresses

... because as you point out, manually configured addresses are
far more likely to fail and being a MobileIP type I'm mainly 
interested in configuring CoAs anyway.

> For manually assigned addresses, I believe the ratio is closer
> to 1:10 or 1:100 (unmeasurable, of course).

I'd be really interested to know if anyone has any indicative
figures on MAC address collision: it is inevitable that somewhere
out there there are two adaptors with the same MAC address due
to human frailties, but how many?

Thanks for your feedback!

-----Nick

---

From: Pekka Savola <[email-masked]>
Date: Fri, 18 Oct 2002 08:48:46 +0300 (EEST)

> for my Optimistic DAD draft anyway for exactly this reason.

Yep.
 
>    AUTOCONFIGURED ADDRESSES, by a factor of at least 10,000,000,000

This sounds rather good, using the lower case, of course.  What's included 
in "randomly autoconfigured addresses" is a bit blurry, though.  Is it 
RFC3041 only?  Does it include EUI64-based schemes, etc?
 
> interested in configuring CoAs anyway.

That is sounds good to me.  I'd also add a line of reasoning behind that, 
like:

 Optimistic DAD MUST NOT be used for manually configured addresses,
 as those are much, much more likely to have collisions.
 
> to human frailties, but how many?

I don't have figures but Francis Dupont reported this happening once to 
him.

It should also be noted that people *do* change MAC addresses manually 
(possibly leading to clashes), e.g. in internet exchange points per policy 
and in e.g. access lines (e.g. xDSL) if ISP expects to see only one MAC 
address.  But these aren't usually a shared medium or config'd addresses 
are used, so this may not be that big a problem.

Vendors who ship e.g. 4-port Ethernet adapters (e.g some Sun products)  
with the same mac address in each port are problematic of course (and this 
isn't the first time -- switches usually don't like it:-).  If you connect 
two ports to the same segment..

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Fri, 18 Oct 2002 17:35:19 +1000

On Fri, Oct 18, 2002 at 08:48:46AM +0300, Pekka Savola wrote:
> 
> This sounds rather good, using the lower case, of course.

Of course. I'll clarify the details for -01. Thanks for your
feedback.

> (possibly leading to clashes)

NCD Xterms come to mind too, although these are unlikely to
be seen on Mobile Networks Of The Future :-)

-----Nick

---

From: Ignatios Souvatzis <[email-masked]>
Date: Fri, 18 Oct 2002 10:21:57 +0200

> (tentatively titled draft-moore-ipv6-optimistic-dad-00).

I've just looked at
http://www.ctie.monash.edu.au/ipv6/draft-moore-ipv6-optimistic-dad-00.txt

I've not decided yet whether this is a good idea at all (long thread to
read), but there is a terminology error that should be corrected before use:

2.3 Address Generation

[...]

   * A randomly generated address SHOULD have the Universal/Local bit
        and the Individual/Group bit set to 0 to indicate a locally
        scoped Unicast address (see [RFC2373]).

s/locally scoped/not globally unique/

Regards,
	Ignatios Souvatzis

---

From: Tim Chown <[email-masked]>
Date: Fri, 18 Oct 2002 09:58:18 +0100

> I don't have figures but Francis Dupont reported this happening once to 

I believe in some cases some cheap "clone" NICs would be mass-produced
with the same MAC address, (the cloner doesn't care to honour the uniqueness)
but hopefully this is rare.  However, the units may be likely to end up at 
one site if bulk-bought from a reseller.

There are three levels of probability - the random/privacy addresses across
all 64 bits, the EUI-64 addresses (where due to vendor MAC prefix pools only 
the lower 24 bits may change) and manual addresses.

> two ports to the same segment..

Is that common?

Tim

---

From: [email-masked]
Date: Fri, 18 Oct 2002 18:04:53 +0900

>> two ports to the same segment..

	for load sharing (like having 400Mbps bandwidth rather than 100Mbps)
	yes.

itojun

---

From: Vladislav Yasevich <[email-masked]>
Date: Fri, 18 Oct 2002 13:18:57 -0400

Nick

I haven't made up my mind yet about this draft,
but here are some comments.

  - Sections 2.1 and 2.2 are not very clear.  For example, in
section 2.2 there are two bullets that modify section 5.4.3,
but these 2 bullets are very ambigiouse as to what parts of
[rfc2462 sec. 5.4.3] they apply to.  It would be better if
the draft spelled out the particular modified behavior.

  - Section 3.1 of the draft states:

    > ...        Since the Optimistic Node already has the link-layer
    > address of the router, and the router now has the link-layer address
    > of the Optimistic Node, communications can begin immediately.

    Where are these link-layer addresses taken from?

    The router will ignore both NS and NA for the following reasons:
     - NS is send  without the Source Link-Layer Address option.
     - NA is sent with the O-bit = 0.  If the router does not have an
       entry for this address (most likely), it "SHOULD" ignore the NA
      (2461).

    The only place so far the node can get the address of the router is from
    the RA, but Source Link-Layer Address option is optional in RAs
    (it's a MAY in 2462).

- Section 3.2:

   For the simple case, there is a very minor effect on the operation
   of non-optimistic nodes.  An optimistic node will force the state
   of all REACHABLE entries to transition to STALE and may force NUD.
   This is a very minor effect, but it should be noted.

   Also, the initial delay of the first NUD probe is 5 seconds which is
   rather substantial amount of time that the packets may be blackholed
   in the case of proxy NAs.

-vlad
-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 18 Oct 2002 10:30:55 -0700

> to human frailties, but how many?

Another possible source of collision would be people
changing their mac address each time they change access
network for privacy reasons  (to prevent one form of
tracking).

alper

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 18 Oct 2002 17:26:22 -0700

Pekka,

> by another node.. but if you're really sure you want it, perform DAD as

This is the approach I've been looking at. But there is a problem.
Nodes that implement the required ND extension can explicitely
inform the router about their IP addresses. Router can learn about
others (i.e., regular DAD hosts) via listening to multicast NSs for DAD.
No problems so far...

But when a router starts with no state (a new one, or rebooting
after crash), it might never learn about regular nodes that
have already done DAD.

So, unless this problem is solved, the applicability of this
solution is limited to networks where all nodes support the
required extensions.. Any ideas?

> 1:100 (unmeasurable, of course).

I must be missing something.. How come this probability is so high?

alper

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Sat, 19 Oct 2002 11:22:41 +1000

> the draft spelled out the particular modified behavior.

Okay, I'll look into making this less ambiguous. The difficulty is
that the changes are relatively small compared to the main text
(eg, 2461/2462), and so I've tried to emphasize the changes rather
than providing the full rules and making people work out the 
difference!

>      - NA is sent with the O-bit = 0.

Well, more to the point, S=0. So if it doesn't have an entry, it will
most likely ignore it.

Hesham points out that this is probably an assumption of Fast Handovers
type behaviour on my part: guilty as charged. There's nothing more
effective than peer review to find your assumptions!

In the Fast Handovers case, the router probably has some traffic waiting
for the MN. I'll consider more carefully what will happen if this is
not the case and post again on Monday.

>     the RA, but Source Link-Layer Address option is optional in RAs

Ummm. Interesting. 2461 says "A router MAY omit this option in
order to enable inbound load sharing across multiple link-layer
addresses.", but I'll admit I'd never considered it!

>    This is a very minor effect, but it should be noted.

A NA with S=0,O=0 for a REACHABLE entry will have no effect on the
entry according to the Appendix C state machine, and these are the
only NAs which the ON will sent to All Nodes which Tentative. 
Admittedly an NA with S=1,O=0 will reset a REACHABLE entry to STALE,
but why is the correspondent soliciting for a REACHABLE entry?
(Or have I missed something elsewhere?)

>    in the case of proxy NAs.

Yep. That's probably the worst outcome on the list, but I think
it is acceptable as it is both unlikely (new connection on colliding
address) and recoverable (by NUD). 

Thanks for your feedback ... you've certainly given me lots to 
think about on Monday!

-----Nick

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Sat, 19 Oct 2002 11:35:51 +1000

On Fri, Oct 18, 2002 at 05:26:22PM -0700, Alper E. YEGIN wrote:
> Pekka Savola wrote:
> > ND cache behaviour;
> This is the approach I've been looking at. But there is a problem. [...]

My colleague Greg Daley has been working on the same problem
(eliminating DAD) from this direction: see draft-daley-ipv6-mcast-dad-01.txt

> have already done DAD. [...]  So, unless this problem is solved,
> the applicability of this solution is limited to networks where
> all nodes support the required extensions.. Any ideas?

This is my concern too: my aim with my draft was to work out a 
possible solution where totally unmodified nodes would interoperate
correctly.

> > For manually assigned addresses, I believe the ratio is closer to
> > 1:10 or 1:100 (unmeasurable, of course).
> 

Humans have remarkably lousy RNGs!  I'm willing to believe Pekka 
on this one, because I've had many experiences with people assigning
static V4 addresses ... "hey, we're up to x.y.z.57 aren't we? It's
not in /etc/hosts on _my_ workstation ..."

-----Nick "... hey, look, there's nothing registered to x.y.z.255 either!"

---

From: Pekka Savola <[email-masked]>
Date: Sun, 20 Oct 2002 02:33:56 +0300 (EEST)

On Fri, 18 Oct 2002, Alper E. YEGIN wrote:
[...]
> I must be missing something.. How come this probability is so high?

It's due to the fact how manually assigning works.  There are two factors:
 1) IID assignment ("which address to use")
 2) configuration  ("avoiding typos")

It is natural that people doing manual configuration will try to prefer 
IID's like ::1, ::2, ::53, ::x etc. and there are much more likely to be 
conflicts there; also one should never underestimate the power of fat 
fingers :-)

---

From: Vladislav Yasevich <[email-masked]>
Date: Mon, 21 Oct 2002 10:27:48 -0400

Nick

> than providing the full rules and making people work out the 

If you would just quote the sentences or paragraphs you wish to modify,
it will clear things up.

> (Or have I missed something elsewhere?)

Hmm.  Here is a quote from rfc 2461, section 7.2.5:
    "If the target's Neighbor Cache entry is in any state other than
     INCOMPLETE when the advertisement is received, processing becomes
     quite a bit more complex.  If the Override flag is clear and the
     supplied link-layer address differs from that in the cache, then one
     of two actions takes place: if the state of the entry is REACHABLE,
     set it to STALE, but do not update the entry in any other way;
     otherwise, the received advertisement should be ignored and MUST NOT
     update the cache."

It doesn't state anything about the the 'S' bit.

> Thanks for your feedback ... you've certainly given me lots to 

You are welcome.

-vlad

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 22 Oct 2002 13:30:04 +1000

On Mon, Oct 21, 2002 at 10:27:48AM -0400, Vladislav Yasevich wrote:
> [Nick Moore wrote:]

Ah, I see what you mean. RFC 2461 contradicts itself then, since
Appendix C states:

| !INCOMPLETE     NA, Solicited=1,        Record link-layer     REACHABLE
|                 Override=1              address (if
|                                         different).
| 
| !INCOMPLETE     NA, Solicited=0,        -                     unchanged
|                 Override=0
| 
| !INCOMPLETE     NA, Solicited=0,        -                     unchanged
|                 Override=1
|                 Same link-layer
|                 address as cached.
| 
| !INCOMPLETE     NA, Solicited=0,        Record link-layer     STALE
|                 Override=1              address.
|                 Different link-layer
|                 address than cached.

Now, I understand that the main text would generally trump a
mere Appendix, but the appendix rules seem to me to make more
sense. My draft is based on the Appendix C rules so yes, I'd
have to rethink a few things based on 7.2.5.

Would one of the RFC2461 authors like to comment?

-----Nick

---

From: Greg Daley <[email-masked]>
Date: Tue, 22 Oct 2002 14:47:37 +1000

Hi Alper,
Sorry about the delayed response.

Possibly unhelpful responses below...

> required extensions.. Any ideas?

With the mld-dad approach, the assumption is that all nodes
will do MLD on subnet-local multicast addresses, and thus
all nodes participate (to some extent) in the MLD reporting
and query mechanisms defined by the RFC2710.

Since MLD is a node requirement (good or bad) this is possible

The issue with using ND based mechansims is that there's no
generic query which all hosts (or a sufficient subset, as in MLD)
will be guaranteed to respond to. In this case, the system
cannot rebuild state from restart (nor necessarily converge to
full state in a finite length of time, unless nodes can be
prompted to send packets.

Few (all or even many nodes) multicast packets in ND can cause
a response, except for missing (lifetime 0?) router
advertisements.

In these cases, where the router lifetime is zero, or no
multicast packets are received, a node will send an RS,
although I don't know the effect on traffic from the nodes.
(Nasty Hack I know).

Greg Daley