Subject: RE: Issue 3: on link assumption considered harmful

From: Soliman Hesham <[email-masked]>
Date: Wed, 29 Oct 2003 08:49:22 -0500

> I think this scenario is useful for IPv6 small-devices, so I 
 > don't quite agree
 > with you all.
 > 
 > I feel that we are undoing a lot of things and we will end 
 > up with no 
 > autoconfiguration features at all. This might be a good thing 
 > for sysadmins, though.

=> I don't think we're undoing any autoconfig here. This is 
a clarification to avoid other problems without eliminating
autoconfig.

 > 
 > If I understand the onlinkassumption draft well, the main drawback
 > of sending packets on-link is that some malicious party would
 > be able to grab those packets. 

=> IMHO, that was not the main issue. I saw bigger
issues in that draft. I thought the biggest two were:

- impacts on address selection (section 3.1)
- Address resolution delays (section 3.2)

Hesham

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Juan Rodriguez Hervella <[email-masked]>
Date: Wed, 29 Oct 2003 17:47:11 +0100

> a clarification to avoid other problems without eliminating

I quote yourself on a previous mail on this thread:

"The problems of this assumption are discussed in section 3
of Alain's draft. The draft suggests that this assumption
should be removed from ND specs. Here is the suggestion:
[snipped but it's read as..."remove" and "remove"...]
This seems like a reasonable suggestion, any objections?"

As I've already said, I think that on-link communications might
be a useful thing to have.

> - impacts on address selection (section 3.1)

So let's go to fix address selection instead of removing
a nice feature.

> - Address resolution delays (section 3.2)

I think that this problem doesn't deserve removing automated 
on-link communications. I realise that this issue implies that
we are penalizing the well-configured IPv4 network.
This is better than forbiding IPv6 on-link communications and 
moreover you might have similar delay penalties even with an IPv6
default router, if there's some black-hole on the routing system...

Cheers.
-- 
JFRH

---

From: Pekka Savola <[email-masked]>
Date: Wed, 29 Oct 2003 23:03:38 +0200 (EET)

Hi,

Combining this, and the comment from the AI_ADDRCONFIG thread, and adding 
v6ops in the Cc:..

On Wed, 29 Oct 2003, Juan Rodriguez Hervella wrote:
[...]
> You will have to give me other arguments to kill the on-link assuption.

You seem to have some scenarios in mind where you think these are useful.  
Please elaborate.

Remember that the removing the on-link assumption mostly helps in 
deployments where there is no IPv6 connectivity at all.. i.e., you're 
probably not experiencing these personally :-).  But those are very 
probably nasty for folks who might have dual-stack on by default, but 
without connectivity.

More inline..

> be a useful thing to have.

You realize, of course, that the document does not try to restrict on-link 
communications at all?

It just recommends that if you don't have a default route, don't assume
everybody in the Internet is reachable on-link.  This seems rather
reasonable in almost all cases, because you generally *can't* expect
anything like that.  You expect that the prefixes you have the addresses
from are on-link (which continue to work without any problems), and that's
it :-)

> So let's go to fix address selection instead of removing

Again, do you have scenarios in mind where this feature would be useful?

The document doesn't (yet :-) tease out the different problems as well as
it could, but this isn't just a thing that can be fixed by a simple
default address selection modification.  

For example, if your first-hop router crashes *), but you still have a
global IPv6 address, and you perform a DNS lookup over IPv4, and get A and
AAAA responses back from the DNS, the on-link assumption would make you
try to perform a TCP connect() using the IPv6 address.  Obviously, this
will cause long timeouts until the router comes back up and replaces the
default route.

*) here are actually two cases: the default route is removed (e.g. it
times out), which is a clear case of an on-link assumption problem, and
when default route persists but the next-hop is considered unreachable by
NUD (which also triggers the on-link assumption, AFAIR -- but not sure;  
also not sure how fast NUD will work on the default router's nexthop..).

The more obvious problem you may not be seeing is when an implementation 
has enabled dual-stack but does not have IPv6 connectivity at all (i.e., 
only the link-local addresses).  However, due to the onlink assumption, it 
tries to reach every IPv6 destination directly on its interfaces.  I fail 
to see any justification for this.  Such addresses need not come through 
default address selection.

The clearer issue with default address selection (really, destination
address selection, which isn't really implemented that much yet!) is when
the the scopes are mismatching.

The fix should probably be applied in both, the default address selection
(by clarifying what "avoid unusable destinations" should entail) and
RFC2461bis, but the latter is more timely and more important.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Juan Rodriguez Hervella <[email-masked]>
Date: Thu, 30 Oct 2003 12:04:14 +0100

> probably nasty for folks who might have dual-stack on by default, but

Ok I understand that.

> You realize, of course, that the document does not try to restrict on-link

Yes I do.
 
> Again, do you have scenarios in mind where this feature would be useful?

Uhmmm let me think for a while, ok ? :-)

> will cause long timeouts until the router comes back up and replaces the

For example, your fridge wants to talk with the scheduler to ask for more
food. The oven, which is sending RAs, is turned off. 
This will cause no communication at all.
I prefer 3 seconds of delay. I'm the auto-communication kind of man.

I don't intend to make you laugh but I think I will have to get
some information about the zero-conf WG's jobs before going on 
this discussion, because I thought that this feature was a
GOOD THING.

> only the link-local addresses). 

This is the common case nowadays. When I connect to Internet at home with
my dial up provider, I've got IPv4 and also a link-local address and I've 
never experienced any problem at all.

> However, due to the onlink assumption, it

Absolutely agreed.

-- 
JFRH

---

From: Juan Rodriguez Hervella <[email-masked]>
Date: Thu, 30 Oct 2003 12:23:43 +0100

> > global IPv6 address, and you perform a DNS lookup over IPv4, and get A
> > and AAAA responses back from the DNS, the on-link assumption would make
> > you try to perform a TCP connect() using the IPv6 address.  Obviously,
> > this will cause long timeouts until the router comes back up and replaces
> > the default route.
>

Ooops, forget the oven :-), just think as if the fridge was shipped
with an Ipv6 address prefix and the scheduler was shipped with
another IPv6 prefix :)

-- 
JFRH

---

From: Sebastien Roy <[email-masked]>
Date: Thu, 30 Oct 2003 11:39:21 -0500

[email-masked] said:
> For example, your fridge wants to talk with the scheduler to ask for
> more food. The oven, which is sending RAs, is turned off.  This will
> cause no communication at all. I prefer 3 seconds of delay. I'm the
> auto-communication kind of man.

I don't see how you reached the conclusion that the removal of the
on-link assumption would cause lack of communication in your example.
If you're depending on a fall-back to IPv4 (and I assume you are since
you mentioned a 3 second delay), then communication will occur more
quickly without the on-link assumption...  Can you explain your
reasoning?

Your example is not well defined.  Are the fridge and the scheduler on
the same link or not?  Do they have manually configured IPv6 addresses
or statelessly autoconfigured addresses?  Do they have IPv4 addresses?
Is the oven both the IPv6 and IPv4 router?

> 
> I don't intend to make you laugh but I think I will have to get some
> information about the zero-conf WG's jobs before going on  this
> discussion, because I thought that this feature was a GOOD THING.

The zeroconf requirements don't include the on-link assumption.  They
also don't include nodes residing on the same link, but it's not clear
if the example you gave depends on that or not.

> never experienced any problem at all.

Your experience is anecdotal.  There may be two reasons for your not
experiencing problems.

1. In general, do you attempt to communicate with nodes whose names
   resolve to both IPv4 and IPv6 addresses?  Maybe not.

2. Some OS's never implemented the on-link assumption to begin with,
   maybe yours is one of them.

-Seb

---

From: Pekka Savola <[email-masked]>
Date: Thu, 30 Oct 2003 19:15:53 +0200 (EET)

On Thu, 30 Oct 2003, Juan Rodriguez Hervella wrote:
[...]
> with an Ipv6 address prefix and the scheduler was shipped with

The whole point of IPv6 (and also IP) is that machines aren't shipped with
invented addresses, and you're supposed to make them automatically
communicate.  Or, in the case of IPv6, the invented address is their 
link-local address and they can autoconfigure another address.  All of 
these are from the same prefix between all the nodes on a link.

This is just so incredibly bad idea it doesn't even bear thinking about.  
But if one want to enable it manually, you can always point a default 
route in your Ethernet interface.

More on the related subject from:

   Embedding Globally Routable Internet Addresses Considered Harmful
                       draft-plonka-embed-addr-00

Abstract
                                                                               
   Vendors of consumer electronics and network gear have produced and
   sold hundreds of thousands of Internet hosts with globally routable
   Internet Protocol addresses embedded within their products' firmware.
   These products are now in operation world-wide and primarily include,
   but are not necessarily limited to, low-cost routers and middleboxes
   for personal or residential use.
                                                                               
   This "hard-coding" of globally routable IP addresses within the
   host's firmware presents significant problems to the operation of the
   Internet and to the management of its address space.
                                                                               
   This document means to clarify best current practices in the Internet
   community.  It denouces the practice of embedding references to
   unique, globally routable IP addresses in Internet hosts, describes
   some of the resulting problems, and considers selected alternatives.
   It is also intended to remind the Internet community of the ephemeral
   nature of unique, globally routable IP addresses and that the
   assignment and use of such addresses is temporary and therefore
   should not be used in fixed configurations.

---

From: Juan Rodriguez Hervella <[email-masked]>
Date: Thu, 30 Oct 2003 18:55:31 +0100

> route in your Ethernet interface.

Hello:

Indeed this is a good point.

I won't discuss on this subject any longer.

Thanks for the discussion and the pointer!

[snipped]

-- 
JFRH