[75348] in North American Network Operators' Group

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

Re: IPV6 renumbering painless?

daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Nov 11 18:49:11 2004

Date: Thu, 11 Nov 2004 15:45:04 -0800
From: Owen DeLong <owen@delong.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>
Cc: NANOG list <nanog@merit.edu>
In-Reply-To: <E0BA4C8D-3438-11D9-9D6A-000A95CD987A@muada.com>
Errors-To: owner-nanog-outgoing@merit.edu


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

>> I still think that we should pursue making the design work and not
>> adopt
>> cruft as standards (ULA).
>
> ULAs aren't cruft. They serve a purpose. If you don't need them, don't
> use them and they won't get in your way.
>
ULAs aren't cruft so long as providers do not start exchanging ULA routes
in the general routing table.  When economics start forcing this issue, =
then
ULAs become a crufty form of PI space.  Since I believe the economics will
force this issue sooner rather than later, I regard ULAs as cruft whether
you agree or not.

> The actual distribution of new IP addresses to boxes is fairly trivial in
> IPv6. DNS is somewhat problematic but nothing a good search and replace
> can't handle. The real issues are IP address based access restrictions
> and problems with ingress filtering when addresses from two ISPs are in
> use at the same time.
>
Agreed.  That is why I would like to see access restrictions move to=20
something
more meaningful than the IP address.  Of course, doing so, requires some
easy form of strong host authentication, such as AH on all packets that =
must
traverse access restrictions.

Ingress filtering shouldn't be that hard, since at least on a theoretical
level you shouldn't, in those cases, be leaking provider A's addresses to
provider B's network and certainly, answers are unlikely to come back from
the other provider.

>>> - Until very recently DNS software did not support A6 records at
>>>   all, and "chain" support for A6 records still seems to be a work
>>>   in progress.
>
>> This is getting resolved and I suspect will be long since functional by
>> the time v6 comes to widespread deployment consideration.
>
> Quite the opposite. There was A6 support in BIND AFAIK, but it's removed
> as it's unworkable. Learn to love AAAA.
>
That's most unfortunate.  A6 had much more promise than AAAA for a variety
of applications.  Oh well.

>> If your organization is large enough to involve reconfiguring a
>> significant
>> number of routers, it is unlikely to be small enough to have to use PA
>> space instead of getting PI space in the v6 world.
>
> There is currently no PI in IPv6 unless you're an internet exchange or a
> root server. Whether there will be is anyone's guess, but it's not
> currently in the pipeline.
>
If we allow ULA, there definitely will be.  If we don't, then, it will be
interesting to see how many ISPs spring up with a single customer=20
(themselves).

>> I still think NAT is evil cruft that had a purpose in the V4
>> world, but, is highly undesirable in the v6 world.
>
> Regardless of the merit of NAT, there is little merit in IPv6+NAT as it
> has all the downsides of both. If you can live with NAT, stay in IPv4 and
> talk to the IPv6 world over IPv4<->IPv6 NAT.
>
Agreed.



Owen

--==========76A8885B47D9AA15D910==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFBk/mAn5zKWQ/iqj0RAgS1AJ4v3iD75fvjtP05v8THfJLtPZsgDQCeI7eK
tjYJwV/sVlxZvirzSrdRATk=
=jC1+
-----END PGP SIGNATURE-----

--==========76A8885B47D9AA15D910==========--


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