Marcelo / Geoff,
> marcelo bagnulo wrote:
> I don't think that the discussion should be focused on IPv6
> only a priori.
> Geoff Huston wrote:
> For me this area of consideration is somewhat orthogonal to
> the V4 / V6 considerations.
That's fine by me, but then we do have some work with the about text:
> We have specified an Internet that works, at the network
> layer, using relatively stable but not permanent identifiers
> for connection endpoints, which are allocated and
> administered using a topology dependent model, implying a
> service provider dependent model
For IPv4 this is untrue, as PI addresses are not allocated using a
topology dependent model and do not imply a server provider dependant
model.
> But we run into problems (the architecture doesn't quite
> fit when we try to address some scenarios encountered in
> real life: multihoming
Untrue for IPv4. The issue with IPv4 multihoming is a scalability issue:
the growth of the routing table (resulting in part from the announcement
of multihomed blocks) induces instability, which is not good. Possibly,
a protocol other than BGP4+ would have a lot less of a scalability
issue, so I don't consider this an architecture issue.
> assembling a local network without necessarily having to contact
> an ISP to obtain address space(e.g.,home net)
Not a problem with IPv4: we have RFC1918.
> Some proposed solutions are challenged in terms of:
> providing referential integrity - how is referential
> integrity maintained when identifiers are not globally
> unique or are overloaded?
The answer to this is simple: either make the identifiers globally
unique, or manage that ambiguous identifiers never collide (or make the
collision risk extremely slow).
> choosing between different identifiers for an object
^^^^^^^^^^^
> which has different "reachability" and the reachability
> is context-dependent
Shouldn't "identifiers" above be "locators"? I vaguely assume that an
object can have multiple locators but should have only one identifier.
Michel.
_______________________________________________
Saad mailing list
Saad@ietf.org
https://www1.ietf.org/mailman/listinfo/saad
