Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT)
> This prompted a jabber discussion extracts of which follow. > > note that people who operate routers are usually all about control. > automatic renumbering is scary except maybe on the edge > There is no loss of control. It would still require a human to add a > prefix to the set of prefixes in use. > > somebody upstream from you renumbers. what happens? > With IPv6 I would expect that a both the new and old routes would be > published for a period. The old route would then be withdrawn. There is > plenty of addresses space. There is no need for instantious changes in > addresses. > > i was talking about control. your upstream adds new prefix, do you > add automatically or do you wait for human to approve it? > simiarly for your upstream withdrawing, do you withdraw automatically > or ... > I would expect that there would be due notice give so that humans > could be involved. you expect too much. > > Mark > > -- > 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 > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT)
no renumbering event is "too hard" in isolation .. BGP peers, MRTG/CRICKET monitoring, /ACL configs, syslog all come to mind as issues/considerations for router renumbering. and remember tht the router is the distribution engine of "the set of prefixes in use with a set of tags (global, deprecated, etc) one has to be very careful about "catch22 situations, deprecating the in use prefixes before the new prefixes are in use. operationally, renumbering DNS/DHCP servers is a whole lot easier. --bill On Wed, Jun 20, 2007 at 10:41:33AM +1000, Mark Andrews wrote: > > I would have thought that router renumbering should be no > harder that host renumbering. Essentially all you are > changing is the higher (/48 normally) prefix bits. All > that is required is a method to distribute the set of > prefixes in use with a set of tags (global, deprecated, > ula, advertise in RA, etc.). > > Everything else should flow from that set. Firewall rules > should be using that information as it really doesn't matter > which global prefix a host uses to talk to the world. They > are all essentially equal. > > I may we be showing my ignorance here but I don't believe > that this really is a "to hard" job. > > Mark > > > Jeroen Massar wrote: > > > > > 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. > > > > > > > > I think what we wanted to get rid of in IPv6 was one-to-many NAT, also > > know as PAT (among other names). In IPv6, we can stick to one-to-one > > NAT, which eliminates most of the nastiness we associate with NAT in > > today's IPv4 world. > > > > > But see below for a scenario that might have actual merit here. > > > > > > > > **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. > > > > > I don't think routers are at the point yet where you can easily renumber > > your routers' interfaces when your PA addresses change. As a result, > > networks wanting to avoid the pain of renumbering, but who don't qualify > > for PI and a global routing slot, might want to do something similar: > > > > Say a network gets a ULA-C block, and numbers everything on their > > network out of that block. They later connect to the Internet, and get > > a PA block from their upstream, and configure it on their border > > routers. To avoid reconfiguring all their routers every time they > > change upstreams, they configure one-to-one NAT on their border routers, > > such that every address on their internal network (which is ULA-C) maps > > to the same address, except with different first 48 bits, in their > > provider-allocated block. > > > > This wouldn't present the same kinds of problems you'd get from > > one-to-many NAT, but I'm sure there are some ways where this wouldn't be > > as good as PI space. However, my first-order evaluation is that it > > would be better to have small networks achieve their provider > > independence this way, rather than by relaxing the PI rules and > > threatening the scalability of the current routing system with a large > > number of additional non-aggregatable netblocks. > > > > Now as expressed earlier, most ULA-C use cases probably won't involve > > NAT. But if people do elect to use NAT with ULA-C, what problems do you > > see with this kind of use of NAT? Do you see those problems as worse > > than the problems caused by completely rejecting the original PA-only > > architecture of IPv6 in favor of PI-for-everyone? > > > 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. > > > > > > > > I agree that PI space, if it were widely available, would meet the same > > needs as ULA-C. However, I think we need to be realistic that > > PI-for-everyo
Re: draft-ietf-ipv6-ula-central-02.txt and NAT
Hi, On Jun 19, 2007, at 5:12 PM, Scott Leibrand wrote: I think what we wanted to get rid of in IPv6 was one-to-many NAT, also know as PAT (among other names). In IPv6, we can stick to one- to-one NAT, which eliminates most of the nastiness we associate with NAT in today's IPv4 world. Really? I thought the annoying bit about NAT was the fact that IP addresses get encoded into higher layers, thus requiring ALG or deep packet inspection. One-to-one NAT would solve the NAT'd server problem, but I thought that was considered a feature by most networks. Rgds, -drc IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT)
> > I would have thought that router renumbering should be no > harder that host renumbering. Essentially all you are > changing is the higher (/48 normally) prefix bits. All > that is required is a method to distribute the set of > prefixes in use with a set of tags (global, deprecated, > ula, advertise in RA, etc.). > > Everything else should flow from that set. Firewall rules > should be using that information as it really doesn't matter > which global prefix a host uses to talk to the world. They > are all essentially equal. > > I may we be showing my ignorance here but I don't believe > that this really is a "to hard" job. > > Mark This prompted a jabber discussion extracts of which follow. note that people who operate routers are usually all about control. automatic renumbering is scary except maybe on the edge There is no loss of control. It would still require a human to add a prefix to the set of prefixes in use. somebody upstream from you renumbers. what happens? With IPv6 I would expect that a both the new and old routes would be published for a period. The old route would then be withdrawn. There is plenty of addresses space. There is no need for instantious changes in addresses. i was talking about control. your upstream adds new prefix, do you add automatically or do you wait for human to approve it? simiarly for your upstream withdrawing, do you withdraw automatically or ... I would expect that there would be due notice give so that humans could be involved. Mark -- 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 ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT)
I would have thought that router renumbering should be no harder that host renumbering. Essentially all you are changing is the higher (/48 normally) prefix bits. All that is required is a method to distribute the set of prefixes in use with a set of tags (global, deprecated, ula, advertise in RA, etc.). Everything else should flow from that set. Firewall rules should be using that information as it really doesn't matter which global prefix a host uses to talk to the world. They are all essentially equal. I may we be showing my ignorance here but I don't believe that this really is a "to hard" job. Mark > Jeroen Massar wrote: > > > 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. > > > > > I think what we wanted to get rid of in IPv6 was one-to-many NAT, also > know as PAT (among other names). In IPv6, we can stick to one-to-one > NAT, which eliminates most of the nastiness we associate with NAT in > today's IPv4 world. > > > But see below for a scenario that might have actual merit here. > > > > > **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. > > > I don't think routers are at the point yet where you can easily renumber > your routers' interfaces when your PA addresses change. As a result, > networks wanting to avoid the pain of renumbering, but who don't qualify > for PI and a global routing slot, might want to do something similar: > > Say a network gets a ULA-C block, and numbers everything on their > network out of that block. They later connect to the Internet, and get > a PA block from their upstream, and configure it on their border > routers. To avoid reconfiguring all their routers every time they > change upstreams, they configure one-to-one NAT on their border routers, > such that every address on their internal network (which is ULA-C) maps > to the same address, except with different first 48 bits, in their > provider-allocated block. > > This wouldn't present the same kinds of problems you'd get from > one-to-many NAT, but I'm sure there are some ways where this wouldn't be > as good as PI space. However, my first-order evaluation is that it > would be better to have small networks achieve their provider > independence this way, rather than by relaxing the PI rules and > threatening the scalability of the current routing system with a large > number of additional non-aggregatable netblocks. > > Now as expressed earlier, most ULA-C use cases probably won't involve > NAT. But if people do elect to use NAT with ULA-C, what problems do you > see with this kind of use of NAT? Do you see those problems as worse > than the problems caused by completely rejecting the original PA-only > architecture of IPv6 in favor of PI-for-everyone? > > 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. > > > > > I agree that PI space, if it were widely available, would meet the same > needs as ULA-C. However, I think we need to be realistic that > PI-for-everyone won't fly, and need to think creatively about ways to > achieve the same goals (such as provider independence) in such a way > that we don't impose more public cost than private benefit. > > Another thing to consider when evaluating whether to specify something > like ULA-C is that we can't know what kind of innovation it will make > possible in the future. Therefore, the question we should be asking is, > is there any remaining reason *not* to allow networks to register ULA-C > space? When it was last proposed there was: it was thought that > networks would get ULA-C and use it as PI space. Now, since PI space is > readily available to multihomed networks, that is much less likely. As > a result, I am in favor of allowin
Re: draft-ietf-ipv6-ula-central-02.txt and NAT
Jeroen Massar wrote: 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. I think what we wanted to get rid of in IPv6 was one-to-many NAT, also know as PAT (among other names). In IPv6, we can stick to one-to-one NAT, which eliminates most of the nastiness we associate with NAT in today's IPv4 world. But see below for a scenario that might have actual merit here. **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. I don't think routers are at the point yet where you can easily renumber your routers' interfaces when your PA addresses change. As a result, networks wanting to avoid the pain of renumbering, but who don't qualify for PI and a global routing slot, might want to do something similar: Say a network gets a ULA-C block, and numbers everything on their network out of that block. They later connect to the Internet, and get a PA block from their upstream, and configure it on their border routers. To avoid reconfiguring all their routers every time they change upstreams, they configure one-to-one NAT on their border routers, such that every address on their internal network (which is ULA-C) maps to the same address, except with different first 48 bits, in their provider-allocated block. This wouldn't present the same kinds of problems you'd get from one-to-many NAT, but I'm sure there are some ways where this wouldn't be as good as PI space. However, my first-order evaluation is that it would be better to have small networks achieve their provider independence this way, rather than by relaxing the PI rules and threatening the scalability of the current routing system with a large number of additional non-aggregatable netblocks. Now as expressed earlier, most ULA-C use cases probably won't involve NAT. But if people do elect to use NAT with ULA-C, what problems do you see with this kind of use of NAT? Do you see those problems as worse than the problems caused by completely rejecting the original PA-only architecture of IPv6 in favor of PI-for-everyone? 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. I agree that PI space, if it were widely available, would meet the same needs as ULA-C. However, I think we need to be realistic that PI-for-everyone won't fly, and need to think creatively about ways to achieve the same goals (such as provider independence) in such a way that we don't impose more public cost than private benefit. Another thing to consider when evaluating whether to specify something like ULA-C is that we can't know what kind of innovation it will make possible in the future. Therefore, the question we should be asking is, is there any remaining reason *not* to allow networks to register ULA-C space? When it was last proposed there was: it was thought that networks would get ULA-C and use it as PI space. Now, since PI space is readily available to multihomed networks, that is much less likely. As a result, I am in favor of allowing small networks to register their own unique private space, as this draft would do. I can't predict how ULA-C will be used, but I'm confident that innovation is a good thing, and that we can safely open up the ULA-C sandbox to networks who wish to use it. -Scott IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
> > 4.1 DNS Issues > > > 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. > > > We have to be *very* careful here. If we allow PTR's to > > be installed in the global DNS then globally reachable > > nameservers *have* to exist for each prefix allocated. > > Otherwise the problems that the AS112 project is trying to > > deal with will appear here as well. > > > This is a long term operational cost associated with ULA-C. > > Well, please expand on this so we can discuss in more detail. > > My assumption is that some (but not all) ULA-C holders will want to be > able to have PTR records. This seems operationally useful to me, for > those that choose to use them and place them in the public DNS > tree. Thus, we shouldn't ban it outright. That is, the question is > whether the RIRs then would need to support the creation of such > records for registered ULA-C owners. > > And help me understand how this equates to the AS112 issues. For sites > that (today) get PI space and don't actually advertise it to the > internet, aren't the DNS issues _exactly_ the same? Yes they are similar but I suspect that the scale of traffic will differ markedly. One thing I can be certain of. There will be reverse queries for ULA-C space. A lot of these queries will originate from sites using ULA-C but have not setup nameservers to intercept those queries because they don't care about the reverse mappings. Shifting the NXDOMAIN load from the servers for C.F.IP6.ARPA will be harder than shifting the load from the IN-ADDR.ARPA servers for 10.IN-ADDR.ARPA was because C.F.IP6.ARPA will be in use and the NXDOMAIN load will be randomly spread below C.F.IP6.ARPA. I also believe that most but not all of the sites using ULA-C will have other routable space. Requiring that some of the servers are not ULA-C is not a excessive burden. Failure to supply nameservers is cost shifting which we should not be encouraging. I really don't want to have to add C.F.IP6.ARPA to the list of namespaces in draft-ietf-dnsop-default-local-zones. We will have failed with ULA-C if that occurs. Mark > Thomas -- 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 ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
Scott Leibrand wrote: > Templin, Fred L wrote: >>> Which won't work, as ULA-C's are not in the routing tables, they >>> won't pass >>> uRPF checks and thus those packets of yours will get dropped to the >>> floor. >>> >>> When you got gear you are going to attach to the internet request a >>> PI or a >>> PA block and use a global unicast address. >> >> Which Internet? The existing IPv4 one, or a future IPv6 one? That common thing that is commonly present in ISP tables. Now if ULA-C becomes part of that, then it is not 'local' anymore of course and we just have another form of PI. > Or, to ask the question another way, does it make sense to use uRPF to > drop packets sourced from ULA-C blocks? I refer you to BCP38 for a LOT of reasons on why to enable uRPF checks. One of those is the most common one: spoofing. > Our current implementations of loose uRPF are rooted in IPv4 justifications, > most notably that private IP space (RFC 1918) is non-unique, so we have no > idea where the packet came from, so we might as well drop it. And do you have any idea at all where ULA-C packets come from? Can you send return packets to them? Remember, that ULA addresses should not be present at all on that generic thing that people call the Internet. Or is spoofing again very happily allowed. Also please take into consideration the recent quibble over RH0. Networks which do proper uRPF checks didn't have any problems with these packets as those packets would never be able to pingpong on those networks simply because of a wrong source address. > I'm not sure that applies in > the IPv6 world, where an ICMP packet can be sourced from ULA-C space or > non-routed PI space and can have perfectly valid DNS and whois > information associated with its source address. Since when do routers look in DNS and whois? If they would do that we would have id/loc, now that would be great. Scott Leibrand wrote: >> Leo Vegoda wrote: >> Is this not already possible with a /48 PI assignment from ARIN? > > Yes, but only if you "qualify for an IPv4 assignment or allocation from > ARIN under the IPv4 policy currently in effect." That currently means > you must either be a large network (qualifying for a /20), or you must > be large enough to run BGP, be multi-homed, and be large enough to > justify a /22. Then change the RIR policy, don't go invent some strange address type that will only cause problems in the end and will just be a surrogate PI space. RIR's should be giving out address space on the justification of NEED by the requesting organization, not by the need to control routing entries because some ISP's are scared of having to upgrade their routers. If that latter group is scared, filter out the PI blocks and everything you don't want to see and let those folks pay you for a slot in your routing tables. Anything that is going to be connected one way or the other today, tomorrow or possibly somewhere in the future to that that called 'the Internet' aka the stuff using global unicast space should steer far and clear from ULA. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
Templin, Fred L wrote: Which won't work, as ULA-C's are not in the routing tables, they won't pass uRPF checks and thus those packets of yours will get dropped to the floor. When you got gear you are going to attach to the internet request a PI or a PA block and use a global unicast address. Which Internet? The existing IPv4 one, or a future IPv6 one? Or, to ask the question another way, does it make sense to use uRPF to drop packets sourced from ULA-C blocks? Our current implementations of loose uRPF are rooted in IPv4 justifications, most notably that private IP space (RFC 1918) is non-unique, so we have no idea where the packet came from, so we might as well drop it. I'm not sure that applies in the IPv6 world, where an ICMP packet can be sourced from ULA-C space or non-routed PI space and can have perfectly valid DNS and whois information associated with its source address. -Scott IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
Leo Vegoda wrote: On 20 Jun 2007, at 12:07am, Scott Leibrand wrote: Here's a use case for ULA-C that demonstrates its usefulness, and demonstrates why reverse DNS for ULA-C blocks is a valuable enough service that we shouldn't purposefully break it for the public Internet. Let's say, for example, that I'm a very small ISP with IPv6 PA space from my upstream(s). I give out subnets of that PA space to my customers in an automated dynamic fashion, and I don't run BGP, so I don't need or want PI space. However, I do have some routers with interfaces that need numbering, and I'd rather avoid renumbering them when I change upstreams. Since ULA-C is cheap and easy to get, I register myself a block of it, and use it to number my router interfaces. Since I'd rather my customers saw DNS names instead of IPv6 addresses in their traceroutes, I delegate the reverse DNS for my ULA-C block to a nameserver on my upstream's PA space, and set up proper PTR records for all my routers. Is this not already possible with a /48 PI assignment from ARIN? Yes, but only if you "qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect." That currently means you must either be a large network (qualifying for a /20), or you must be large enough to run BGP, be multi-homed, and be large enough to justify a /22. Is ULA-C a new solution for a problem that's already been solved with PI assignments or does it solve a new problem? I believe there is a gap between the current PI policy, which is targeted at organizations large enough to qualify for a routing slot, and the need many smaller organizations have for their own IP space for various internal uses. Some of those organizations will be happy to use ULA-L, but some will need a guarantee of uniqueness and the ability to list their IP space in DNS (.arpa) and in whois. If we can meet the needs of those organizations without having to relax the requirements for PI space, we can reduce future pressure on the DFZ. -Scott IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
On 20 Jun 2007, at 12:07am, Scott Leibrand wrote: Here's a use case for ULA-C that demonstrates its usefulness, and demonstrates why reverse DNS for ULA-C blocks is a valuable enough service that we shouldn't purposefully break it for the public Internet. Let's say, for example, that I'm a very small ISP with IPv6 PA space from my upstream(s). I give out subnets of that PA space to my customers in an automated dynamic fashion, and I don't run BGP, so I don't need or want PI space. However, I do have some routers with interfaces that need numbering, and I'd rather avoid renumbering them when I change upstreams. Since ULA-C is cheap and easy to get, I register myself a block of it, and use it to number my router interfaces. Since I'd rather my customers saw DNS names instead of IPv6 addresses in their traceroutes, I delegate the reverse DNS for my ULA-C block to a nameserver on my upstream's PA space, and set up proper PTR records for all my routers. Is this not already possible with a /48 PI assignment from ARIN? Is ULA-C a new solution for a problem that's already been solved with PI assignments or does it solve a new problem? Regards, -- Leo Vegoda IANA Numbers Liaison IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-ietf-ipv6-ula-central-02.txt
> When you got gear you are going to attach to the internet Which Internet? The existing IPv4 one, or a future IPv6 one? Fred [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
Scott Leibrand wrote: [..] > Now, whenever anyone does a traceroute into or out of my network, > they'll see ULA-C addresses in the traceroute Which won't work, as ULA-C's are not in the routing tables, they won't pass uRPF checks and thus those packets of yours will get dropped to the floor. These packets will include ICMP Packet Too Big, and when those get dropped, your network is broken, which actually is caused by the usage of a LOCAL prefix on the Internet. Maybe a fist addendum that has to be made: ULA(-C) *MUST* never appear on the wire on the global Internet. If you do that anyway, you simply will cause your network to break: When you got gear you are going to attach to the internet request a PI or a PA block and use a global unicast address. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
Here's a use case for ULA-C that demonstrates its usefulness, and demonstrates why reverse DNS for ULA-C blocks is a valuable enough service that we shouldn't purposefully break it for the public Internet. Let's say, for example, that I'm a very small ISP with IPv6 PA space from my upstream(s). I give out subnets of that PA space to my customers in an automated dynamic fashion, and I don't run BGP, so I don't need or want PI space. However, I do have some routers with interfaces that need numbering, and I'd rather avoid renumbering them when I change upstreams. Since ULA-C is cheap and easy to get, I register myself a block of it, and use it to number my router interfaces. Since I'd rather my customers saw DNS names instead of IPv6 addresses in their traceroutes, I delegate the reverse DNS for my ULA-C block to a nameserver on my upstream's PA space, and set up proper PTR records for all my routers. Now, whenever anyone does a traceroute into or out of my network, they'll see ULA-C addresses in the traceroute. They don't need to actually reach those addresses if they're not in my network, but they will at least be able to resolve PTR records for them, so that the traceroute cleanly shows whose network they're traversing. And whenever I decide to switch upstreams, all I have to do is update my DHCP servers, update my nameserver's A record to an IP out of my new upstream's PA space, and we're done. I don't have to renumber a single router, I don't have to run BGP, and I don't have to litter the DFZ with another PI block. -Scott [EMAIL PROTECTED] wrote: IMHO, if reverse DNS is provided, it should be required that the authoritative DNS servers have non-ULA addresses. Not only that, but since the goal of ULA-C addresses is to provide something similar to what site-local was going to be, perhaps the RIRs should operate authoritative reverse DNS servers for the entire ULA-C space to ensure that reverse DNS for ULA-C addresses is permanently broken on the public Internet. Of course, anyone who wants to run their own internal reverse DNS in their own private network, or networks, should feel free to do so. Is the goal of this document merely to define the ULA-C address range well enough to throw it into the lake and see if it sinks or swims? Or is there some requirement to provide a more workable form of site-local addresses? --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
Is the goal of this document merely to define the ULA-C address range well enough to throw it into the lake and see if it sinks or swims? Or is there some requirement to provide a more workable form of site- local addresses? The central ULA's should to be viewed in contrast to the currently defined locally assigned ULAs (RFC4193). They share almost all of the properties except for the degree of uniqueness (and, of course, the ability to self-generate the prefix). Central ULA's are guranteed to be unique vs. locally assigned ULA have a very high probability of uniqueness. Centrally assigned ULA's are for organizations that need an absolute guarantee of uniqueness, not just a very high probability. This applies to large enterprises who want to use these internally and for private connections to other enterprises, and for usage currently being discussed in the RIR community. Bob IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-ietf-ipv6-ula-central-02.txt
> IMHO, if reverse DNS is provided, it should be required that > the authoritative DNS servers have non-ULA addresses. Not only that, but since the goal of ULA-C addresses is to provide something similar to what site-local was going to be, perhaps the RIRs should operate authoritative reverse DNS servers for the entire ULA-C space to ensure that reverse DNS for ULA-C addresses is permanently broken on the public Internet. Of course, anyone who wants to run their own internal reverse DNS in their own private network, or networks, should feel free to do so. Is the goal of this document merely to define the ULA-C address range well enough to throw it into the lake and see if it sinks or swims? Or is there some requirement to provide a more workable form of site-local addresses? --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
Pekka Savola <[EMAIL PROTECTED]> writes: > On Tue, 19 Jun 2007, Thomas Narten wrote: > > And help me understand how this equates to the AS112 issues. For sites > > that (today) get PI space and don't actually advertise it to the > > internet, aren't the DNS issues _exactly_ the same? > IMHO, if reverse DNS is provided, it should be required that the > authoritative DNS servers have non-ULA addresses. For the glue records? Absolutely. Well, actually, this discussion may need to be nuanced. The requirement should be that that if there is a PTR record (i.e., with a delegation chain starting at in-addr.arpa), the authoritative servers that would be traversed in chasing down the record must all be globally reachable. That probably means non-ULA addresses, though there might be some edge cases. > I think Mark was assuming that ULA address for authoritative > delegation point might be OK, which would lead to issues if the ULA > address is not reachable from everywhere where reverse DNS lookups > should succeed. Not acceptable to have glue records that contain addresses that are not generally reachable. The DNS is not designed to operate efficiently in such an environment. Thomas IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt - reverse DNS
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 > > 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 ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
On Tue, Jun 19, 2007 at 04:54:36PM +0100, Jeroen Massar wrote: > When the prefix is 'local' why would that need to be rooted into the global > Internet? I get the point about having unique addresses out of the same > namespace, but I don't get why reverses then have to be supplied too. 1) by putting it in the global space, every single recursive dns server in an organization doesn't have to special case (read: slave or conditional forwarding) ULA reverse zones to get accurate PTR records. 2) two (or more) different organizations who agree to use ULA-C space (e.g. as part of a partnership) don't have to do even funkier dns tricks than #1 to have accurate PTR records for both sides. best of all: by delegating, we avoid the AS112 problem as well. additionally, there is a draft going through the dnsops WG speaking to the advantages and pitfalls of reverse dns. wherever possible we should encourage PTR records to be accurate as possible for as many people as possible. delegating ULA-C allocations to globally reachable nameservers hurts no-one and can only potentially be useful information. > What is the point of that? How can a ULA address reach a global unicast > address or for that matter, how is such a ULA address, which is most likely > going to be the sole user of those reverse servers going to contact any of > the root servers, .arpa servers, RIR servers etc to actually find out where > that server is located in the first place? devices on ULA addresses could contact recursive nameservers that have a global unicast address and can resolve on their behalf. some machines may even have both a ULA-C address AND a global address. > Are those people going to do NAT from their ULA space? Then please directly > kill this whole ULA proposal completely. If NAT is involved in anyway it > should never see daylight. this has nothing to do with NAT, but thanks for bringing out the boogeyman. > Also, registered the DNS servers in the global DNS thus means that those > machines will be Internet connected, then what is the point of ULA again? the delegation should be to global unicast space, not to ULA-C space. you'll have to find another reason to ask "what's the point?", i guess. > reverse tree, then there will also be ULA 's in the forward tree, oh boy > we are going to have a nice mess there... people put RFC1918 addresses in A records today and the internet hasn't imploded as a result yet. if you're a partner of mine, lookup an RFC1918 address i have in the global dns, and you can reach that address through a prefix i give you as part of our partnership: that RFC1918 record in the global DNS is useful to you. what's the difference between that and ULA-C, besides the fact that i don't have to worry about which company's network addressing tomorrow's merger/acquisition/partnership/etc uses.. like i do with RFC1918. if you have no relationship with me (or my potential ULA-C space) then what does it matter to you if i put ULA-C addresses in my forward zones or have my reverse ULA-C space delegated to a globally reachable server. i have a great counter-argument: since routing slots are oh so valuable and are driving policy decisions (e.g. minimum allocation size in ARIN) and engineering efforts (e.g. SOMEONE MIGHT LEAK ULA-C!), perhaps malloc() slots in your DNS servers are so important that you might inadvertantly cache one of my records that points to space you can't reach. in the interest of the memory footprint DNS servers everywhere we can't allow ULA[-C] addresses to ever be in the global dns space! -- - bill fumerola / [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-ietf-ipv6-ula-central-02.txt - reverse DNS
I fail to see the point of mandating non-routable space with allocated ULA-C. Any network administrator has the ability and freedom to not route as much or as little of their PI space as they want. Why force constraints on usage? If they are going to link two physically seperated sites (into a WLAN or MLAN for example) with 'private' IP's then isn't that just access-listed PI? Please explain to me what you could do with ULA-C that you can't do with PI and an ACL. I really want to understand. The only possible use I can figure is so that soho router manufacturers can have something to hard-code in to their LAN/DHCP defaults, but even then there would have to be a subnet parameter passed to the router by DHCP unless one was going to assume that the WAN network was the entire PI space. Thanks in advance for the constructive education. Kevin > -Original Message- > From: Pekka Savola [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 19, 2007 2:41 PM > To: Jeroen Massar > Cc: Thomas Narten; Mark Andrews; ipv6@ietf.org > Subject: Re: draft-ietf-ipv6-ula-central-02.txt - reverse DNS > > On Tue, 19 Jun 2007, Jeroen Massar wrote: > > What is the point of that? How can a ULA address reach a global > > unicast address or for that matter, how is such a ULA > address, which > > is most likely going to be the sole user of those reverse servers > > going to contact any of the root servers, .arpa servers, > RIR servers > > etc to actually find out where that server is located in > the first place? > > > > Are those people going to do NAT from their ULA space? Then please > > directly kill this whole ULA proposal completely. If NAT is > involved > > in anyway it should never see daylight. > > I do not know the intended deployment scenarios, 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.) > > You're right that if a ULA(-C) site would have no global > addresses whatsoever, reverse-DNS delegations can't be done. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oykingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-ietf-ipv6-ula-central-02.txt
> Jeoren, what about this quote from the draft: Sorry I mutilated your name again! Jeroen. Bert IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
I-D ACTION:draft-ietf-ipv6-ula-central-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Centrally Assigned Unique Local IPv6 Unicast Addresses Author(s) : R. Hinden, et al. Filename: draft-ietf-ipv6-ula-central-02.txt Pages : 11 Date: 2007-6-18 This document defines Centrally allocated IPv6 Unique Local addresses. These addresses are globally unique and are intended for local communications, usually inside of a site. They are not expected to be routable on the global Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-02.txt To remove yourself from the I-D Announcement list, send a message to [EMAIL PROTECTED] with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-ula-central-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: "FILE /internet-drafts/draft-ietf-ipv6-ula-central-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-ietf-ipv6-ula-central-02.txt
> -Original Message-
> From: Jeroen Massar [mailto:[EMAIL PROTECTED]
> What is the point of that? How can a ULA address reach a
> global unicast
> address or for that matter, how is such a ULA address, which
> is most likely
> going to be the sole user of those reverse servers going to
> contact any of
> the root servers, .arpa servers, RIR servers etc to actually
> find out where
> that server is located in the first place?
[ ... ]
> Another point here is that when there will be ULA registrations in the
> reverse tree, then there will also be ULA 's in the
> forward tree, oh boy
> we are going to have a nice mess there...
Jeoren, what about this quote from the draft:
4.1 DNS Issues
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.
Bert
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt - reverse DNS
On Tue, 19 Jun 2007, Jeroen Massar wrote: What is the point of that? How can a ULA address reach a global unicast address or for that matter, how is such a ULA address, which is most likely going to be the sole user of those reverse servers going to contact any of the root servers, .arpa servers, RIR servers etc to actually find out where that server is located in the first place? Are those people going to do NAT from their ULA space? Then please directly kill this whole ULA proposal completely. If NAT is involved in anyway it should never see daylight. I do not know the intended deployment scenarios, 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.) You're right that if a ULA(-C) site would have no global addresses whatsoever, reverse-DNS delegations can't be done. -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
Pekka Savola wrote: > On Tue, 19 Jun 2007, Thomas Narten wrote: >> And help me understand how this equates to the AS112 issues. For sites >> that (today) get PI space and don't actually advertise it to the >> internet, aren't the DNS issues _exactly_ the same? > > IMHO, if reverse DNS is provided, it should be required that the > authoritative DNS servers have non-ULA addresses. I think Mark was > assuming that ULA address for authoritative delegation point might be > OK, which would lead to issues if the ULA address is not reachable from > everywhere where reverse DNS lookups should succeed. What is the point of that? How can a ULA address reach a global unicast address or for that matter, how is such a ULA address, which is most likely going to be the sole user of those reverse servers going to contact any of the root servers, .arpa servers, RIR servers etc to actually find out where that server is located in the first place? Are those people going to do NAT from their ULA space? Then please directly kill this whole ULA proposal completely. If NAT is involved in anyway it should never see daylight. Also, registered the DNS servers in the global DNS thus means that those machines will be Internet connected, then what is the point of ULA again? Another point here is that when there will be ULA registrations in the reverse tree, then there will also be ULA 's in the forward tree, oh boy we are going to have a nice mess there... I really can't see how 'registering DNS servers in the global root' is going to be beneficial to having 'local' address space. It will only wreak a lot of problems and cause people to do NAT. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
On Tue, 19 Jun 2007, Thomas Narten wrote: And help me understand how this equates to the AS112 issues. For sites that (today) get PI space and don't actually advertise it to the internet, aren't the DNS issues _exactly_ the same? IMHO, if reverse DNS is provided, it should be required that the authoritative DNS servers have non-ULA addresses. I think Mark was assuming that ULA address for authoritative delegation point might be OK, which would lead to issues if the ULA address is not reachable from everywhere where reverse DNS lookups should succeed. -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
Thomas Narten wrote: [..] >> We have to be *very* careful here. If we allow PTR's to >> be installed in the global DNS then globally reachable >> nameservers *have* to exist for each prefix allocated. >> Otherwise the problems that the AS112 project is trying to >> deal with will appear here as well. > >> This is a long term operational cost associated with ULA-C. [..] > And help me understand how this equates to the AS112 issues. For sites > that (today) get PI space and don't actually advertise it to the > internet, aren't the DNS issues _exactly_ the same? When the prefix is 'local' why would that need to be rooted into the global Internet? I get the point about having unique addresses out of the same namespace, but I don't get why reverses then have to be supplied too. Which leads to the point I wanted to ask: How is ULA-C different from PI? Yes, the prefix it comes from is different, which allows 'easy filtering'. But do you suddenly trust fc00::/7 more than global unicast? Also, unless there is a considerable (important) portion of the Internet that will not accept ULA-C prefixes, or the ULA-C prefix in question has a lot of value, this will become a routing mess as people will start announcing them and using them where possible. PA is also being chopped up by some who are announcing /48's already and even tricks like getting a /31 and announcing two completely separate /32's without the aggregate /31. The draft is more or less okay IMHO. But the big question is if it is really needed when there is PI already that can be used for this same purpose. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
> 4.1 DNS Issues > 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. > We have to be *very* careful here. If we allow PTR's to > be installed in the global DNS then globally reachable > nameservers *have* to exist for each prefix allocated. > Otherwise the problems that the AS112 project is trying to > deal with will appear here as well. > This is a long term operational cost associated with ULA-C. Well, please expand on this so we can discuss in more detail. My assumption is that some (but not all) ULA-C holders will want to be able to have PTR records. This seems operationally useful to me, for those that choose to use them and place them in the public DNS tree. Thus, we shouldn't ban it outright. That is, the question is whether the RIRs then would need to support the creation of such records for registered ULA-C owners. And help me understand how this equates to the AS112 issues. For sites that (today) get PI space and don't actually advertise it to the internet, aren't the DNS issues _exactly_ the same? Thomas IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02
> In this draft it has some requirements for generating ULA-C prefixes and > then in 7.0 it requires the RIRs to publish an RFC documenting how they > will implement these requirements. I don't think the RIRs necessarily need to publish an RFC. The main point is for the RIRs to have sufficiently documented what they propose to do so that everyone is happy with proposal and it's written down somewhere. The details of exactly what documentation is sufficient can be discussed and shouldn't become a rathole relative to the bigger question of whether ULA-C shold go forward at all. > But a better way is for the ULA-C document to include this. Well, one thing to balance here is the part the IETF specifies and the part the RIRs specify (in terms of operational policy). Putting it all in one document complicates that and might result in the some of the text appearing to come from the IETF (and the IETF then being authoritative) rather than the RIRs. I don't think we want that either. > I note that any algorithm for checking (and registering) a generated > prefix in the 5 RIR databases could easily be done in advance so > that each RIR keeps a supply of unique ULA-C prefixes on hand based > on their forecast rate of requests for such addresses. There are lots of ways of achieving uniqueness. One thing the authors discussed quite a bit (with rough consensus at best!) was to what degree the operational details of how to carry out the proposal should be specified in this ID. Personally, I'd rather see less detail in the IETF document, with it concentrating on the desired/required properties of ULA-Cs. Presumably, if we define the properties clearly/properly, how they are produced operationally would be a detail and not really our concern, i.e., so long as the desired properties are preserved. Thomas IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
