How to force rapid ipv6 adoption

Fri Oct 2 20:51:42 UTC 2015

On Fri 2015-Oct-02 09:43:40 -0700, Hugo Slabbert <hugo at slabnet.com> wrote:

>My apologies; missed the anchor for some reason and just got the top bits of the doc.
>--
>Hugo
>hugo at slabnet.com: email, xmpp/jabber
>also on TextSecure & RedPhone
>
>---- From: Damian Menscher <damian at google.com> -- Sent: 2015-10-02 - 08:45 ----
>
>> On Thu, Oct 1, 2015 at 8:54 PM, Hugo Slabbert <hugo at slabnet.com> wrote:
>>
>>> On Thu 2015-Oct-01 18:28:52 -0700, Damian Menscher via NANOG <
>>> nanog at nanog.org> wrote:
>>>
>>>> On Thu, Oct 1, 2015 at 4:26 PM, Matthew Newton <mcn4 at leicester.ac.uk>
>>>> wrote:
>>>>
>>>> On Thu, Oct 01, 2015 at 10:42:57PM +0000, Todd Underwood wrote:
>>>>> > it's just a new addressing protocol that happens to not work with the
>>>>> rest
>>>>> > of the internet.  it's unfortunate that we made that mistake, but i
>>>>> guess
>>>>> > we're stuck with that now (i wish i could say something about lessons
>>>>> > learned but i don't think any one of us has learned a lesson yet).
>>>>>
>>>>> Would be really interesting to know how you would propose
>>>>> squeezing 128 bits of address data into a 32 bit field so that we
>>>>> could all continue to use IPv4 with more addresses than it's has
>>>>> available to save having to move to this new incompatible format.
>>>>>
>>>>
>>>> I solved that problem a few years ago (well, kinda -- only for backend
>>>> logging, not for routing):
>>>>
>>>> http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/net/InetAddresses.html#getCoercedIPv4Address(java.net.InetAddress)
>>>>
>>>
>>> Squeezing 32 bits into 128 bits is easy.  Let me know how you do with
>>> squeezing 128 bits into 32 bits...
>>>
>>
>> I did just fine, thanks.  (You may want to read the link again.... ;)

Out of curiosity, the method you describe is lossy, though, no?  It is 
basically just intended to ensure that we don't break the database or 
application when we write an IPv6 address into it because it can only 
handle an IPv4 value.  I appreciate the hack & know you have a disclaimer 
on there of "only for logging, not routing," but "squeezing 128 bits of 
address data into a 32 bit field" is a bit of a stretch to describe a 
process that takes 128 bits, discards 64 of them, and then hashes the 
remaining 64 bits into 29 bits, no?

>>
>> Damian
>
-- 
Hugo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20151002/261f63f1/attachment.sig>