Jeroen, I don't quite understand some of your points, so I am not going to try to make conjectures about those. But, I will respond to what I can below:
> -----Original Message----- > From: Jeroen Massar [mailto:[EMAIL PROTECTED] > Sent: Monday, June 25, 2007 10:09 AM > To: Templin, Fred L > Cc: bill fumerola; [email protected] > Subject: Re: draft-ietf-ipv6-ula-central-02.txt > > Templin, Fred L wrote: > [..] > > >> Thus you are connecting to the Internet, using IPv4 or IPv6 doesn't > >> matter, you have a dependency on the Internet. As such you are not > >> working dis-connected from the Internet and you have a > >> dependency on it. > > > > Only when you want to connect to another site. > > Thus the moment you are connecting to another site you are forcing one > to also connect to the Internet. The way I envision for a site to connect to another site is via establishing one or more links between the two sites. Having the two sites come in physical proximity with each other (e.g., due to mobility) is one way. Establishing tunnels between them across the Internet is another way. > [..] > > Again, *no* NAT'ing of IPv6. > > How are you going to use ULA-C addresses as a source and then > connect to > hosts on the global Internet? Not what I am proposing, and not desirable. ULA-C addresses as source may not be compatible with global IPv6 addresses as destination. Isn't that what source address selection is for? I will say again that I do not support IPv6 NAT. > [..] > > A laptop fits this description. Think of one running some > > of this new virtualization support whereby there may be > > many virtual machines connected up by virtual networks > > running within the laptop. (Actually, folks like IBM were > > doing this "new" virtualization on their mainframes back > > in the 70's...) > > I have one of those sweet laptops and I have 3 OS's running > at the same > time most of the time. I use RFC1918 and simply randomly picked > 172.17.123.0/24 which has (upto now :) never collided with > the networks > that I visited. ULA (RFC4193) would have that same property. I have to > note that I have to NAT that address space to the network I am at, who > only give me 1 single IP address most of the time (could use bridging > and prolly ask for more addresses per DHCP of course). Having > them route > my prefix to me though everytime I walk into a Starbucks or a > hotel etc > is really never ever going to happen. There is no "this is my prefix > route my traffic here" protocol (at least yet). Also no single network > operator will ever accept such a protocol as it is their network, not > that of the visitor to control. Viruses and {cr|h}ackers > would love it I > guess. Having my laptop inject its ULA(-C) prefix into a visited network's IGP seems like one alternative, and I have not investigated the various interactions you are describing. But, injecting the prefix may not be the only alternative and maybe not even be the best one. > When you are in the position to negotiate the routing part, > then having > them turn up DNS, which has to happen for both forward (how else are > they going to locate your host) and reverse hosts is very doable. > This then nullifies the whole requirement of having NS > pointers to your > servers, which have to have internet-connected and static addresses > unless you want to update them all the time, which for sure makes the > RIR happy who definitely want to have more cash then for doing that. This is one part that I didn't understand very well. > Or are your requiring sites you visit to have Internet connectivity as > you only have your servers (forward + reverse) on the Internet? Nor this. > >> this can > >> mean indeed a major corporation (who maybe even require > multiple /48's > >> which is why rfc4193 is a bit off to cover those cases) > >> > >> If you want to have a /48 for your laptop, simply use ULA (RFC4193) > >> those are free. > > > > RFC4193 ULA is good, but could be better. However remote the > > possibility of collisions, IMHO there would still be value in > > having a 3rd-party mechanism to avoid duplicate assignments > > and/or de-conflict duplicates. > > It exists: PI space. Get it at ARIN today: $100/year > > Which if you have such a high reliability requirement for > non-clashes is > very cheap and gives you the possibility to do reverse DNS and even > route it on the global internet, just in case they provide you with > transit at the site you happen to come along. I don't know enough about ARIN/PI to know who can get it, how much it costs, how filters could be configured to recognize it, etc. to be able to comment. Pretty much everything I know about it I am learning through your posts, but my off-the-cuff take is "seems too expensive for small sites". > >> Or are you simply wanting to have your own IP > >> addresses, > >> setting up firewalling etc because you have a laptop (or Winnebago > >> filled with servers) and carrying it around globally > through various > >> buildings and making other networks accept your /48 AND > force them to > >> connect to the Internet to be able to resolve your reverse? > > > > I don't quite understand this, but I want to be able to > > drop my laptop down in whatever visited network and have > > it connect to other sites w/o having to manually configure > > explicit VPNs. > > How are you 'automatically' telling the network to route packets for > 'your prefix' to your device? See above. It doesn't have to be through prefix injection into an IGP of the visited network as long as there is a means to set up an edge-to-edge tunnel between my laptop and the site I want to connect to. > >> Most likely anyway when you connect your laptop to another > site they > >> will be providing you with an IP address anyway from their > >> site prefix. > > > > One use I could see for that is if you needed a care-of > > address such as used for MIPv6. > > Care-of-addresses are simply the address you get per DHCP/RA. > > > But, that gets off onto a completely different line of discussion. > > It also has nothing to do with connecting to sites. I was just responding to your assertion that obtaining a topologically-correct address from the visited network was "most likely" going to happen - I was only postulating about one reason as to why that might be so. > >> Can you clarify the use case you are sketching here a lot more as I > >> really want to know what actual use case is actually > useful that ULA-C > >> solves, what PI doesn't solve (Drawings + text help). > Especially now > >> that the folks who 'want/need' ULA-C do want to have reverse DNS > >> available from the Internet, while they want to be local in > >> the first place. > > > > I already gave my use-case in: > > > > http://www1.ietf.org/mail-archive/web/ipv6/current/msg07806.html > > As I mentioned above, how are the routing protocols "automatically" > trusting that you own the prefix, or for that matter finding > each other > in the first place. This will involve a protocol that can handle this. > When such a protocol exists you can also have it handle your > reverse DNS > setup. Edge-to-edge tunnels between sites is perhaps one way to avoid prefix injection in the visited network. > I fully agree that there is a need for "Unique Addresses", and these > exist already, it is called: PI. > > >> All those cases can be covered perfectly fine by PI. Or is it > >> just that > >> folks see ULA-C as 'very cheap PI space'? > > > > Again, I don't know about other folks but for me I see the > > price as too high for some "sites" to have to pay. > > Thus the only reason for ULA-C seems to be that PI is "too expensive". > Folks are always forgetting that there is a need for a lot of other > things which are way more expensive than that: the actual > hardware being > used, power, maintenance, people being payed etc etc etc. > > Why would the IETF have to solve the problem of having "expensive > address space" for the few who simply want it for free, by providing > address space which is only cheaper, but for the rest exactly the same > as existing solutions and in the long run will only cause > people to use > it on the global Internet and thus becoming a cost factor to > everybody? > > Is 2^-40 probability really not enough for those sites? If they can't > cough up $100/year, then they most likely don't have a lot of hosts > actually involved and thus renumbering in the case of a > collision of ULA > (RFC4193) can't be that high either. If the probability is > too high for > them and the cost of renumbering is too high then PI for $100/year is > suddenly really cheap. As such, sorry, but I don't see any > problem that > ULA-C will solve. I do see the problems that it will cause in > the long run. I can only represent my use-case in terms of why someone might want ULA-C; others would have to represent theirs. The only question I see is the source address selection so as to avoid IPv6 NAT'ing. Then again, if all your site ever does is to connect up to other sites with edge-to-edge tunnels then there should be no interactions between its ULAs and the DFZ. Fred [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
