>
> --===============1586805975==
> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--325288981
> ;
> protocol="application/pkcs7-signature"
>
>
> --Apple-Mail-2--325288981
> Content-Type: text/plain;
> charset=US-ASCII;
> format=flowed
> Content-Transfer-Encoding: 7bit
>
>
> On Dec 7, 2004, at 17:25, Mark Andrews wrote:
>
> >
> >> Hi,
> >>
> >>> OK. Lot of shouting since this was sent but not much new text.
> >>>
> >>> How about
> >>>
> >>> Locally assigned ULA AAAA records MUST NOT appear in the global
> >>> DNS,
> >>> since there is an extremely small probability that the
> >>> corresponding
> >>> addresses are not unique. Even though these addresses will be
> >>> unrouteable in the global Internet, their leakage via DNS is
> >>> highly
> >>> undesirable. Such AAAA records MAY appear in local regions of
> >>> the DNS
> >>> corresponding to their region of routeability.
> >>>
> >>> (And I would put an equivalent SHOULD NOT on centrally assigned
> >>> ULAs.)
> >>
> >> While I am sure everyone in this discussion has read the DNS text in
> >> the
> >> current draft, here it is just in case:
> >>
> >> 4.4 DNS Issues
> >>
> >> At the present time AAAA and PTR records for locally assigned
> >> local
> >> IPv6 addresses are not recommended to be installed in the global
> >> DNS.
> >> The operational issues relating to this are beyond the scope of
> >> this
> >> document.
> >>
> >> For background on this recommendation, the concern about adding
> >> AAAA
> >> and PTR records to the global DNS for locally assigned local IPv6
> >> addresses stems from the lack of complete assurance that the
> >> prefixes
> >> are unique. There is a small possibility that the same PTR record
> >> might be registered by two different organizations. Due to this
> >> concern, adding AAAA records is thought to be unwise because
> >> matching
> >> PTR records can not be registered.
> >>
> >> This text (in my view) is more or less equivalent to what is proposed
> >> above. The text in the draft doesn't use the upper case MUST/SHOULD
> >> language since this part of the document is operational guidelines
> >> and that
> >> language doesn't seem appropriate. I suppose something with lower
> >> case
> >> must/should would work.
> >>
> >> My personal view is that this is about all we can say now in this
> >> document. I continue to think that what is needed is a separate
> >> draft that
> >> discusses this topic in detail. This document might even relax the
> >> recommendation if warranted. It would be a good place to describe
> >> different approaches to the locally and centrally assigned ULAs as
> >> well.
> >>
> >> Chair hat on:
> >>
> >> The -08 draft is currently in the IESG. Almost all of the Discuss
> >> votes
> >> have been cleared. If we can go with the current text it may result
> >> in the
> >> document being approved soon. The more we try to fine tune it there
> >> is a
> >> risk of further delay.
> >>
> >> It would be good if we could move forward on this document.
> >>
> >> Bob
> >
> > Which completely ignores the operational problems caused by
> > leaking reverse lookups. We know these will exist and we
> > need to take steps to prevent them.
> >
> > The only complaint I saw against my proposed text was the level
> > of proscription against adding AAAA LAU LAs to the global DNS.
> >
> > Don't throw the baby out with the bath water.
> >
>
> The concern I have with putting these operational recommendations in
> this document is that they are applicable to other scenarios (e.g. net
> 10
> addresses in the global DNS).
We really should be making a *one stop* document. Sure the
same problems apply to RFC 1918 and Link Local (both v4 and
v6). We may want a overriding document as well but the
same information with specific domain names needs to in all
to the above documents.
Whenever RFC 1918 gets revised (and it is long overdue for
revision) this sort of thing needs to be added there. Along
with filtering out packets with you prefix on entry.
Most of what is in Section 4 is applicable to RFC 1918. You
can connect multiple sites using the address in RFC 1918, you
just need to ensure that each site chooses a different prefix.
There really is nothing new with ULAs. We have been playing
with this sort of stuff for years in one form or another.
This document is about collecting what we know should be
done and putting it on one place with specific details as
they apply to FC00::/7.
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.
Mark
> So it seems more reasonable to have a generic guidelines document
> that discusses address placement in DNS.
>
> Regards,
> Brian
>
--
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
--------------------------------------------------------------------
