> At 05:45 PM 12/4/2004, Mark Andrews wrote:
>
> > 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.
>
> Come on. This is NOT a real-world example.
>
> Today, I publish domains of the style example.com for production (public)
> use. I also publish NS records for zones of the style local.example.com for
> addresses on local (i.e. PRIVATE) networks that are not reachable from
> outside. Why do I do this? It simplifies getting around on private networks
> that allow servers to communicate for private matters (backups, for
> example). The servers are multihomed, with a public facing interface that
> is used for public things and a private-facing interface that's used for
> private things.
>
> There's no interference with public operations. If you try to ping a host
> on .local.amaranth.net, you may get unexpected results since there are many
> RFC1918 addresses there. Did this harm anything? No. Could I use views in
> BIND to block your being able to query there? Sure.
It does no harm unless someone happens to attempt to use
those names outside of your world. You have no knowledge
of what is running on those addresses.
Internal email address do leak. The safe response to a
leaked internal address is to have it not connect to anything
when used externally. Your decision causes harm when the
address is actually running a SMTP server.
Similar senarios happen with every other protocol.
Because the addresses are ambigious you have no knowledge
of what harm a name leak will cause. You think that is
harmless. You can't know for sure what the impact of a
name leak will cause.
> People can and will publish zones for private use. Using a third level,
> such as local.example.com, is a GOOD way to do this.
>
> If you're concerned about people screwing up in the form you show above,
> then make a statement to that effect, rather than insisting on a MUST NOT
> that covers reasonable, and non-interfering usage such as folks have been
> using for years in IPv4. There's no Commons involved here.
I say MUST NOT because you cannot, as the publisher, know the impact
of publishing a ambigious address has on others.
> > This is the harm that can be caused when you publish a
> > LA ULA.
> >
> > 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.
>
> That's worked exceptionally well for folks leaking bogus-sourced packets
> (RFC 2827/BCP38). The IETF doesn't have a very good police force. If your
> goal is to enforce this by making DNS server products refuse to load zone
> data containing ULAs, I suspect that will fail as well, as the marketplace
> will insist such be allowed, and some vendor(s) will ignore claims to the
> contrary in the RFC.
Just because people don't do the right thing is not a reason to
not tell them what the correct thing to do is.
Mark
> > 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.
> >
> >--
> >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
> >--------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [EMAIL PROTECTED]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--
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
--------------------------------------------------------------------
