Keith Moore wrote: > Anything that involves ambiguous addresses will cause problems.
Please read http://www.ietf.org/internet-drafts/draft-hain-templin-ipv6-limitedrange-00. txt and note there is no requirement for ambiguous addresses. Please read http://www.ietf.org/internet-drafts/draft-hinden-ipv6-global-local-addr-02.t xt and note there are no ambiguous addresses defined. > Anything that increases reliance on address selection will > cause problems. Having more than one address requires address selection, therefore this issue is with multi-homing, not a particular prefix. > Anything that makes it easy for limited reach > addresses to leak outside of their routing scope will cause > problems. So ban applications from passing addresses. This has nothing to do with any particular prefix, because it applies to all equally. Routing and access filters are a reality and will not go away. > And the more different ways we have to provide > address stability, the more failure scenarios we're creating. I happen to see if from the glass-half-full perspective and note that we are providing more solution scenarios. > > > > But again, we can solve the local stability problem if there > > > really is a significant use case for it. > > > > So solve the requirements and there will not be a need for other > > approaches. Until then, this filibuster is delaying network > managers > > from deploying IPv6 in a way that will meet their requirements. > > Well it's not clear that such requirements are valid. > Somebody needs to make a convincing case. > > And even if one accepts the need for a separate local > stability solution, this still wouldn't necessarily justify > ambiguous addresses or increased reliance on address selection. Continuing to raise ambiguous addresses is simply creating FUD. The requirements are valid to those that have them, independent of acceptance by the IETF. The network manager will meet the requirements with the tools we provide, even if that means using ones we wish they would not. Our only recourse is to provide alternative tools that meet the requirements. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
