inverse mapping for 6to4 [Re: configuring our site for ip6.int...]

[Nick Sayer]

Simon Leinen wrote:
> 
> >>>>> "ns" == Nick Sayer <nsayer@quack.kfu.com> writes:
> > Richard Draves wrote:
> >>
> >> What about for 6to4 address space?
> 
> > [boldly leaping forward]
> 
> > If no one else steps forward, I would be willing to conquer this
> > job. I can cobble together some scripts and some web that will keep
> > track of 6to4 NS records for the ip6.int space.
> 
> Personally I'd find it more elegant/useful to delegate 2.0.0.2.ip6.int
> to nameservers that map PTR requests to CNAME pointers into the
> IN-ADDR.ARPA space, e.g. for the 6to4 address
> 
>  2002:823b:1d2:4:a00:20ff:fe9c:792b
                   ^^^^^^^^
<pointless>Use Suns much? :-)</pointless>

>      ^^^^^^^^
> <=> 130.59.1.210 (6to4 gateway)
> 
> one might be redirected as follows:
> 
> dig ptr -x b.2.9.7.c.9.e.f.f.f.0.2.0.0.a.0.4.0.0.0.2.d.1.0.b.3.2.8.2.0.0.2.IP6.INT.
>  => IN CNAME b.2.9.7.c.9.e.f.f.f.0.2.0.0.a.0.4.0.0.0.6TO4.210.1.59.130.IN-ADDR.ARPA.
> 
> That way the owner of the inverse mapping for 130.59.1.210 could
> simply add PTR records or sub-delegations for the 6to4 addresses under
> that prefix.
> 
> Ideally, this style of automatic redirection could be combined with
> traditional delegations to accomodate situations where the 6to4 and
> IPv4 inverse mappings cannot be coordinated for some reason (such as
> someone at a University trying to set up a properly inverse-mapped
> 6to4 cloud in a lab, and not getting any cooperation from the
> hostmaster at Computing Services who is in charge of the IPv4 inverse
> mapping).

There are 2^32 IPv4 addresses, and only a tiny fraction of them are
going to
be represented in 6to4 prefixes. Additionally, 6to4 is only a
compatibility
hack whose useful lifespan is finite and (we all hope) short. The path
of
least resistance is to simply manage the zone for the few years it will
remain
relevant.

I allege that given the cluefullness most ISPs have lacked so far about
IPv6 (at
least on this continent), asking them to subdelegate in-addr.arpa space
(when many
of them can't even set up that space correctly) is a losing proposition.
Given
that premise, there will be more exception cases (explicit declarations
to replace
"normal" delegations under the control of competent ISPs) than not.

Evem if you take the tack that the 2.0.0.2.ip6.int zone will be
automatically filled
with cname or ns records that are then overridden with exception cases,
a whole new
zone transfer mechanism must be created for those few servers that will
preside over
the 2.0.0.2.ip6.int zone. If not, then the mechanism will consist of
transfering
2^32 sets of NS or CNAME records, which would probably be over 99%
garbage.


> 
> If this is deemed a good idea, someone should write an I-D about it
> and hack BIND or some other DNS server as a proof of concept.

I think that's way too much effort. Much simpler to just manage the zone
by hand.

> 
> > Of course, someone would have to delegate the 2.0.0.2.ip6.int. level
> > to me.
> 
> It seems that this domain has been delegated already.

Part of the reason I am speaking up is that I can find no way to enter
delegations into that zone. If there is a way, then I would gladly
shut up about it. I do believe the delegatees of that zone have some
burden to say _something_ with regards to the procedure for putting
NS records in the zone. Even if that something is "Be patient. We're
working on a procedure right now." :-)

> 
> > 2. I don't think this is quite as daunting a task as it may at first
> > appear. It is likely in my mind that the number of 6to4 routers will
> > be on the order of 1 per site and that they are likely to end up
> > being phased out over time anyway. I further suspect that the number
> > of such relays at the moment is low. Further, there is an obvious
> > 1:1 relationship between 6to4 prefixes, 6to4 routers and
> > 2.0.0.2.ip6.int zones. And if in the future the task becomes more
> > daunting rather than less, the delegations can be broken up.
> 
> One of the nice things about 6to4 is that it requires very little
> administrative work to get connectivity (at least to other 6to4
> networks).  If 6to4 inverse mappings could be piggybacked on IPv4
> inverse delegations, we could save people the work of contacting an
> external entity for that.

It would indeed be nice if it was automatic, as is the 6to4
prefix allocation. But there's no automatic way to decide which
IPv4 addresses are 6to4 routers and which aren't. And the overwhelming
majority of them won't be.