[184408] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: How to force rapid ipv6 adoption

daemon@ATHENA.MIT.EDU (Hugo Slabbert)
Fri Oct 2 16:51:46 2015

X-Original-To: nanog@nanog.org
Date: Fri, 2 Oct 2015 13:51:42 -0700
From: Hugo Slabbert <hugo@slabnet.com>
To: Damian Menscher <damian@google.com>
In-Reply-To: <1cffd0.kqhkiG.15029700be0@slabnet.com>
Cc: NANOG mailing list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org


--oPmsXEqKQNHCSXW7
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


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

>My apologies; missed the anchor for some reason and just got the top bits =
of the doc.
>--
>Hugo
>hugo@slabnet.com: email, xmpp/jabber
>also on TextSecure & RedPhone
>
>---- From: Damian Menscher <damian@google.com> -- Sent: 2015-10-02 - 08:45=
 ----
>
>> On Thu, Oct 1, 2015 at 8:54 PM, Hugo Slabbert <hugo@slabnet.com> wrote:
>>
>>> On Thu 2015-Oct-01 18:28:52 -0700, Damian Menscher via NANOG <
>>> nanog@nanog.org> wrote:
>>>
>>>> On Thu, Oct 1, 2015 at 4:26 PM, Matthew Newton <mcn4@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 t=
he
>>>>> 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 lesso=
ns
>>>>> > 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/comm=
on/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=20
basically just intended to ensure that we don't break the database or=20
application when we write an IPv6 address into it because it can only=20
handle an IPv4 value.  I appreciate the hack & know you have a disclaimer=
=20
on there of "only for logging, not routing," but "squeezing 128 bits of=20
address data into a 32 bit field" is a bit of a stretch to describe a=20
process that takes 128 bits, discards 64 of them, and then hashes the=20
remaining 64 bits into 29 bits, no?

>>
>> Damian
>
--=20
Hugo

--oPmsXEqKQNHCSXW7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJWDu5eAAoJEJqxD/2xeDE+exoP/AhO12NfPo+F6P2ydk+RiAMx
UzMBgzH2N9sBqB11StvPCh3GAb5gxoPiHBQmKLPoxd8ZI/B0ak59TDCUVPqv+WJl
E+eyNVVvhETsj1RwSdXmQD3owOr7JiXuwBFhGyj95tKcgXTuuELvXyzVygtfhqVq
1VYrpHUzqj2GY7S6bdrSombZH/vLZ4OGBwgNYHEwBd91VfvNqIa0SBOfrFOEOgDq
NzD0QsohjaEXrIzXa+flI/IncS6vSrbkZixLMbRXp5ePys1XGoJxgs0aUSUXpkqW
8SCJFRO+sxsVMkePms1KSk+dSOz1JVXDO2TQkUsCyw/J3Dt1AbMYErZyPDFjvlUv
jyOZNavbYAIBiPQK3crke987kQUXlowitbrhVQaR6xvahGekop77T5VhDYggJ/+R
qWNGdMaJglkPM9Xq2hM1bs/s1FL3CAxHalMQwXnxloEVlrKGjJYx9//4XztRWLsU
iY6U0ZH9ZCnxAE6X9/2eR5xRAt7hBDD14CAyGnLtBXW7VGox4IqyI0ihYVtchPcd
lu9v66cfFN+DvhCl0KkMWuncmndCRd1qfi5IVleki1LYSW1EWePEIbO4siT4BEFz
68HT8TftYi5Q150W/m4ltSFfQ9dKXDx/kg0YazepeM9B70LjWOFzAhq+WM6UEl+s
2uOZkYUDTu/2qg14Nfts
=3W7n
-----END PGP SIGNATURE-----

--oPmsXEqKQNHCSXW7--

home help back first fref pref prev next nref lref last post