Subject: Re: DNA for IPv4 or IPv6 ( was Re: [DNA] RE: Review of link-information from Pekka Savola)

From: Greg Daley <[email-masked]>
Date: Fri, 06 May 2005 09:44:22 +1000

Hi Erik, 

----- Original Message -----
[cut]
> 
> 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.

Perhaps.  Still, the potential for harm is the same if any
unverified hint is used to invalidate state before reception
of an RA.  Strong (or fast) attackers can get in first with
an RA which wouldn't otherwise have been listened to.

Any DNA procedures just need to be wise or robust to this though.

> 
> > There's been talk about mobility signalling or auto tunneling when
> > 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.

Agreed.

They may have resources on another interface (or upper layer) which
just needs to know the availability of IPvX access.
 
> > 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.
> 
> Making 127.0.0.1 and ::1 is easy even when the host moves very 
> frequently :-)

Sounds like you've got a short draft to write before April next year.

> >> 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.
> > 
> > 
> > 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).

It's going to be pretty common.

> > 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).
> 
> 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.)

Well let's not make those mistakes if they're costly in our 
environment.....

Knowing what not to do is worthwhile.  Talking to Bernard about any 
caveats
from IPv4 LL (which aren't already mentioned in the DNAv4 document)
would be useful.

> 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.

The default in Linux is to configure IPv6 Link-Local addresses on an 
interface
if IPv6 is on.  

I believe it then then follows ND and attempts Router Discovery, 
falling back into
a state of quiet after MAX_RTR_SOLICITATIONS (not looking at 2461, at 
the moment
for names, sorry).

Resetting the state for this interface may be within the realms of 
DNAv6,
by default in this WG, we think of an interface being actively used, or 
having
active configuration to check. When IPv6 service is unavailable on a 
valid 
interface though, procedures may be slightly different.

For example (and not meant as a premature optimization) it doesn't make 
sense
to send 3 or 4 router solicitations on an interface if IPv4 'knows' 
it's on
the same IPv4 subnet=> same link.

That's all I had in mind.  The remaining state for latent IPv6 or IPv4 
link local
may need resetting or modification.

Greg

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 06 May 2005 09:44:39 -0700

> The default in Linux is to configure IPv6 Link-Local addresses on an 

Yes, but link-local works quite differently than link-local IPv4 in most 
stacks.
A host can have a link-local IPv6 address and one or more global IPv6 
addresses, whereas for many IPv4 stacks it is an either link-local or 
non-link local, which makes switching back and forth so much more 
painful in IPv4.

Also, there's been the 'v6 on by default' discussion in v6ops, so I 
think by now most stacks can operate with an IPv6 link-local address 
(and no globals, due to no IPv6 router), without any adverse effect on 
applications (which will just use IPv4).

> the same IPv4 subnet=> same link.

Unless you are concerned about ARP/DHCP spoofs that make the host think 
it didn't move when it in fact did, and IPv6 is using SeND.
Attacks that try to convince you that you didn't move (when you did) are 
a lot worse than those that try to convince you that you moved when you 
didn't.

    Erik

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 May 2005 09:22:00 -0700 (PDT)

The IESG has received a request from the Dynamic Host Configuration WG to
consider the following document:

- 'Detection of Network Attachment (DNA) in IPv4 '
   <draft-ietf-dhc-dna-ipv4-11.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by 2005-05-24.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-11.txt