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

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

Hi Mark,

	Thats why I said the DNS section was a "cop out".  The DNS
	information hadn't been collected, distilled and put on
	paper.  I attempted to do that.

	* Don't publish ambigious addresses global.
	* It is unwise (but not wrong) to publish unreachable addresses.
	* Don't let reverse queries for private address space leak.
	  That it is common to leak the private net next to you and
	  you should stop that as well as what you are using.
	* That you can the apex of the reverse zone for private space
	  to create your own deleation tree (e.g. 10.in-addr.arpa,
	  168.192.in-addr.arpa) and not have to slave all the reverse
	  zones everywhere.

I agree that it would be good to document this information, but there are three reasons why I personally don't think that the ULA document is the right place to do this:

(1) This is operational information, not part of the specification of these addresses, so it would be better published in a BCP.

(2) The IPv6 WG is not the best group to make broad statements about what should/should not be included in the global DNS. The dnsop WG would be a better place for this work.

(3) The ULA document has already passed IETF LC and is in the IESG. It should be re-opened for by the WG for critical technical flaws at this point, so I don't think it makes sense to use this document as a vehicle for publishing general information about how to handle local addresses in the DNS.

We need to come to some closure on how/if the DNS portions of this document need to change before publication, and we need to do it quickly because this document is already in IESG evaluation.

Brian Haberman, I think you are serving as WG chair for this document, right? Could you possibly figure out if this conversation has raised any new issues that need to be considered after IETF LC? If so, can you figure out if there is any IPv6 consensus regarding what to do about them?

I need to understand if it is necessary to delay this document for resolution of this issue.


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