Alain Durand wrote: > > Brian E Carpenter wrote: > > >Alain, > > > >Do you think it is better to let the RIRs develop a policy for > >allocating PA space for local use, i.e. create a swamp like IPv4? > > > PA... Do you PI for Provider Independant? > If it is the case, yes I think it would be less damaging to do that. > See below.
I meant PA because that is all that is in the implementors and registries' hands today. Actually any form of PI would do (they are all equally unrouteable today). I regard the Hinden/Haberman addresses as an easy-to-create form of PI. > > > > >In detail.. > > > [Focusing on technology as I think that the other dicussions will > simply not go anywhere in this forum] > > >>impact: > >> - what about reverse DNS? > >> > >> > > > >Suggestions? Is reverse DNS needed for these addresses? You're correct that > >this needs analysis. > > > A valid enough reason to get a -02 published. Sure. That's why we do WG last calls... > > >> - what about address selection rules? > >> > >> > > > >These addresses behave like global scope for that purpose. > > > In terms of scope, you're right. Now take the multi-party > communication example that was described by Erik earlier on, > there is a problem. So you need to add an extra selection rule > and an API to reverse that choice for the cases it does not make > sense. Well, in a sense I think these problems are unsolvable - I think whatever scope semantics we try to impose on the address syntax, there will always be cases where reachability is an experimental question and any algorthmic selection rule will fail. > Note: you cannot do that just by adding entries in the preference > table, this table is global and you need a per-socket oprtion. It may even be worse. If A is trying to decide which address for B to refer to C, the correct choice may be a complicated function of both B and C, and A may have no way to determine which of B's addresses are accessible to C. And I believe we have that problem whatever we do (including doing nothing), so I don't see how the current draft makes it worse. > > >> - what about address leakage? > >> > >> > > > >These addresses are unique, so leakage is nothing like as harmful > >as with RFC 1918. They are also known to be unrouteable globally, so > >can be blackholed at domain boundaries. I thought that was discussed in > >the draft. > > > > > > > >> - how to debug those networks when they will leak? > >> > >> > > > >You don't need to. If you see one of these addresses out of its intended > >domain, you only need to drop it. I'm not saying this lightly - I really > >think this is not an issue. There is nothing to debug. You just don't care. > > > > > I disagree. You cannot say that. Examples: > - you're under security attack from one of those addresses, > you'd like to trace it back. Any tiny bit helps. This in theory of course should be prevented by ingress filtering. It's true (as for RFC 1918) that if they aren't dropped at ingress, tracing back will be very hard. > > - you're doing a complex merge of several local address spaces > and things get ugly. You'd like to have a simple way (like whois) > to know who those prefixes belongs to. I would think that in such a merger you would have that information. Certainly when you merge two networks today you generally know the address prefixes. > > >> and it is impossible to map those prefixes back to their owner? > >> > >> > > > >Doesn't matter. You just drop them. > > > No. see above. > > >>In a rush to create something to replace the Site Local addresses, > >> > >> > > > >It isn't replacing site-local. It's filling a widely perceived need that > >has emerged (with our better understanding of the needs of enterprise and > >inter-enterprise networking) since site-local was invented. > > > >The rush, as I > >said at the top, is to prevent widespread misuse of PA prefixes and to give > >us a chance of preventing NAT6. > > > >If this doesn't get done soon, I think the emphasis will rapidly change to > >working with the RIRs to get a rough and ready policy in place for > >private use of PA space. > > > The real requirement is to have addresses that are not bound to any > provider, > as this because renumbering will never be painless and multi-homing solution > a la Multi6 will take years to be developped. Yes. And don't these addresses have exactly that property? > > So the question is what to do in the meantine. 3 alternatives: > 1- Give a limited amount of PI to those who really want it and let > them pay $$$ to get their ISP to route them > 2- Create this 'local address' kludge that will stay for a long time I don't believe it's a kludge. I believe it's simply a straightforward version of PI. The $$$ argument applies, in fact. > 3- Speed up the work in Multi6. A bit optimistic. Multi6 is still very hard. > None of this comes for free, however my take is that the combination > of 1 and 3 is much less expensive that 2. I can't agree, since I think 2 is a form of 1. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
