Subject: [mobile-ip] MIPv6 draft 19 and Einstein

From: "Greg O'Shea" <[email-masked]>
Date: Mon, 23 Dec 2002 13:10:25 -0000

"Things should be as simple as they can be, but no simpler." Albert
Einstein.

Looking towards implementing the provisions of 11.5.4 of draft 19 of a
148-page draft I could not help but recoil from the ugliness and
complexity resulting from "special case" hacks to otherwise stable and
generic mechanisms such as DAD and NS. I have a suggestion that would go
some way towards this. I hope it is not too radical for this time of
year. Thoughts welcome!

It seems to me that MIPv6 a significant simplification could be made to
the existing spec and implementations thereof, by requiring that home
networks are "virtual" networks to which nothing except Home Agent(s) is
ever directly attached. Networks are cheap in IPv6, so this is not
wasteful. For example a home network could be a virtual interface inside
a HA or in interface card to which no cable is attached. The only sense
in which a mobile can use the home network is through binding updates to
the Home Agent, so admission control is a "free" function of IPSec
between HA and MN. Address collision on the Home Network can no longer
occur, the HA no longer has to provide DAD or proxy or NC flushing on
home addresses, and the  hacks of existing NA and NA required for when a
MN return to its home can can all go.

If a physical home is required, then it is afforded by a foreign network
to which the HA is directly attached.

My initial thoughts are that nothing need be added to the existing draft
to obtain this simplification. On the other hand, based on a first
reading, here is a list of MIPv6 provisions that I think could be
removed:
* D bit processing by HA [6.1.7]
* L bit processing by HA [6.1.7]
* BA code 134 (DAD fail) [6.1.8]
* MN protection of LLA derived from HoA [7.7]
* HA performing DAD on Home Registration [10.3.1]
* mods to std NS for HA DAD on HoA [10.3.1]
* delay between BU and BA while HA completes DAD [10.3.1]
* HA defence of HoA and associated LLA [10.3.1]
* specific requirements re L2 address for dereg on home net [10.3.2]
* NA by HA to downdate onlink CN NCEs for home reg [10.4.1]
* retransmission of NA by HA on home net [10.4.1]
* HA acting as proxy for MN on home net [10.4.1]
* specific HA requirements for HA response to NA while acting as proxy
[10.4.1]
* specific handling of packets by HA sent to MNs LLA [10.4.2]
* special case hack of standard NS spec & implementations on MN [11.5.4]
* special case do / not do DAD on HoA by MN [11.5.4]
* special case NS between MN and HA [11.5.4]
* temporary supress NS/NA while await Home dereag  by MN [11.5.4]
* special case downdate onlink CN NCEs on home net by MN [11.5.4]
* rexmit of downdate onlink CN NCEs on home net by MN [11.5.4]
* L bit processing by MN
* D bit processing by MN
* concerns re stealing of HoA by some other node on home net [11.7.1]

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 23 Dec 2002 07:28:29 -0800

When a mobile node is on its home network, it does not need the
services of a home agent.  If it cannot be on its home network, then
it requires always a home agent, no matter what.  This would be a
terrible loss of functionality.  Such a restriction is not a new idea --
in fact, the same idea has been floated more than once even from
the very beginning of the mobile-ip working group.  At this point,
since the home agent function and the home network function has
been built and tested a lot of times, it seems to be a big step backwards.

Regards,
Charlie P.

Greg O'Shea wrote:

> generic mechanisms such as DAD and NS. I have a suggestion that would 
> go some way towards this. I hope it is not too radical for this time 
> of year. Thoughts welcome!
>
> It seems to me that MIPv6 a significant simplification could be made 
> to the existing spec and implementations thereof, by requiring that 
> home networks are "virtual" networks to which nothing except Home 
> Agent(s) is ever directly attached. Networks are cheap in IPv6, so 
> this is not wasteful. For example a home network could be a virtual 
> interface inside a HA or in interface card to which no cable is 
> attached. The only sense in which a mobile can use the home network is 
> through binding updates to the Home Agent, so admission control is a 
> "free" function of IPSec between HA and MN. Address collision on the 
> Home Network can no longer occur, the HA no longer has to provide DAD 
> or proxy or NC flushing on home addresses, and the  hacks of existing 
> NA and NA required for when a MN return to its home can can all go.
>
> If a physical home is required, then it is afforded by a foreign 
> network to which the HA is directly attached.
>
> My initial thoughts are that nothing need be added to the existing 
> draft to obtain this simplification. On the other hand, based on a 
> first reading, here is a list of MIPv6 provisions that I think could 
> be removed:
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 23 Dec 2002 15:14:02 -0800

> of year. Thoughts welcome!

section 11.5.4 can be simplified a bit, especially the following
paragraph.

> If the mobile node does Neighbor Solicitation to learn the home
>    agent's link-layer address, in this special case of the mobile node
>    returning home, the mobile node MUST multicast the packet, and in
>    addition set the Source Address of this Neighbor Solicitation to the
>    unspecified address.....

if the HA, in its router advertisments always includes a source 
link layer address option, the whole paragraph can be removed. 
according to RFC 2461, the source link layer address option is 
optional.

maybe we can mandate this in MIPv6 spec. "Mobile IPv6 Home Agents 
MUST include the source link layer address option in router 
advertisements". what do you think?

we always include the source link layer address option in our 
implementation.

Vijay

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 28 Dec 2002 10:30:59 +0200

Greg,

Greg O'Shea wrote:
> ever directly attached. ...

As I have expressed a few times before, in my (perhaps not so) humble
opinion MIPv6 has a number of fairly large architectural problems
that make it unnecessarily complex.  Unfortunately, the biggest one
seem to be related to the issue of separating the identifier and
locator functions of IP addresses.  That is such a large issue that
we can't possibly hope to solve it any time soon.  As you may know, that
issue has recently been discussed extensively at the multi6 mailing
list, to a smaller extend at the ipv6 (ipng) mailing list, and perhaps
also elsewhere.  There is also the IRTF NSRG report about the issue.

Against that background, I don't think it is worth the effort
to modify MIPv6 at this stage too extensively.  Instead, I sincerely
hope that MIPv6 will serve us for a few years, and that we will
eventually move to a better architecture with good separation of
identifiers and locators.

What comes to the your specific suggestion of making all home links
virtual, I think that it is a good and solid suggestion for future
work.  In a way, I would consider it as a small step to the eventual
separation of identifiers and locators.  If the home links are only
virtual, the home addresses become in some sense "virtual" addresses,
i.e. identifiers.  OTOH, they still remain locators in the sense
that they name a location, the virtual home location of the mobile
node.  Thus, that move would't make a clean separation, but IMHO it
would be a step towards the right direction.

Now, I wasn't at Atlanta, but according to the minutes it was proposed
that the mobileip WG is split into two, one part concentrating more on
mipv6.  Furthermore, the minutes state that one charter item for the
new mipv6 WG would be to split the MIPv6 spec into multiple,
simple specs.

To me it looks like your suggestion would make an excellent
starting point for splitting the MIPv6 spec.  Indeed, such a split
would probably allow some future implementations to be simpler than
the ones we need based on the current spec.  Thus, I would discuss
the suggestion with Gabriel, and consider it as a working item
for the new WG.

--Pekka Nikander

---

From: Jari Arkko <[email-masked]>
Date: Sat, 28 Dec 2002 11:39:59 +0200

> we always include the source link layer address option in our 

(Dealing first with the details before going to the big issue
raised by Greg.) Yes, Vijay, I think the simplification you
propose is a good one and we should use it.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Sat, 28 Dec 2002 12:05:03 +0200

I like Greg's simplified model a lot. This would
probably be the way that I would implement a
commercial-grade home agent.

Charlie, you argued that there's a loss of functionality
if the home agents are always required. I think you are
in part right, and in part Greg is right. Greg is saying
that you can bundle the HAs to the routers and if you
take away the routers then the network is dead anyway.
This is right, though there are some remaining cases where
it still makes a difference:

- When the HA functionality is not in the same box as the
   routers are. Then you could still be operational even if
   the HA was down.

- Even if the router/HA is down, current design allows you
   to communicate on the current link with your home address.
   The new design would not.

- In the current design, if you are at home and want to
   communicate with peers who are on the same network, you
   can do it directly, without establishing RO. In the new
   design, you'd have to establish RO and run RR all the
   time. Not a big deal perhaps, but you'd always have to
   do it.

Then a few observations about where the impacts of the
proposal are. For one thing, it appears that the current
specifications allow you to do this for the home agent.
Many of the benefits of this approach can be realized
with this, such as the ability skip DAD on the home agent
side. (Remember that we decided to remove the D bit
functionality already put to the burden on HAs.) Of
course, the MNs still need to prepare for the possibility
that they will end up on a home network, so not all
benefits can be realized. You might even argue that the
most important ones are on the MN side.

But what should we do with this proposal then? I does
have a lot of merit, but I'm tempted to agree with Pekka
that we should do it as a part of the splits that are
being planned for the MIPv6 "bis" version. Maybe the
"virtual home link HA" as the core of that spec, with
an optional add-on for those HAs that wish to offer a
physical home link... there are some question marks as
to what we can do on the MN side and how the MNs would
be able to skip the complexity. Anyways, I'm open to
suggestions here. What do others think?

I also think that we should adopt the simplification
that Vijay suggested for the next draft revision.

Jari

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 30 Dec 2002 13:05:39 -0800

Jari Arkko wrote:

> if the home agents are always required.

This was a specific reaction to the possibility that
mobile nodes would not have a home network available.

>                                         I think you are

I am 100% in favor of bundling home agents to routers.  The
sort-of original plan for IPv6 mobility was to have ALL
routers be home agents.  This didn't happen because it has
taken so long to get a Mobile IPv6 standard.  If it had been
done 4 years ago, we might have a different model.  This is
unfortunate, that the delay can make such a tremendous difference
in a protocol that was designed to be scalable into the distant
future, but that's the breaks.

Anyway, what I got was that Greg was saying something quite
different.  The characterization you present, is something
that I am completely in agreement with.

>    routers are. Then you could still be operational even if

This would still be the case if there were multiple
home-agent/router boxes.  What you point out is that having
multiple boxes buys continued operation.

>    The new design would not.

Again, this is a matter of redundancy, not so much anything
central to Mobile IPv6.

>    time. Not a big deal perhaps, but you'd always have to

It is a sufficiently big deal that I think it would be a travesty
to lose this functionality.  It is particularly a big deal for
mobile nodes with wireless AND wired interfaces, because
home agents should not be pumping out data for thousands
of mobile nodes at multi-Gb/s rates.  A wired mobile node
on its home network should certainly feel entitled to service
at multi-Gb/s rates.

> functionality already put to the burden on HAs.)

This issue is not closely related, I don't think.

>                                                     Of

???  I think that would be a highly questionable argument
by any performance criterion.  Plus, the "extra" stuff a
mobile node has to do (besides DAD and so on) is not so much.

> suggestions here. What do others think?

It's a matter for discussion.  However, I was a bit
surprised by this phrase:
       ...splits that are being planned for
          the MIPv6 "bis" version...
I was not aware of this planning process, unless you
meant some casual bits of conversation that have
randomly floated around.

If there is going to be such planning, I think we should
delay it until after Mobile IPv6 gets through IETF
last call.  Otherwise, we are likely to get in a rut.

Regards,
Charlie P.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 30 Dec 2002 23:42:02 +0200

> on its home network should certainly feel entitled to service

Yes. Good argument.

> mobile node has to do (besides DAD and so on) is not so much.

Fair enough. I agree that performance-wise HAs have more
impacts, even perhaps complexity-wise MNs get hit too.

> last call.  Otherwise, we are likely to get in a rut.

Of course. No, this isn't anything that would be done now.
An idea has just been floated around that once MIPv6 is an
RFC, its update from PS to DS could also include a split into
a few smaller documents.

Jari

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Dec 2002 13:59:44 -0800 (PST)

> the suggestion with Gabriel, and consider it as a working item

I think that the IPsec/IKE experience argues
exactly the opposite: having too much "modularity"
in the documents leads to confusion, not
enlightenment. To my mind, it's better to have a
single document that does at least one useful
standalone function.

		Mike

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 30 Dec 2002 18:30:35 -0600

Bundling or colocating HA with the router is OK and it would lead to 
some savings such as no proxy NDs as implementation details as opposed 
to non-standard HA. What Greg proposed OTOH was, I  think, non-standard HA.
Ideally in wireless networks one needs to have a scalable HA, get a 
heavier HA as MIP MNs increase. This probably can not be achieved purely 
by colocation.
Regarding the split spec issue, I do not see anything wrong with having 
an HA spec. HA runs a specific state machine which could be specified 
separately.

Regards,

-- 
Behcet