Re: [rrg] RRG to hibernation

[[e-mail]]

The recent storm in a glass of water has calmed down again. Silence has returned.
I think the outcome of the RRG doesn't satisfy most of the participants (besides few exceptions) and should not thrill the IAB at all.Precious time by the years has been wasted. The problem due to the IPv4 address depletion turns out to be much worse than the scalability problem. 
LISP appears to be a pull-variant replacing the legacy push-model. Loc-id-split is something else: E.g. my TARA model which  doesn't do EID-to-RLOC mapping nor  disseminate such info (neither by pull nor by push) to make sure that the packet is sent to the right ETR. It simple complies with Elvis Presley's "Return to sender, address unknown, noch such number, no such phone..." if it were sent to the wrong/ not anymore up-to-date  ETR -  
or would append a broadcast search inside the surrounding geopatch.
There is more missing: how to use TTL, peeping into the inner header ?:-( How to form and use a Multicast-Locator, or an Anycast-Locator ? How would it  handle a roaming Multicast-sender? 
Above all however there is no working strategy to deal with the situation where ipv4 is not globally unique anymore. Neither LISP nor ILNP have so far    presented a solution. And the RRG has never discussed the theoretical basics !!! In principle the 4 octet sized ipv4 address must be extended.My proposal: by two additional leading octets - in mind. This doesn't mean that they have to be placed directly in front of the 4 octets.  Particularly, the value = 0000H might be equivalent to "the two octets  aren't placed anywhere at all". But other values might be placed somewhere  (e.g. being part of the locator). 
In the (current) TARA concept it would be the geopatch number in the range 1:64800, resp. the number 64801 for well-known Anycast, and 64802 for well-known Multicast.
There are problems by the numbers. Enough for just the networking layer (TCP should take care by itself when ipv4 looses its globally uniqueness )!
I am not a friend of ipv6 either. Just to share my worries: Imagine a multicast instance where sender and receivers are roaming, where sender and receivers are a mix of ipv4 and ipv6 users, in a world where ipv4 has lost globally uniqueness. Brrrrh.
Hibernation is not the right answer.
Heiner












_______________________________________________
rrg mailing list
[e-mail]
http://www.irtf.org/mailman/listinfo/rrg