RE: WG Last Call: On-link Assumption and IPv6 On by default

[Pekka Savola <pekkas@netcore.fi>]

Hi Tony,

Thanks for good feedback.  You raise good points, which warrant 
clarifications and/or more discussion on certain parts of the 
document(s).  More inline..

On Wed, 24 Mar 2004, Tony Hain wrote:
> Onbydefault needs some minor wording changes, but is otherwise ready.

OK.

> Onlinkassumption has a whining tone, and is clearly not ready. Rather than
> pointing out issues, it tries to justify changing everyone's behavior to
> match a particular implementation. The most it should do is recommend a
> policy knob to disable the assumption.

I have to personally disagree with this.  I don't think this depends 
on the implementation technique (see below).  Further, having a policy 
knob to disable the assumption would be harmful for most of the users, 
even though only few (if any?) would find it useful -- so if there is 
a knob, I think it would have to be to re-enable the assumption (more 
of this below as well).
 
> draft-ietf-v6ops-v6onbydefault-01.txt
> 3.3 - tunneling discussion should point out the same is true for tunneling
> of IPv4, so this is really a misconfigured firewall, not an IPv6 problem

Do you refer to the misconfigured firewall problem or the VPN problem?  
Those seem to be slightly different, and could maybe be discussed in 
subsections.

I'm assuming the former.  Yes, this seems like a misconfigured 
firewall.  This should be mentioned more clearly.  However, it's 
probably still worth stating, as we don't want everyone to completely 
block proto-41 as a safeguard.  And besides, this cannot really be 
fixed, in general, by firewall config only -- consider Teredo which is 
infamous for burrowing through firewalls alike -- and you'll have 
difficult time trying to prevent that..

Automatic connectivity tools such as 6to4 or Teredo aren't expected to 
be commonplace, as with IPv6, so this seems to be an issue worth 
noting.

> 4. Applications also need to be aware that the fact that a
>    dual stack destination's IPv6 address is published in the DNS does
>    not necessarily imply that all services on that destination function
>    over IPv6.
> 
> This is also true for IPv4. Just because www.sun.com has an IPv4 address
> does not mean that the SMTP service works on that destination.

This seems slightly different, because www.sun.com is not listed as 
their MX record -- there is no reason anyone would assume it's the 
right place to send mail to @sun.com addresses?

On the other hand, if www.sun.com listed both A and AAAA records, it 
should obviously work with either A and AAAA.  The argument is that 
even if AAAA (or A) doesn't work (for whatever reason), one should 
fall back to the other.  

In in a sense, this is indeed similar with IPv4.  For example,
consider the case of www.sun.com having two A records.  If the first
doesn't work, you should be able to fall back to the second one.  
This gets more required, practical, and complicated (from app
developer point of view) with the introduction of IPv6..
(typical v4 apps don't handle multiple addresses AFAIK, but that is a 
requirement for v4/v6 apps.)

> 5. Section 3 should be moved to here, there is no need for a separate
> discussion with a pointer.

Did you mean section 3.3, not section 3?  I assume so.

Actually, Security considerations should be expanded to include more
than just a pointer: discuss the issues in more general (I have
comments pending on that).  It may still be worth to have (longer)  
discussion in sect 3.3, and just refer (or summarize) that from
Security Considerations, but that would probably remain to be seen.

> draft-ietf-v6ops-onlinkassumption-01.txt
> 
> 2. discussion about workaround should point out that many users don't have
> the appropriate privileges or knowledge to manually configure addresses

Good point. (Which can also go the other way: the hosts are not 
expected to have manually configured addresses unless the users have 
privileges to configure them -- thus reducing the need to cover for 
"two distinct prefixes on the link" -scenario in the first place.)
 
> 3.1 - so the text finds fault in address selection rules because an arguably
> broken implementation decides that an empty router list means that the local
> interface becomes the default router??? Rather than call the rules at fault,
> the section should point out the fallacy of that implementation approach.

But isn't the result in the end still about the same, no matter what
implementation technique would be used?  If you have an empty router
list (rather than a default on-link route), RFC2461 sect 5.2 still
states that everything should be considered to be on-link.  The
implementation techniques appear to be equivalent in this scenario --
or could you elaborate?  This is something warranting clarification in
any case..
 
> 3.2 - establishes an exaggerated scenario then complains that the result
> takes too long. The same would be true for a long list of IPv4 addresses
> where the only accessible one was the last on the list. 

But this specific case would not happen with IPv4, as it has no
on-link assumption, right?  Obviously, if you do send out e.g. a lot
of IPv4 TCP SYNs and get RSTs back except for the last one, the
situation is the same (but that's a separate issue, discussed a bit 
in the v6onbydefault doc sect 2.3).
 
> 3.3 - is speculation about a particular implementation detail, not an
> even-handed discussion about alternatives. 2 is what the default action
> should be. 

I see this case as a rather important detail (when analyzing that part
of the spec -- in general it isn't necessarily too criticial), and
probably not something best left for implementers' discretion --
because we'll get (and have gotten) inconsistent results.

You say 2 is what it should be; some say 1 is the simplest bet; others
say don't do anything because no action you make can lead to
consistent results.

Being targeted at BCP, if the recommendation was not to disable this
feature altogether, the secondary resolution could be "well, if you
implement it in any case, do it like this [gain WG consensus on what
we would recommend in such a case]".  Not sure if this is worth the
effort, but could be brought up.
 
> 3.4 - this should be moved to the security considerations section.

It seems that section 3 is maybe more balanced with all the issues 
described there.  That said, there should probably be more text in 
security considerations..
 
> 4. rather than change the spec, this should simply recommend that
> implementations include a policy option to disable the 'on link assumption'
> if desired.

I have to disagree rather strongly with this.  In RFC2461bis, this
part of the conceptual algorithm has already been removed, and no 
clear arguments have been presented why this would be a problem.

On the other hand, I would not object to having a toggle which would
restore the on-link assumption behavior, if someone would want to
still provide it for some unknown purposes.  But to ensure that the
default is sane for the general consumption, such toggles should be
disabled by default.

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