RE: RFC3484 destination address selection rule 2 is buggy

One general comment I have for SAS (Source Address Selection) is that
folks have listed a lot of problems in drafts to v6ops and 6man etc.,
but most problems can be filtered down to a few rather than 10 or more
different problems. Some drafts also have very contrived network design
to break SAS - such a network is not breaking anything for SAS - the
network design is broken. 

Please see in line below between "<hs>" and "</hs>".

-----Original Message-----
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
Pekka Savola
Sent: Wednesday, March 26, 2008 1:50 AM
To: JINMEI Tatuya / ????
Cc: Iljitsch van Beijnum; ipv6@ietf.org
Subject: Re: RFC3484 destination address selection rule 2 is buggy

On Tue, 25 Mar 2008, JINMEI Tatuya / ???? wrote:
> v4:{site-local,global} is special and is not that harmful as long as 
> the network is properly configured (I know we cannot always assume 
> that, though).  When a link-local address is the only available 
> address for host, there should normally be no IPv6 default router 
> either.

The scenario where a router advertises the default route yet does not
advertise any prefix information (or prefix information does not set the
autoconfig bit) is still a valid scenario (e.g., I could imagine
DHCPv6-only deployments using this; in fact I believe if you want to run
DHCPv6-only this is the only choice to for deploying default
route) and it should be addressed.

<hs>
Welcome to access concentrators service provider (vs. enterprise)
deployments, one type of which is a cable deployment, the router will
send an RA with no Prefix Information Option (PIO). Access concentrator
networks (RFC 4388) use both a router and DHCPv6. Such deployments are
really large in scale, so indeed this is a valid scenario for
consideration for any protocol design. In IETF 70 presentation to 6man,
I had also said, access concentrator deployments have hosts behind
modems as always off-link to each other.
</hs>

Iljitsch noted in the original mail that his default route existed even
though he moved to ietf-464nat network (the nexthop was answering to
ping but was not sending RAs).

It is true that the case made in draft-ietf-v6ops-v6onbydefault-03 is
already somewhat mitigated by implementations which no longer implement
the "on-link by default" rule but that alone does not seem sufficient.

Is moving from one network to another (using the same interface) a
scenario where you should purge the default route? (Even if the nexthop
is still responsive?)  Should you purge the default route if the link
goes down (I suspect not -- e.g. with 802.11 link with bad coverage this
could be a problem)?

<hs>
DNA is taking care of such an issue where a host moves from one subnet
to another. 
</hs>

Hemant

It seems to me that there are also valid scenarios where exactly the
same problem appears in addition to many scenarios which are usually due
to misconfiguration.  I believe our protocols should be robust enough to
cover both valid scenarios and (if there aren't major
drawbacks) common misconfigurations.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------