[184310] in North American Network Operators' Group
Re: How to force rapid ipv6 adoption
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Oct 1 20:58:11 2015
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAB2RJyiqqHjuAffprc0UbBgjo1hNSfp3SeqKooqb9didb5svvw@mail.gmail.com>
Date: Thu, 1 Oct 2015 17:53:28 -0700
To: Todd Underwood <toddunder@gmail.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
OK=E2=80=A6 Let=E2=80=99s look at the ASN32 process.
Use ASN 23456 (16-bit) in the AS-Path in place of each ASN32 entry in =
the path.
Preserve the ASN32 path in a separate area of the BGP attributes.
So, where in the IPv4 packet do you suggest we place these extra 128 =
bits of address?
Further, what mechanism do you propose for forwarding to the 128 bit =
destination by
looking at the value in the 32 bit field?
The closest I can come to a viable implementation of what you propose =
would be
to encapsulate IPv6 packets between IPv6 compatible hosts in an IPv4 =
datagram
which is pretty much what 6in4 would be.
If you want the end host on the other side to be able to send a reply =
packet, then
it pretty much has to be able to somehow handle that 128 bit reply =
address
to set up the destination for the reply packet, no? (No such =
requirements for ASN32).
Seriously, Todd, this is trolling pure and simple.
Unless you have an actual complete mechanism for solving the problem, =
you=E2=80=99re just
doing what you do best=E2=80=A6 Trolling.
Admittedly, most of your trolling has enough comedic value that we laugh =
and get
past it, but nonetheless, let=E2=80=99s see if you have a genuine =
solution to offer or if this
is just bluster.
Owen
> On Oct 1, 2015, at 16:52 , Todd Underwood <toddunder@gmail.com> wrote:
>=20
> I can't tell if this question is serious. It's either making fun of =
the
> embarrassingly inadequate job we have done on this transition out it's
> naive and ignorant in a genius way.
>=20
> Read the asn32 migration docs for one that migrations like this can be
> properly done.
>=20
> This was harder but not impossible. We just chose badly for decades =
and now
> we have NAT *and* a dumb migration.
>=20
> Oh well.
>=20
> T
> On Oct 1, 2015 19:26, "Matthew Newton" <mcn4@leicester.ac.uk> wrote:
>=20
>> 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).
>>=20
>> 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.
>>=20
>> :-)
>>=20
>> Matthew
>>=20
>>=20
>> --
>> Matthew Newton, Ph.D. <mcn4@le.ac.uk>
>>=20
>> Systems Specialist, Infrastructure Services,
>> I.T. Services, University of Leicester, Leicester LE1 7RH, United =
Kingdom
>>=20
>> For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
>>=20
