Subject: RE: MIPv6 and ND value changes

From: [email-masked]
Date: Tue, 19 Nov 2002 05:48:28 +0200

Hi Erik,

> So while I don't want to slow down the MIPv6 specification or the
> implementation and deployment, I think breaking out these pieces will help
> with specification and protocol modularity, which makes it easier and quicker
> to revise the specifications along the standards track etc.

So, perhaps my comment is a bit naive, but as the changes have been
discussed in the MIP WG and many people think the changes are 
sane in the IPv6 WG ... I wonder what would be accomplished by
breaking them out in a seperate document.  Since the IPv6
WG will be working updating ND, could not the MIPv6 draft 
make the recommendations and then these recomentations be taken
as the starting point for the ND discussions in the IETF?

John

--------------------------------------------------------------------
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: "James Kempf" <[email-masked]>
Date: Tue, 19 Nov 2002 04:45:13 -0800

John,

The primary issue is whether the ND spec itself should benefit.

The behavior of DAD failure is an example. RFC 2461 currently has a built-in DoS
hole in that it specifies the host should shut down the interface if there is a
DAD failure. This is a perfect opportunity for propagating a successful DoS
attack, and is not restricted to MIP.

By burying the solution for this into the MIP spec, it removes the possibility
that wider IPv6 nodes can benefit.

However, there are other proposed ND optimizations that are purely mobile
specific. Some of these are in the MIP spec, some aren't. I think it makes some
sense to group these into a seperate spec in the MIP group.

            jak

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Nov 2002 14:05:32 +0100 (CET)

> as the starting point for the ND discussions in the IETF?

I can see a focused technical discussion on a small problem statement
and a short document can actually result in better technical solutions.

For instance, instead of changing the fixed rate limit for solicited RAs
it make be a lot better to rate limit RAs using a token bucket filter.
That can handle the rate limiting when a bunch of machines that boot
after a power failure while still being very responsive to MNs that send
RSs to detect movement.

Also, it makes sense to point out that in the case where all the MNs can
get a link up/down indication there isn't a need to waste the bandwidth
of the frequent unsolicited RAs but instead rely on the MN sending an RS
then the link up indication shows up.

The point is that we could discuss the above agaist the MIPv6 spec, but
that would delay the spec.
If it was a separate 3 page spec we could do the technically right thing
without worrying about MIPv6 spec delays.

  Erik

---

From: Greg Daley <[email-masked]>
Date: Wed, 20 Nov 2002 04:41:01 +0000

Hi Erik, 

Sorry to reply so late on this,

The token bucket support indicated in your email
is already specified (and implemented) in FastRA.
In fact, there's not much more than that to the spec
(It is 3 pages).

I don't think that putting FastRA in MIPv6 was an option 
proposed by anyone, but I do think that the location
of the RA Advertisement Interval modification *is* important,
if yourself and Tom both believe it shouldn't be in MIPv6.

I guess we'll be discussing it tonight.

Greg