Subject: Re: New idea for Router Sol/Adv and Mobility - NO new types

From: Erik Nordmark <[email-masked]>
Date: Mon, 5 Mar 2001 10:52:04 +0100 (CET)

> >> 1. The TTL of RS is < 255, which tells the HA it is from off-link.
> > 
> > Or a spoofed RS. When a router receives a spoofed RS it would presumbly
> > log an event and/or increase a counter.
> > With your overloading proposal it can't tell the difference
> > between a spoofed one and a mobile node using an RA.
> 
> Enlighten me, how exactly does creating a new message type solve this
> problem? It seems to me that it just shifts it to a different ICMP #.

It doesn't make the spooing issue go away (I didn't claim it did)
but allows the current rules for the current ICMP types to stay unchanged
including any logging of ttl < 255 packets.

The new message types need to have rules that deal with spoofing one
way or another. But this might e.g. be to mandate some IP level security
mechanism for all messages having the new types.

  Erik

--------------------------------------------------------------------
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: Mon, 5 Mar 2001 17:40:16 -0800

On one hand I agree with Erik that new types are better than overloading the
semantics unnecessarily. The basic problem I am having with this thread is
understanding the problem it is trying to solve. Since the HA is required to
be in all possible routing paths to my home subnet (else some parts of the
world will never contact the node when it is mobile), it has to be a
function of the last hop router. The premise of this proposal was that the
MN would need to ask the HA for a prefix so it could configure its home
address. Since it knows (presumably via configuration) the address of the
HA, (and given the HA has to be in the routing path) it already has a
useable prefix. I have always assumed that the MN is configured with its
home prefix, then it would use the all-routers anycast address to find the
HA. In this case the proposed messages are unnecessary. Clearly I need a
picture to understand why the MN would know its HA, but not its home prefix.

Tony

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Erik Nordmark
Sent: Monday, March 05, 2001 1:52 AM
To: T.J. Kniveton
Cc: Erik Nordmark; Mattias Pettersson; Powell, Ken;
[email-masked]; [email-masked]
Subject: Re: New idea for Router Sol/Adv and Mobility - NO new types

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 6 Mar 2001 09:16:57 +0100 (CET)

> Clearly I need a

While the MN must know at least one home prefix it might not know all of them
in  particular it might not know about any new prefixes that have been
introduced  while the MN was away from home.
So it needs to be able to get the complete list including the current
lifetimes for the prefixes.

Of course, if all the home prefixes that the MN knows expire due to
renumbering then the MN is in deep trouble.

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Tue, 06 Mar 2001 10:48:43 +0100

In your previous mail you wrote:

=> this thread was completely messed by the mobile-ip mailing list bug:
I believe a summary is needed in order to understand ideas and
their chain.

   On one hand I agree with Erik that new types are better than overloading the
   semantics unnecessarily. The basic problem I am having with this thread is
   understanding the problem it is trying to solve.

=> look at my intro (:-).

   Since the HA is required to be in all possible routing paths to my
   home subnet (else some parts of the world will never contact the node
   when it is mobile), it has to be a function of the last hop router.

=> not exactly. The Home Agent (HA) must be attached to the home link.
If the home link doesn't physically exist then (and only then) your
statement applies.

   The premise of this proposal was that the MN would need to ask the
   HA for a prefix so it could configure its home address.

=> the issue is home link renumbering, in particular when the Mobile
Node (MN) is down for a very long period. This is a real problem
but there are far more important problems, for instance the abyssal
performance of secure mobile IPv6 when a MN is booted in visit
(of course having to learn the HA address and the home address will
not improve this).
 This thread assumes that:
  - the home link is often renumbered
  - DNS is not available in the visit network (if it is available
    then you need only to configure a name as proposed by Compaq folks)
  - home AAA is not available (if it is available then HA and home address
    allocation may/should be done by AAA)
  - statefull autoconfig will never be available!

   Since it knows (presumably via configuration) the address of the
   
=> there is a dedicated anycast address for HAs (because if HAs are routers,
not all routers are HAs).
 I agree this topic is a secondary one and we should throw it into the
for further studies stuff. Of course, I'll strongly object if this is
slowing down the mobile IPv6 draft (BTW, is there an I-D 14?).

Thanks

[email-masked]

---

From: root <[email-masked]>
Date: Tue, 06 Mar 2001 12:19:24 -0800

> I believe a summary is needed in order to understand ideas and

You might be able to find the thread on the IPng group since I crossposted there.
My message which describes the problem is "New idea for Router Sol/Adv and
Mobility," which should fill you in.

If you can't find that, let me know and I will forward some of the messages to
you.

>    HA for a prefix so it could configure its home address.

Although you might be able to configure *an* home address using the router's
prefix, you are supposed to be able to configure *all* home addresses while away
from home. The value of this flexibility is debatable, but it certainly seems like
a good thing to be able to configure at least more than one address.

> (of course having to learn the HA address and the home address will

There is a couple of issues. The home link being renumbered while the MN is off,
is a subject that I have filed into "for future study" under the rubrick "Mobile
Node Bootstrap Problem." However, this thread addresses a more specific problem,
which is that Tunneled Router Advertisements, as currently defined in the draft,
a. Will *not *work when a MN does not yet have its Home Address
b. Add an IPv6-in-IPv6 encapsulation header which is unnecessary

There may be more reasons, but these two, especially (a), are probably sufficient
to merit solving this problem now (IMHO).

>   - statefull autoconfig will never be available!

Sorry, I may have mixed the discussion of these two issues -- mobile bootstrap
(for which you did a good job of describing the assumptions), and fleshing out the
Tunneled Router Adv/Sol as my original message in this thread describes. It is
also noteworthy that the latter does not solve the former, though they are
connected; future work is necessary to come up with a general, palatable solution
to bootstrapping.