Brian E Carpenter wrote:
Alain Durand wrote:
Brian E Carpenter wrote:
Alain,PA... Do you PI for Provider Independant?
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?
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.
I meant traceable, potentially routable PI. Hinden/Haberman addresses are not traceable (in the sense that looking at the prefix I can tell who it belongs to), and this is a big difference.
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.
if the only thing out there was globally reachable addresses, this problem will go away. I understand that some of those addresses may not be reachable because of firewall, but this is a case of misconfiguration. So I argue that the hinden/haberman draft makes things more complex as it creates two family of addresses, those who are potentially unreachable by design and those who are potentially unreacable by configuration.
I disagree. They share many issues, like the one addressed by the AS112 project- what about address leakage?These addresses are unique, so leakage is nothing like as harmful
as with RFC 1918.
http://www.as112.net/
This is exactly my point: this proposal will make debugging the global InternetI disagree. You cannot say that. Examples:- 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.
- 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.
more difficult.
- 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.
2 is easy. more than 2 gets difficult. Picture the situation: "oh, we have merged so many times, we now have tens of prefixes advertized and we do not know/remember which one is which..." All this because those addresses are untraceable.
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.
Difference of opinion. IMHO, it is not that straightforward, there are many side effects. See above.
- Alain.
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
