[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt

> 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.

> >         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: Mark_Andrews@xxxxxxx
> >
> >--------------------------------------------------------------------
> >IETF IPv6 working group mailing list
> >ipv6@xxxxxxxx
> >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> >--------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@xxxxxxxx
> 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: Mark_Andrews@xxxxxxx

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6