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. 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
signature.asc
Description: OpenPGP digital signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
