Subject: Re: [v6ops] Eating one's own dog food

From: Erik Kline <[email-masked]>
Date: Thu, 6 Apr 2017 06:08:13 +0900

On 31 March 2017 at 00:17, Nick Hilliard <[email-masked]> wrote:

> Ted Lemon wrote:
> > I would prefer that the default ietf ssid were IPv6-only with NAT64 for
> > legacy service.   If people want IPv4, they should switch to
> > ietf-legacy.   And if we really want this data to be meaningful, we
> > should change the name of ietf-legacy every IETF so that people have to
> > choose it to get it.
>
> I'd be pleased if this were done at meetings that I regularly attend.

Likewise.

FWIW, I believe that switching the default was proposed at a plenary in the
no too distant past.  The suggestion was for "ietf" to be operated as
"ietf-nat64" and replace "ietf-nat64" with "ietf-dualstack" or
"ietf-legacy".

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Apr 2017 09:52:30 +1200

> "ietf-nat64" and replace "ietf-nat64" with "ietf-dualstack" or

Isn't the -legacy SSID the one with no authentication?

That said, no, I don't agree. The default should be (a) authenticated
and (b) dual stack. I don't buy (and never have, and never will) that
presenting NAT64 as preferable to genuine IPv4 is in the interests of
users. It's second-class dog food. Iff the IETF IPv4 service was
actually CGN it would be a different story; a bakeoff between NAT64
and CGN would be instructive.

    Brian 
> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Fred Baker <[email-masked]>
Date: Wed, 5 Apr 2017 14:58:50 -0700

> On Apr 5, 2017, at 2:52 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> NAT64 and CGN would be instructive.

NAT64 *is* CGN (or at least NAT); it just happens to be between IPv4 and IPv6.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Apr 2017 15:10:19 -0700

On Apr 5, 2017, at 2:52 PM, Brian E Carpenter <[email-masked]> wrote:
> Iff the IETF IPv4 service was

It's almost certainly worth asking why IETF continues to carry around its old, obsolete IPv4 address block to every IETF.   This horribly confounds various geolocation services, so that for example when I tried to share a map to a meeting in Chicago with a bunch of other IETFers, I had to use tethering to get a US IP address so that I could reference maps.google.com <http://maps.google.com/> instead of maps.google.kr <http://maps.google.kr/> (which for some reason was really slow).

There was a time when making sure that every IETF participant had a globally routed IPv4 address was a sensible thing to be doing, but I think that time is solidly in the past at this point.   Nowadays it's like having free morning shoeshine service (leave your shoes outside the door before bed, they'll be shined and returned, in case youngsters are wondering WTH I'm talking about).

I'm not saying we don't need IPv4, but there's no reason to run it as anything other than a legacy (CGN) service at this point: that's how it's run everywhere else, and if we think that running our network differently than the rest of the world is eating our own dogfood, I'm not sure why.

---

From: Erik Kline <[email-masked]>
Date: Thu, 6 Apr 2017 07:10:16 +0900

> NAT64 *is* CGN (or at least NAT); it just happens to be between IPv4 and

Yeah, the IETF networks are extremely rare in handing out public IPv4 space.

For all intents and purposes these days, every device might as well have
the same IPv4 address and default router configured and only the default
router's MAC address needs to be found (with VRRP even that's in the
guessable realm).

---

From: Mark Andrews <[email-masked]>
Date: Thu, 06 Apr 2017 08:14:37 +1000

> and CGN would be instructive.

The point of eating one's own dog food is to expose one to all the
issues of using that dog food.  At the moment we have lots of people
that think NAT64 is something that should be recommended when you
start down the ipv6-only path.  Having them consume this dog food
may make them rethink that opinion.

This is just opt-out rather than opt-in.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Apr 2017 10:24:23 +1200

> NAT64 *is* CGN (or at least NAT); it just happens to be between IPv4 and IPv6.

Yes. But it's still a different beast with potentially different failure
modes and performance impacts. It's not an apples/oranges comparison;
more like comparing two types of orange.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Apr 2017 10:31:57 +1200

> may make them rethink that opinion.

If that's the argument, then we should definitely have a 464XLAT
solution in the choice of dog food too.

But I will always opt for pure dual stack, like I have in my
university office. I have enough experience of dual stack + NAT44
at home, thanks.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Apr 2017 10:45:12 +1200

On 06/04/2017 10:10, Ted Lemon wrote:
...
> I'm not saying we don't need IPv4, but there's no reason to run it as anything other than a legacy (CGN) service at this point: that's how it's run everywhere else, 

Absolutely not true. Many campuses still run a proper IPv4 service, and many ISPs still
don't need to run CGN (of course their subscribers mainly run small-scale NAT44).

There are a lot of CGNs, nobody is denying that. It's been researched:
www.icir.org/christian/publications/2016-imc-cgnat.pdf

   Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 06 Apr 2017 01:02:57 +0200

That’s why long time ago I insisted in not having in the default network public IPv4 addresses, and instead running a CLAT.

This means that we are using GUA+private IPv4 addresses.

In the last IETF at Chicago, I got configured a /64 in my laptop and was running a VM with the CLAT client.

This VM can be actually in the “default” IETF SSID.

If anyone needs IPv4 public address, move over the legacy SSID.

In most of our daily usages networks we get the same configuration, and this is what we will get for some years in homes and offices. That’s the only real “own dog food”.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Erik Kline <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 6 de abril de 2017, 0:10
Para: Fred Baker <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] Eating one's own dog food

    

    For all intents and purposes these days, every device might as well have the same IPv4 address and default router configured and only the default router's MAC address needs to be found (with VRRP even that's in the guessable realm).

    

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Tim Chown <[email-masked]>
Date: Thu, 6 Apr 2017 09:31:22 +0000

> On 5 Apr 2017, at 23:31, Brian E Carpenter <[email-masked]> wrote:
> 

You might ‘opt’ for it, but an argument for NAT64+464XLAT is to avoid needing to support IPv4 in the access network, at least if the CLAT is embedded in the hosts.

Complexity in the host/edge (CLAT/NAT64/DNS64) vs complexity in the network (running two protocols).

I like that the IETF offers NAT64, and pure IPv6-only, and of course dual-stack. 

We’re just bike-shedding on the default.

Tim

---

From: George Michaelson <[email-masked]>
Date: Fri, 7 Apr 2017 08:17:31 +1000

> I like that the IETF offers NAT64, and pure IPv6-only, and of course dual-stack.

me too.

> We’re just bike-shedding on the default.

kinda, but I think deliberately deciding to make the obvious defaults
V6 'primarily' and the clean4 something you have to pick, changes the
dynamic.

I'm not sure thats bike-shed or advocacy. Nudge theory. Social
pranksterism. Japes.

So in the non-bikeshed sense, if the v6ops/6man/homenet nexus
advocated to 'the man' that the default SSID(s) should be
predominantly about v6, I wouldn't personally object and I might even
hum. mutedly. with warrens merrie-old-clown hat on.

-G

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Apr 2017 16:15:32 -0700

On Apr 6, 2017, at 3:17 PM, George Michaelson <[email-masked]> wrote:
> with warrens merrie-old-clown hat on.

I suppose now that Warren has to act all grown-up, someone needs to wear it.   :)

---

From: Lee Howard <[email-masked]>
Date: Thu, 06 Apr 2017 19:34:18 -0400

>hum. mutedly. with warrens merrie-old-clown hat on.

³The man² in this case is Alissa. And Jim Martin.

Lee

---

From: George Michaelson <[email-masked]>
Date: Fri, 7 Apr 2017 11:33:41 +1000

ok. So we ask Alissa, but the requirement is, its RDNSS in RA only.

(ducks...)

-G