Subject: [homenet] a modest proposal

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Jul 2012 11:08:14 -0700

I know this is ietf week, but...

If we believe that ipv6 is ready to go for mass deployment, why do we
not pressure home router vendors to default to sending router advertisements
with ULA addresses that, if necessary, get NAT'd at the border just like
192.168 space does today.

I mean, nothing bad would happen, right?

Mike

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Jul 2012 19:08:58 -0400

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:
    Michael> If we believe that ipv6 is ready to go for mass deployment, why do we
    Michael> not pressure home router vendors to default to sending router advertisements
    Michael> with ULA addresses that, if necessary, get NAT'd at the border just like
    Michael> 192.168 space does today.

    Michael> I mean, nothing bad would happen, right?

Do you mean, NAT64'ed?

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Erik Kline <[email-masked]>
Date: Tue, 31 Jul 2012 08:09:49 +0900

> I mean, nothing bad would happen, right?

Even if the user doesn't have global IPv6 connectivity?

And: what /good/ would happen?

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Jul 2012 16:14:02 -0700

>      Michael> I mean, nothing bad would happen, right?

Yes, just nat v6 internal addresses to v4 on the isp side when you
don't have v6 connectivity. If you're reading this and inclined to
a NAT rant, you probably didn't understand my post.

Mike

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Jul 2012 19:32:50 -0400

>> Do you mean, NAT64'ed?

    Michael> Yes, just nat v6 internal addresses to v4 on the isp side when you
    Michael> don't have v6 connectivity. If you're reading this and inclined to
    Michael> a NAT rant, you probably didn't understand my post.

I'm not going to rant until I understand you, thus my question.
How does ULA+NAT64 at the edge replacing RFC1918+NAT44 change the world?

I think it would be a nice thing to do, and it requires no standards
action.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Erik Kline <[email-masked]>
Date: Tue, 31 Jul 2012 08:37:40 +0900

> I think it would be a nice thing to do, and it requires no standards
What happens when that customer's ISP eventually gets around to
IPv6-provisioning the customer.  If some customer device chooses the wrong
prefix to originate connections we'll be introducing a requirement for
NAT66.  You could try to rely on longest prefix matching 3484 behaviour to
save you, but...idk.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Jul 2012 16:40:48 -0700

> I think it would be a nice thing to do, and it requires no standards

Yes, that's exactly what I meant. It changes the world in that it
gets the masses of people using and getting familiar with v6 and
all of its considerations. I've heard (?) there are v6-only ISP's but
for the rest of us unwashed masses, it's still rfc1918 and NAT's
where if you are geeky enough to look at an ifconfig you'd see
a boring link local address that never gets used for much of anything.

As far as standards, one thing it may be interesting to this working
group is the assignment of ULA's across homenet routers. AFAIK
there isn't a way to do that automagically?

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Jul 2012 16:44:06 -0700

On 07/30/2012 04:37 PM, Erik Kline wrote:
> What happens when that customer's ISP eventually gets around to IPv6-provisioning the customer.  If some customer device chooses the wrong prefix to originate connections we'll be introducing a requirement for NAT66.  You could try to rely on longest prefix matching 3484 behaviour to save you, but...idk.

As I said, what could go wrong, right? That's sort of the point of
my most modest proposal -- find out sooner rather than later.

Mike

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 30 Jul 2012 20:10:49 -0400

In message <[email-masked]>
Michael Thomas writes:
 
> >      Michael> If we believe that ipv6 is ready to go for mass
> >      Michael> deployment, why do we 
> >      Michael> not pressure home router vendors to default to sending
> >      Michael> router advertisements 
> >      Michael> with ULA addresses that, if necessary, get NAT'd at
> >      Michael> the border just like 

Mike,

There would be no advantage to either the user or the service provider
to allocate from IPv6 PI space rather than IPv4 PI.

Whether the user has a 10/8 with 16 million hosts, or a /64 with 16
billion billion (whatever that is called), makes no difference.

The provider needs to allocate exactly one IPv4 address if we are
doing NAT64.  If the whole neighborhood is connected as in a consumer
ISP, then they allocate a large pool.  Last I was on one of those, the
pool was a /20 with 4,906 IPv4 addresses.  It doesn't take long to run
out of IPv4 addresses that way.  And we pretty much have done so.

Allocating IPV4 PI addresses on the client side and IPv6 on the
service provider side doesn't help either.  The client could only
address IPv4 content providers and to make a IPv4-in-IPV6 address at
least one routable IPv4 address is needed on the NAT.  If the NAT
still needs one IPv4 address, nothing is gained on the provider side
(where the IPv4 address depletion resides).

If you see some advantage that solves the IPv4 address depletion (a
big point of the transition to IPv6 exercise), then I've missed it.
If so, please point out what I missed.

If both side, client and provider, are IPv6, then there is no reason
to bother with a NAT at all.  The router doing the NAT has to know its
own IPv6 routable address.  That address has to be configured or
learned somehow such as via DHCP.  There is nothing to be gained by
handing out a /128 to the router for it to NAT, rather than handing
out a routable /64 and letting the customer router allocate routable
addresses.  There are 4 billion times as many IPv6 /64 available as
there are IPv4 addresses so NAT is unnecessary.

I hope this wasn't perceived as a rant about NAT.

Curtis

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Jul 2012 17:20:10 -0700

> If so, please point out what I missed.

No, not at all and not the point. I'm just of the mind that if
we believe that v6 is really, really ready to go there shouldn't
be any problem in substituting rfc1918 v4 space with v6 ULA
space. If that modest change leads to trouble...

Mike

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jul 2012 17:21:02 -0700

> I mean, nothing bad would happen, right?

What does the conditional phrase "if necessary" mean in your mind?  Under what circumstances do you imagine this would not be "necessary" for operational continuity?

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Jul 2012 17:22:21 -0700

> What does the conditional phrase "if necessary" mean in your mind?  Under what circumstances do you imagine this would not be "necessary" for operational continuity?

When you have native v6 connectivity.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Jul 2012 17:23:53 -0700

> What does the conditional phrase "if necessary" mean in your mind?  Under what circumstances do you imagine this would not be "necessary" for operational continuity?

I should add that by native v6 connectivity, you'd also be getting a
provider public v6 as well where rfc3484 saves the day.

Mike

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jul 2012 18:03:10 -0700

On Jul 30, 2012, at 17:23 , Michael Thomas <[email-masked]> wrote:
> 
> I should add that by native v6 connectivity, you'd also be getting a provider public v6 as well where rfc3484 saves the day.

I thought as much.  Here's why I considered that idea and rejected it when I was thinking about this problem in the context of a certain home router product.  What happens when I have a persistent connection from my ULA address through the NAT64 path to a remote IPv4 address when the router acquires IPv6 connectivity?

+ If we stop translating all packets to and from the ULA address, then that connection is broken.

+ If we only stop translating packets for new flows, then we effectively break 3rd-party referral for the 64:ff9b::/64 prefix.

+ If we continue translating every packet, potentially in perpetuity, then we break locality of uniqueness by leaking our ULA routability into the global IPv4 Internet.

It seemed clear to me that all of these options collectively exhausted the available alternatives, and they all came with damaging outcomes without any real benefit visible to anyone that I could identify, so I decided not to pursue the idea very vigorously.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Jul 2012 18:29:22 -0700

> It seemed clear to me that all of these options collectively exhausted the available alternatives, and they all came with damaging outcomes without any real benefit visible to anyone that I could i…

I didn't understand your second bullet. So is this a cutover problem or worse?
Even if it's persistent, it surely needs to be able to cope with the connection
being briefly broken.

And of course, such a router or provider would still need to deal with v4-only
sites.

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 31 Jul 2012 09:00:41 +0100

> space. If that modest change leads to trouble...

Well, it surely requires a DNS64 resolver in the CPE too.

   Brian

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Jul 2012 06:05:29 -0700

> Well, it surely requires a DNS64 resolver in the CPE too.
Having embedded DNS functionality in the CPE is sort of a newish
requirement, yes? If we think that's inevitable for real homenets,
maybe this is a means of moving the ball forward?

Mike

---

From: "Howard, Lee" <[email-masked]>
Date: Tue, 31 Jul 2012 09:25:46 -0400

On 7/30/12 5:20 PM, "Michael Thomas" <[email-masked]<mailto:[email-masked]>> wrote:

Why would you try to create problems that don't yet exist?
IPv6 isn't really, really ready to go until it arrives at your doorstep.

Lee

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 31 Jul 2012 11:15:18 -0400

In message <[email-masked]>
 
> space. If that modest change leads to trouble...

It may yield no benefit except to shake out bugs at customer sites.
If so, it would increase support costs for the provider.

Grandma's Windows98 machine needs an IPv4 address and without it she
can't fetch recipes and read occasional email and run bots in the
background.  :-)

Curtis

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Jul 2012 08:27:17 -0700

> can't fetch recipes and read occasional email and run bots in the

To be fair, I think some of the new features being contemplated
here both require ipv6, and would be potentially beneficial without
requiring global v6 connectivity. But shaking out bugs -- and getting
people used to ipv6 -- isn't a Bad Thing, IMO. The more old hat and
normal v6 usage is, the less frightening it will be for ISP's to roll out,
right?

Mike

---

From: Mark Andrews <[email-masked]>
Date: Wed, 01 Aug 2012 01:40:35 +1000

> I mean, nothing bad would happen, right?

Well if you think every piece of software supports HE go for it.

If you want to find every piece of software that doesn't support
HE go for it.

One doesn't need to NAT, just introduce a second prefix when the
home is eventually connected.

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

---

From: "Howard, Lee" <[email-masked]>
Date: Tue, 31 Jul 2012 12:20:01 -0400

>normal v6 usage is, the less frightening it will be for ISP's to roll out,

No.  I don't want to shake out bugs in consumers' homes.

Let's say we did this, and Grandma's machine had a problem.  Who is
supposed to troubleshoot that problem, identify it as IPv6-related, and
submit a bug report?

ISPs are rolling out IPv6.  There is nothing to be gained by breaking
consumer networks before they have IPv6 access.  Let early adopters find
and squish bugs.

Lee

---

From: Benjamin Kerensa <[email-masked]>
Date: Mon, 30 Jul 2012 19:45:02 -0700

> I mean, nothing bad would happen, right?

Correct.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 31 Jul 2012 16:54:11 +0000

Incorrect.
It's my experience that router manufacturers don't have people sitting around twiddling their thumbs wondering how to spend their precious work hours.
The Internet ecosystem is best served by CE routers that have rock-solid "native IPv6" implementations. Given the relatively large quantity of 6rd currently in use to supply IPv6 to customers (around the world), having rock-solid 6rd is also a priority.

Any cycles that router manufacturers spend on development and QA of what you propose, are cycles taken away from coding and QA of the IPv6 functions we really do need. When cycles are taken away from that critical code, the stretched QA resources miss the bugs that the stretched developers introduce both in the code we do need, and in the code for this new function.

Which leaves the ISP's stretched help desk resources supporting customers who not only have buggy native IPv6 and 6rd in their CE routers, but also the IPv4-only customers who now have buggy code for this new proposed functionality.

Which would have the end result of taking resources away from IPv6 deployments and development. Which would slow down IPv6 deployment.

Adding moving parts, potentially breaking things that aren't broken (while providing no discernible-to-the-average-user functionality), and stretching already-stretched resources is not a way to speed up IPv6 deployment. Rather, it's a very good way to slow it down.
Barbara

Correct.

---

From: Mark Townsley <[email-masked]>
Date: Tue, 31 Jul 2012 10:17:26 -0700

On Jul 31, 2012, at 6:25 AM, Howard, Lee wrote:

> 
> 
> On 7/30/12 5:20 PM, "Michael Thomas" <[email-masked]> wrote:
> 
>> 

Agreed.

<chair hat on>

In terms of Internet connectivity, the homenet WG is about getting IPv6 working within the home, once it has arrived from the ISP. There remains the question of the "disconnected" home, where ULAs and LLs are important and within scope. But, we're not working on "transition mechanisms" here. See softwires, behave, v6ops, or maybe sunset4 for that discussion.

- Mark

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

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 31 Jul 2012 17:45:02 -0400

In message <[email-masked]>
 
> maybe this is a means of moving the ball forward?

This requirement is Not at all new.

Most low endish CPE get a single IPv4 address from the provider, do
NAT, offer PI addresses on the "home" side, offer themselves as DNS
resolvers on the home side.  Act as a DNS cache using the
nameserver(s) offerred by the service provider as forwarders.

Most home users get the CPE from the provider and the providers like
having a resolver in the CPE so today this is a business requirement,
not an IETF requirement.

Curtis