> Thus spake "Mark Andrews" <[EMAIL PROTECTED]>
> >
> > If ISC was to publish in the DNS
> >
> > www.isc.org. 10M IN AAAA 2001:4f8:0:2::d ; exists today
> > www.isc.org. 10M IN AAAA FC01:4f8:0:2::d
> >
> > and you happened to have a machine with local addresses
> > FC01:4f8:0:2::d.
> >
> > You would be unable to reach www.isc.org from any machine
> > receiving your ULA prefix as a consequence of the address
> > selection rules.
>
> I can't ping that same host with "ping fc01:4f8:0:2::d" either; whether the
> hostname is in DNS or not doesn't materially reduce the impact of a LA ULA
> collision.
>
> > This is the harm that can be caused when you publish a
> > LA ULA.
>
> That is certainly a possible outcome if you happen to collide with someone,
> that someone happens to be mixing PI/PA and LA ULA addresses for a given
> hostname, and you happen to try to contact a host via that hostname. Care
> to calculate the odds that your scenario will happen?
>
> However, there do exist cases where the behavior is well-defined and correct
> even in the face of ambiguity. Suppose you have:
>
> www-dev.isc.org. 10M IN AAAA fc01:4f8:0:2::d ;no PI/PA addys
>
> which is (hypothetically) a development server only intended to be used by
> ISC's business partners, and ISC's LA ULA prefix is reachable over private
> links within the closed set of parties that need to use the dev server.
>
> ISC's business partners can reach the dev server at the above name with no
> changes to their local nameservers (if they even have control of such),
> removing an opportunity for human error to intrude. OTOH, anyone else
> trying to contact the dev server will either reach a different host (due to
> a collision) or nothing at all -- either is acceptable to ISC. The hostname
> and IP are intended to be useless to any party not privately connected,
> whether colliding or not, and a LA ULA is no worse as a public response
> than, say, an address assigned to a competitor: neither is valid data yet
> neither is a protocol or logic violation.
If you want to be able to do this then get a CAULA. CAULA are
designed for those who want to play on the global scale. Use the
right tool for the right job. Stop trying to treat CLULAs as if
they are identical to CAULAs. They aren't.
> > If you don't have MUST NOT you don't have a way to point
> > blame when things go wrong. With MUST NOT you can say
> > please remove the address you are in violation of RFC XXXX.
>
> from RFC 2119:
> "SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
> there may exist valid reasons in particular circumstances when the
> particular behavior is acceptable or even useful, but the full
> implications should be understood and the case carefully weighed
> before implementing any behavior described with this label."
This WG has much too little experience with DNS administators.
You give them a inch with a SHOULD / SHOULD NOT and they take
a mile.
DNS/TCP is a SHOULD in RFC 103[45]. Care to hazard what
one of the major probems is with the DNS? TCP being blocked
at the firewall, one vendor doesn't support TCP by default.
I don't know how many times I've heard "Oh DNS/TCP is a SHOULD
we don't need to support it." even when the DNS lookups against
their servers are failing because they have DNS/TCP blocked.
This section really is targeting DNS administators. If they can
make a wrong decision with a SHOULD / MAY they will. 10+ years
of correcting mistakes like this has shown me that you don't
leave doors like this open.
This will become "It's only a SHOULD NOT it won't cause any harm".
DNS administators regularly fail to keep the parent/child NS records
in sync. They regularly only put glue in the parent zone. These
are the basics.
You want to hand them a SHOULD NOT.
> That sums up exactly how putting LA ULAs into the global DNS should be
> viewed: there exist circumstances when doing so is useful, but they require
> careful thought to prevemt unintended interactions. The LA ULA draft could
> certainly be enhanced with a list of what to consider and example scenarios
> where they do and don't work, but a MUST NOT isn't appropriate as long as
> there is _any_ legitimate use.
CAULA in the global DNS will result in unreachable machines.
LAULA in the global DNS will result in connections to wrong
machines with subsequent exposure of everything transmitted over
those connections.
> Removing the LA ULA from DNS will not solve the ambiguity problem anyway,
> nor does it mask the interaction with address selection rules. The problem
> still exists at the IP layer, and any application that supports IPv6 address
> literals (i.e. nearly all of them) would see the exact same behavior if
> users were to type in an ambiguous ULA literal instead of a hostname that
> resolved to that ULA. Should we also ban users from distributing LA ULAs
> via smoke signals or avian carriers to keep from trying to use addresses
> where they're not valid?
I never said it would remove the problem. It will however prevent
part of the set of problems caused by having ambigious addresses.
Remember when a user types in a LAULA they know (can know) they have
hace a LACULA. When a user types a domainname into a application
they have no way of knowing that they have got back a LACLA.
I know when a type 10.x.x.x that it is ambigious address. Users
will learn that FC... is a ambigious address.
I didn't say don't put them in the DNS. I said don't put them in
the global DNS.
> Finally, the verbage may give you something to point at when another admin
> does something you don't like, but that's the _only_ effect it will have.
> If he's going to ignore a MUST NOT in an RFC, what are the odds he'll make
> non-trivial changes to his configuration merely because _you_ had the
> misfortune to collide with his prefix? Of course, the only serious risk of
> collisions will be from intentional failure by both parties to follow the
> MUSTs in the draft...
It's much easier to get change when it is clearly proscribed.
> > 2001:4f8:0:2::d is assigned by forcing the LL address then
> > using auto assignment to get the other prefixes. It is
> > done this way so it won't change with hardware changes.
> >
> > I expect other sites will do similar things to provide stable
> > addressing to their external machines. Collisions in addresses
> > get much more probable when you start assigning the local parts
> > by hand.
>
> It reduces the collision space from 2^128 to 2^64, which is significant, but
> LA ULA prefixes are sufficiently unique that the rest of the address doesn't
> need to be. With 40 bits, we'll need over a million sites fully
> interconnected using LA ULAs before there's a 50/50 chance of prefix
> collision... Of course, since ULAs' scope is expected to be from one to a
> few thousand sites, making the odds of collision on the order of 2^-15 to
> 2^-40 for each ULA prefix. It is safe for us to act as if LA ULAs were
> unambiguous and let layer 8 detect and correct collisions if they ever
> occur.
We are talking aboult LAULA's assigned world wide. Not just the
number of LAULA within a private routing domain.
> Now consider the odds of a human error at a registry that results in a
> duplicate assignment; since it's nonzero (provable, since it's happened to
> me) should we also start treating PI/PA space as ambiguous just in case?
> No, we act as if PI/PA space were unambiguous and let layer 8 detect and
> correct duplicates when they occur. Notice the symmetry there?
Putting LACLA into the DNS results in "broken by design". This
is very different to "broken by error".
> In the end, the entire DNS paragraph is totally unenforceable thus the
> choice of SHOULD NOT or MUST NOT is not going to change a darn thing in real
> deployments. Consensus was achieved on this point long ago, and there is no
> indication that has changed or that it would make a meaningful difference
> even if it had. This effort would be better spent on other parts of this
> draft or on building support for CA ULAs and/or end-user PI space.
Pointing out the limitations of LAULAs actually enhances
the need for CAULAs. By attempting to treat them the same
you actually are saying "we don't need CAULAs. LAULAs are
`good enough' for everything we want to do."
They clear are not good enough for every senario. Pointing
out the differences make the case for both types stronger,
not weaker. Letting people know up front the inherent
limitations of each type is a good thing.
I want CAULAs. I'd even be willing to pay a reasonable
annual fee. If I can't get get a CAULA at a reasonable fee
I will use a LAULA and live with the limitations that it
brings.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
