Hi, Joel,
My apology for posting this back to RRG. I don't think your comments
are of any bad taste. They are very instructive true to the fact, for
which I thank you a lot.
My next, out of continued shallow knowledge as a novice, would be:
o What not have introduced some mechanism similar ones recently
proposed with virtual prefixes.
o Let user sites use PI prefixes.
o With multiple ISPs, PI would be converted and be advertised as PAa
into the upstream ISPa while as PAb into the upstream ISPb.
o Now that both PI and PA are distributed by a single authority,
that authority would keep/manage a mapping server, {PI, multiple PA}.
o (I'd assume that PI is unique in their own number space across all
user sites.)
o DNS would return (only?) return PI addresses. So, corresponding
users know only my PI address.
o-i When my corresponding user injects the packet with PI
destination into the upstream ISP, that ISP would change the
destination to a PA address of the target receiver.
o-ii Or the conversion might be required of the user themselves, and
they would consult the mapping server to get the other party's PA
address before asking the upstream ISP for delivery.
I'd hope you get the picture what I'm trying to describe here.
Wouldn't this solve the problem and keep only aggregatable
addresses/prefixes be going around in the DFZ?
Or, in the beginning of all these, was there no such idea in vision?
On Sat, Jun 12, 2010 at 11:38 AM, Joel M. Halpern <[email protected]> wrote:
> This gets into a history lesson.
> While there are answers relative to IPv4, it is actually more informative to
> look at the IPv6 situation.
>
> When we produced IPv6, we actually wrote down a rule that said "no PI."
> IANA started allocating blocks to the RIRs. The RIRs worked with their
> members to work out the allocation policies from those blocks.
> The IETF can produce recommendations, but the reality is determined by what
> the operators accept and what the RIRs hand out.
>
> The operators, and their customers, pointed out to the RIRs (whcih they
> control) two specific problems
> 1) Customers needed to be able to multi-home without using multiple
> addresses. Multiple-addressing simply did not work right, and did not solve
> many of the problems.
> 2) Customers need to be able to change service providers without needing to
> renumber every device. At that time, and even now, renumbering just doesn't
> work.
>
> These problems are described in the RRG problem statement.
> Due to these issues, the RIRs decided to hand out PI addresses. The
> operators decided that they would allow this. (It would actually take
> significant work on the routers to keep it from working.)
>
> Unless we can solve these problems, or change the operation so that these
> problems do not cause core scaling problems, it is demonstrably inevitable
> that we will end up with serious problems in the core. (One can debate what
> will break first, with one of the choices being the pocketbooks of the
> operators.)
>
> This is the operational reality we live with.
>
> Yours,
> Joel
>
> Dae Young KIM wrote:
>>
>> (I'm perfectly OK with ILNP. I was just not comfortable with
>> terminologies. So much for that.)
>>
>> As I confessed, I'm not a routing expert. So, please, folks, have some
>> patience with my asking from A and B.
>>
>> As to the problem of routing scalability.
>>
>> My curiosities are:
>>
>> 1. Why, in the first place, did people allow sites to inject PI
>> addresses in DFZ? Why not simply reject PI in DFZ, limiting their use
>> strictly inside a site?
>>
>> 2. As to sites that migrated across ISPs, why not simply throw away
>> old PA addresses injected into a new ISP that is not responsible for
>> service to such foreign addresses?
>>
>> If the two operational rules had been kept strictly, then there would
>> not have been the problem of DFZ routing table explosion.
>>
>> There must be some other compelling reasons why this could not have
>> been done. What are they?
>>
>> And additionally,
>>
>> 3. Is there any slightest chance that the authority (ICANN? IETF?)
>> resume to mandate such strict rules as above to bring back the
>> situation where it ought to have been?
>>
>
--
DY
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
