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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 --------------------------------------------------------------------
