Subject: RE: [DNA] RE: Review of link-information from Pekka Savola

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Tue, 03 May 2005 07:30:50 +0200

> I meant to say, the host does not know whether there is an
IPv6-enabled
> router on that link or not.... So, it's not a local host
configuration,
> but a network configuration which can only be dynamically discovered
> (but not necessarily via the link up notification).

That's true.

I think IPv6 DNA and IPv4 DNA (or whatever it's called -- zeroconf?)
should be separate processes both making their own decisions and when a
link up notification is received it should be sent to both DNA
processes. If IPv6 DNA runs on an interface that is not connected to a
network with an IPv6-enabled router, the process will naturally fail in
which case hopefully the node will get an IPv4 address. The node can
naturally also be connected to a network with both address spaces.

/Tero

---

From: Jari Arkko <[email-masked]>
Date: Tue, 03 May 2005 11:29:45 +0300

Tero,

>naturally also be connected to a network with both address spaces.
I tend to agree with this.

There are two possible ways to look at this, either you have
a synchronized procedure or you simply do both. Considering
that IPv4 DNA appears to be using different sets of messages,
it makes more sense, imho, to keep the processes completely
separate as there does not seem to be any optimization gains
in sight.

And yes, IPv6 DNA can fail and then you don't have IPv6 connectivity
on that link. (I hope all the DNA documents explicitly talk about
this case and how to deal with it. Knowing that you have no connectivity
can be as important as knowing you have moved.)

--Jari

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 03 May 2005 10:20:38 -0700

> I think IPv6 DNA and IPv4 DNA (or whatever it's called -- zeroconf?)

draft-ietf-dhc-dna-ipv4-11.txt

> naturally also be connected to a network with both address spaces.

I haven't thought much about the dual-stack host doing DNA.

Given that DNAv4 relies on DHCP and DNA for IPv6 handles stateless 
address autoconfig, it seems easiest to pass the 'link up' notifications 
to each of them independently. That would work, albeit a bit ineffecient 
when the IPv4 links are congruent with the IPv6 links (i.e., if you stay 
on the same link as before for IPvX you also do that for IPvY. Likewise 
if you move for one, you move for the other.)

Jari suggested that we should be able to detect when a host moves from a 
dual link to one which only supports one version of IP, and disable the 
IP protocol which isn't available.
This seems a bit scarier to me. While we want DNA to operate efficiently 
and quickly, so that it can find a new working address and trigger 
Mobile IP style signaling when it has moved, the act of turning off IPvX 
is a lot more disruptive; unconfiguring all the IPvX addresses and 
blowing away all the connections that used them can't easily be undone.

And it might be that the host moved to a link with no IPvX support for 
just a few seconds, and then moves back to a link where IPvX is available.

Perhaps there are anaogous cases for a single IP version when there is 
no mobility signaling protocol used on top; in that case it might make 
sense to keep the old connections around, just in case the host will 
move back to the old link a few seconds later.

    Erik

---

From: Jari Arkko <[email-masked]>
Date: Tue, 03 May 2005 21:04:32 +0300

Hi Erik,

> address autoconfig, it seems easiest to pass the 'link up' 
> notifications to each of them independently. That would work, albeit a 
> bit ineffecient when the IPv4 links are congruent with the IPv6 links 
> (i.e., if you stay on the same link as before for IPvX you also do 
> that for IPvY. Likewise if you move for one, you move for the other.)

Hmm... perhaps there are optimization gains available after all.
I was thinking mainly of the initial case of a new link, this seems
to need a parallel process on both IP versions, since different
mechanisms are used. But on subsequent hints that say "we may
have moved", the fact that IPv4 DNA says we have NOT moved
might be taken as an indication that we don't need to do the IPv6
DNA process.

On the other hand, if it turns out you have moved, then you may have
lost some time as you could have already sent the RS.

> Jari suggested that we should be able to detect when a host moves from 
> a dual link to one which only supports one version of IP, and disable 
> the IP protocol which isn't available.
> This seems a bit scarier to me. While we want DNA to operate 
> efficiently and quickly, so that it can find a new working address and 
> trigger Mobile IP style signaling when it has moved, the act of 
> turning off IPvX is a lot more disruptive; unconfiguring all the IPvX 
> addresses and blowing away all the connections that used them can't 
> easily be undone.

I admit it sounds scarier. But I didn't actually intend to turn off
IPv6 altogether if you hit a link that doesn't appear to be doing v6.
Just v6 on that link! The situation is similar to detecting a "link down" on
an interface. If you have other interfaces, you keep on using them.
(Or you turn on your other interfaces because of this; this is one
of the reasons why you'd want to know you have no IPvx service.)
If you do not have any other interfaces, you hold on to your session
state and addresses for a while, in case things change for the
better. Finally, home addresses and sessions on top of them should
survive in any case.

(Observation: all this seems more complicated than I thought at
first sight. Probably time to write this up somewhere, if not yet
done.)

--Jari

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 03 May 2005 14:15:26 -0700

> might be taken as an indication that we don't need to do the IPv6

Of course the IPv6 DNA process will be faster than the IPv4 one, so you 
got this one backwards :-)

> lost some time as you could have already sent the RS.

Good point.

> better. 

But the tradeoffs are tricky, because it depends on interactions between 
the inability to predict whether the host is going to move again, and 
the behavior of the application/user.

For example, assume no mobility protocol on top and a single IP version 
being used.
When the host detects that an interface has moved to a new link then,
if this is more or less permanent, it makes sense to immediately tell 
the applications that there connections are gone, so that the 
applications (or user) can attempt to reestablish communication, which 
will automatically prefer the IP addresses for the new link.

But, if there is some probability of soon moving back to the old link, 
it might make sense to not tell the applications that their connections 
are dead, since, should the move back happen before the transport 
protocol, application, or user gives up, things would just start working 
again after the move back.

However, if the transport protocol, application, or user have timeliness 
constraints, even if there is a chance of moving back to the old link,
it makes sense to tell such applications that things are dead and they 
should reestablish communication.

> Finally, home addresses and sessions on top of them should
> survive in any case.

Agreed.
When we have something like MIP which can repair things on top, then we 
don't have to get into understanding the desired behavior from the 
applications' and user' perspective.

> first sight. Probably time to write this up somewhere, if not yet

I'm not aware of anybody that has started to write this down.

   Erik

---

From: Greg Daley <[email-masked]>
Date: Wed, 04 May 2005 15:13:18 +1000

Hi Erik,

> Tero Kauppinen (JO/LMF) wrote:
[chop]
> I haven't thought much about the dual-stack host doing DNA.

I think we've tried to avoid it sometimes...

> if you move for one, you move for the other.)

That's fine until someone spoofs ARP,DHCPv4 and the IPv4 subsystem tells
SEND that a link change has occurred.

There are some subtleties with regard to trust models which mean that
indications from other layers (Transport, Link-layer or another network
layer) should be treated as hints in most cases.

It may be possible for a sufficiently trusted subsytems on one box to
indicate that there's no IPvY service, but that's still just a strong
hint.

I think I've heard ideas for DHCP to provide IPv4 and IPv6 addresses,
but unless you have reason to believe that this is an available service,
the same costs in delay and messages are incurred as trying to contact
a MIPv4 Foreign agent in DNAv4 (don't rely on it in general).

> IP protocol which isn't available.

Well, that is if IPv4 was switched on in the first place... :)

> blowing away all the connections that used them can't easily be undone.

I guess that there may need to be a parking for native support.

There's been talk about mobility signalling or auto tunneling when
native IPvX or IPvY is not available.

If you can't get packets, perhaps 'switching off' is bit bucketing
data (or buffering until it's useless and then dropping it), rather than
IP subsystem restart.  After all: 127.0.0.1 should still work.

The way that existing hosts do IPv4 and manage addresses though, it may
be a valid fallback mechanism to deconfigure the address and send 
messages to processes which listen to them.  This assumes that only
garden variety IPv4 is in use, with no support for mobility or long term
disconnection.

This would possibly be better done with the complicity of upper-layers 
though (perhaps through flow control).

> just a few seconds, and then moves back to a link where IPvX is available.

This is possible for contact via LEO satellites, for example.

Parking the connection state makes best sense, rather than
losing state.

Agreed.

There's likely to be a pain threshold for applications though.
If the arrival on a non-supporting link is indicated, it may be possible
to set up a tunneled or transition link to a native service.

Perhaps it's worthwhile looking at some of these ideas with the
remains of the zeroconf team, who are sure to have looked at this
(moving to networks with no service).

Particularly, if IPvY-only networks are available, does that mean you
should pick up a link-local IPvX address?

What does that mean for IPvX applications?

When do we resort to transition mechanisms (probably a simple question)?

If we use transition mechanisms, do we keep our link-local state in
IPvX?

Greg

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 05 May 2005 15:28:10 -0700

> indicate that there's no IPvY service, but that's still just a strong

Yes, but it isn't obvious to me that heeding such a strong hint would 
have any detrimental effect. It would just mean that the DNA would 
discard the old routers, prefixes, etc and then more or less immediately 
configure the same ones.

Thus it doesn't sound like an interesting attack for the attacker; it 
wouldn't cause much harm.

> native IPvX or IPvY is not available.

That might be an option when you have some mipvX service.
But we need DNA to work whether or not such support is available; just a 
  plain old dual-stack host should get reasonable behavior from DNA.

> IP subsystem restart.  After all: 127.0.0.1 should still work.

Making 127.0.0.1 and ::1 is easy even when the host moves very 
frequently :-)

> This is possible for contact via LEO satellites, for example.

I assume it is just as possible walking around with 802.11 APs, and the 
boundary between different IP links (some APs on one subnet and other 
APs on another subnet).

> (moving to networks with no service).

I doubt the zeroconf experience has anything to offer (than additional 
complexity and unsolvable problems).
Bernard's observation that most use of IPv4 link-local is due to some 
failure is an important one. And things like 802.11 ad-hoc mode seems to 
also show up due to failures (the desire being to associate with the AP, 
but the AP doesn't respond quickly enough and the software is configured 
to automatically fallback to ad-hoc.)

My take is that most of the devices that we understand today (laptops, 
PDAs, mobile phones) actually want Internet connectivity. So assuming 
that some local-only communication using IPvX link-local address will 
add something (other than failure modes and complexity) seems odd to me.

   Erik