On 2007-06-19 22:15, Jeroen Massar wrote:
Manfredi, Albert E wrote:
Jeroen, what about this quote from the draft:
Sorry I mutilated your name again!
Don't worry about that, that happens everywhere (even I typo it) ;)
4.1 DNS Issues
AAAA and PTR records for centrally assigned local IPv6 addresses may
be installed in the global DNS. This may be useful if these
addresses are being used for site to site or VPN style applications,
or for sites that wish to avoid separate DNS systems for inside and
outside traffic.
The operational issues relating to this are beyond the scope of this
document.
Not to mean it nastily but shoving the problem off to something else is a
very easy thing to do. If the ULA-C draft is going to define support for DNS
then it should also mention all the known operational problems that can
occur with it. The entity that will perform the registry function is really
not going to document or figure those things out.
I see Thomas' argument for tolerating occasional use of AAAA entries in the
global DNS for ULAs - but it seems that it leads to too many complications
to be recommended. Since I'm sure the IETF isn't ready yet to endorse the
reality of split DNS deployment, wouldn't it be best to say that ULA-Cs
SHOULD NOT be included in the global DNS? (And that is a significant
difference in scope and intent compared with PI.)
Brian
The above hosts are Internet connected and most likely will thus also end up
talking to the Internet at one point or another. I can thus only guess that
they will be wanting to fully connect to the Internet one day and the
generic solution to that problem is NAT. We wanted to get rid of NAT for
IPv6. If NAT is again being done for IPv6 then we can just as well give up
and just keep on using IPv4 as there really is not a single advantage then
anymore to IPv6.
But see below for a scenario that might have actual merit here.
Pekka Savola wrote:
[..]
I do not know the intended deployment scenarios
And this is the whole problem with ULA-C from what I see.
What are the intended deployment scenarios?
Or to put it better: what is the problem that needs to be solved?
I explicitly noted the drafts existence and instructions how people can and
that they should comment on this, I still have to see a mostly-RIR person
coming up with their views, or better somebody (and rather multiple) folks
that actually want to use it.
ULA (rfc4193) solves the problem of a "routed dental office", pop your boxes
out of the truck, plugin a ULA-capable router box in the middle et presto it
works. This is also already partially what link-locals solve, but those
don't work in a routed manner.
But what is ULA-C supposed to solve, especially in light that "IPv6 PI"
exists and is fairly easy to get?
but in many cases where
I'd expect ULA-C migth be deployed, I'd expect such sites to have some
global addresses as well for v4, v6 or both (maybe at a different
physical site, just for a couple of infrastructure servers instead of
all hosts, etc.)
In case you have 'infrastructure servers', aka your local DNS, then it
becomes very easy to let them return answers for your local ip6.arpa tree,
just add the zone as a master. No need for configuring
So, lets assume I have a ULA-C address, how exactly am I going to look up
the reverse? I need to have some kind of global address. When I have a
global address then what is the whole point of ULA, as I am connected already.
**SCENARIO**
One possible scenario could maybe be: use ULA-C local in your local site,
use global (PA) addresses from the upstream ISP, from whom you get a /48
too, thus the number plan is the same, just different first 48 bits. Every
host gets a ULA and a PA address. The PA address might change when changing
ISP. RFC3484 and related work can be used to configure preferring what
address to use. Then you never need to reconfigure your local network and
local addresses are globally unique and can use the Internet.
The big thing there is though: configure your firewalls correctly as the
public addresses do also allow access to everything.
Still, the above can also be accomplished perfectly fine with PI space and
that doesn't require any changes (except RIPE+APNIC policy) to be done.
You're right that if a ULA(-C) site would have no global addresses
whatsoever, reverse-DNS delegations can't be done.
The above example demonstrates that indeed.
Another funny thing there to note is that some people might want to use
ULA-C to 'hide' their infrastructure, as it will be completely disconnected
from the Internet. By introducing reverse dns though, those queries will be
ending up at several DNS servers on the big bad public internet. Of course
the NS record will be cached, but some information does get leaked.
Greets,
Jeroen
------------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
