[arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement)

[Mark Andrews]

In message <6ABCC1C0-6DB6-403E-B8D8-78D688CF8F14 at delong.com>, Owen DeLong write
s:
> 
> On May 16, 2012, at 10:12 AM, William Herrin wrote:
> 
> > On 5/16/12, Owen DeLong <owen at delong.com> wrote:
> >> On May 16, 2012, at 8:11 AM, Michael Richardson wrote:
> >>> But, I didn't say it was risk of collision with ULA-R that was the
> >>> main problem, it is lack of reverse DNS and lack of whois that is the
> >>> problem.
> >> 
> >> Why do you need non-local RDNS and/or WHOIS for local-only addresses?
> > 
> > Hi Owen,
> > 
> > Configuring split-horizon DNS coordinated between multiple
> > interconnected organizations has always been a bit of an intractable
> > problem, especially when some parts are connected to some other parts
> > but not all parts are connected to all other parts. You could
> > sometimes get around it with an interior root but DNSSEC blows that
> > out of the water. An exterior NS record back to the interior
> > authoritative server could potentially help a lot.
> > 
> 
> Which makes the situation you describe more ideally suited to GUA with
> appropriate filtration of routes and packets.
> 
> Owen

ULA space is supposed to be within insecure delegation to break the
chain of trust, see RFC 6303.   Currently isn't which should be
corrected.

6.  IANA Considerations

   IANA has established a registry of zones that require this default
   behaviour.  The initial contents of this registry are defined in
   Section 4.  Implementors are encouraged to periodically check this
   registry and adjust their implementations to reflect changes therein.

   This registry can be amended through "IETF Review" as per [RFC5226].
   As part of this review process, it should be noted that once a zone
   is added it is effectively added permanently; once an address range
   starts being configured as a local zone in systems on the Internet,
   it will be impossible to reverse those changes.

   IANA should coordinate with the RIRs to ensure that, as DNS Security
   (DNSSEC) is deployed in the reverse tree, delegations for these zones
   are made in the manner described in Section 7.

7.  Security Considerations

   During the initial deployment phase, particularly where [RFC1918]
   addresses are in use, there may be some clients that unexpectedly
   receive a name error rather than a PTR record.  This may cause some
   service disruption until their recursive nameserver(s) have been
   re-configured.

   As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
   namespaces, the zones listed above will need to be delegated as
   insecure delegations, or be within insecure zones.  This will allow
   DNSSEC validation to succeed for queries in these spaces despite not
   being answered from the delegated servers.

   It is recommended that sites actively using these namespaces secure
   them using DNSSEC [RFC4035] by publishing and using DNSSEC trust
   anchors.  This will protect the clients from accidental import of
   unsigned responses from the Internet.


Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org