Subject: Residential ISPs & IPv6 NAT

From: RJ Atkinson <[email-masked]>
Date: Wed, 19 Mar 2014 10:36:33 -0400

On Tuesday, 18 March 2014, Lorenzo Colitti wrote, in part:
> You can't fix that particular problem [i.e., residential ISPs that
> are stingy with IPv6 prefix delegation]. 
> 
> If you allow shorter than /64, some stingy ISP is going to assign 
> you shorter than /64. That becomes an arms race until you get 
> to /128 and then you have to implement NAT anyway.

+10

Further, the IETF HomeNet WG has taken a very clear stance
that end-users should be allocated a prefix SHORTER THAN /64
-- primarily to ensure that residential (or similar) users 
have enough space to internally subnet (i.e. within their 
home or small office) WITHOUT NEEDING to deploy routing prefixes 
LONGER than /64.  HomeNet also has taken a position against
IPv6 NAT, which is consistent with the preceding position.

The IETF ought not be taking steps to encourage ISPs to delegate
overly long routing prefixes to their end users, for many 
reasons, but including the IETF's clear desire to avoid 
accidentally or intentionally encouraging/requiring IPv6 NAT 
deployment.

Yours,

Ran

---

From: Cb B <[email-masked]>
Date: Wed, 19 Mar 2014 07:45:01 -0700

> accidentally or intentionally encouraging/requiring IPv6 NAT

Ran,

What problem are you trying to solve?

Over several emails on several threads, i still don't know who or what you
are battling.

CB
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Tim Chown <[email-masked]>
Date: Wed, 19 Mar 2014 14:57:10 +0000

> IPv6 NAT, which is consistent with the preceding position.

Indeed. This message was very clear in homenet.

tim

---

From: Cb B <[email-masked]>
Date: Wed, 19 Mar 2014 09:15:18 -0700

> Indeed. This message was very clear in homenet.

This is 6man.  I don't follow homenet.

I don't believe following homenet is required for 6man participation,
perhaps it's best to keep these topics on homenet if there is no
desire to expound on the issue in 6man.

That said, this is not an invitation to expound in 6man without a 6man
I-D to talk about.

CB

---

From: Tim Chown <[email-masked]>
Date: Wed, 19 Mar 2014 16:22:34 +0000

> This is 6man.  I don't follow homenet.

Sure, but homenet is applying the protocols coming out of 6man.

> desire to expound on the issue in 6man.

But it’s relevant to the discussion here.

> That said, this is not an invitation to expound in 6man without a 6man

Which originally was why64, I think… :)

Tim

---

From: David Farmer <[email-masked]>
Date: Mon, 24 Mar 2014 10:56:09 -0500

> Indeed. This message was very clear in homenet.

I agree with this as well, ISPs should delegate shorter that /64 
prefixes to their customers, especially when requested to do so by the 
customer, a customer SHOULD NOT have to do anything more than ask for a 
prefix at least as short as /60.  I prefer /56 or /48, but at least /60.

>> accidentally or intentionally encouraging/requiring IPv6 NAT

However, what if an ISP is unwilling to delegate shorter than a /64 
prefix?  Yes, we can say until we are blue in the face that ISPs OUGHT 
TO (from [RFC6919]) provide longer than a /64 to customers, especially 
when asked.  But, we can't make them, there are no IETF police.

So, if the ISP doesn't provide shorter than /64 prefixes, the IETF 
saying that only /64 subnets are allowed isn't a very satisfying answer 
for the poor customer that needs/wants a shorter than /64 prefix for one 
of these obstinate ISPs in order to allow for more than one subnet 
within their home.  So what do we tell such a customer?

1. "Get a different ISP, that provides longer than /64 prefixes" - Great 
answer, if there is an economically viable alternative.  Note: if you 
just signed a multi-year contract with an ISP, I'm not sure changing 
ISPs can ever be considered an economically viable alternative.  At 
least until the contract is up.

2. "Don't implement IPv6 until you can get longer than /64 prefix" - 
This keeps the purity of /64.  But, I'm not sure its the answer I want 
to give.  As I said in a different email, I'm not courageous enough.

3. "You really don't need multiple subnets" - This keeps the purity of 
/64.  But, only allows a single L2 home network segment.  Probably not a 
problem for many people today, but it's not that hard to think of 
reasons for more than one L2 network segment in a home.

4. "Use ND Proxy [RFC4389], to appear as a single /64 subnet" - This 
keeps the purity of /64.  But, this goes backwards from good L3 
segmentation and essentially collapses to a single L2 home network 
segment.  Note [RFC4389] is Experimental.

5. "Use NAT66, to appear as a single /64 subnet" - This keeps the purity 
of /64.  But, NAT66 has to be worse than allowing longer than /64 
prefixes.  The stateless NPTv6 process defined in [RFC6269] won't work 
in this application, a stateful one-to-one address translation would be 
necessary.

6. "Use longer than /64 prefix, for example /68 or /72, by manual 
configuration or DHCPv6, but not SLAAC" - Allows multiple subnets in the 
home and good L3 segmentation, it encourages the deployment of IPv6 and 
discourages NAT66.  Also if used with a DHCPv6 server providing some 
kind of privacy addresses a /68 or /72 preserves a sufficiently large 
subnet to maintain a reasonable level of security and privacy.

I really don't want to advocate IIDs other than /64, they should only be 
used in exceptional situations.  However, just like /126s are understood 
as work-around (least-worse option) for routers not correctly supporting 
[RFC6164], I think /68s are a viable work-around (least-worse option) 
for broken ISPs that are not willing to delegate prefixes shorter than 
/64 to their customers.

If we can't make ISPs understand they need to provide their customers 
prefixes shorter than /64, should their customers be forced to suffer? 
In option #1 above the customer don't suffer, the ISP does in theory, 
this is best outcome, but it is a far from a certain outcome.  Options 
#2, #3, #4, and #5 are bad outcomes for the customer, the Internet as a 
whole, or both.  Option #6 in my opinion at least provides a tolerable 
outcome for the customer and the Internet as a whole.

I understand Lorenzo's argument, if we allow longer than /64 prefixes, 
some ISPs will just move to what ever we allow.  But, the fact that many 
high-end hardware fast-path routers have issues with prefixes between 
/65 and /126 is actually a good thing in this instance.  It mean that 
ISPs, who usually need these hardware fast-path routers to scale their 
networks, are only slitting there own throats if they actually try to 
delegate longer than /64 to customers.  So, given current conditions the 
arms race that Lorenzo talks about seems unlikely.

Furthermore, home broadband CPE routers generally don't have hardware 
fast-path options and should be able to tolerate longer than /64 
prefixes without as many issues.

So, I'm not advocating formal changes to [RFC4291], the standard IID 
size should officially remain 64 bits.  I'm just suggestion tolerance of 
longer than /64 prefixes, allowed by [RFC4861], as a work-around of 
broken ISPs, instead of ND Proxy or NAT66.

Thanks

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Tim Chown <[email-masked]>
Date: Tue, 25 Mar 2014 08:04:23 +0000

On 24 Mar 2014, at 15:56, David Farmer <[email-masked]> wrote:

> However, what if an ISP is unwilling to delegate shorter than a /64 prefix?  Yes, we can say until we are blue in the face that ISPs OUGHT TO (from [RFC6919]) provide longer than a /64 to customers, especially when asked.  But, we can't make them, there are no IETF police.

So who are the residential ISPs offering only a /64?

Tim

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 25 Mar 2014 01:15:34 -0700 (PDT)

----- Original Message -----
> From: David Farmer <[email-masked]>
> To: Tim Chown <[email-masked]>; 6man WG <[email-masked]>
> Cc: 
> Sent: Tuesday, 25 March 2014 2:56 AM
> Subject: Re: Residential ISPs & IPv6 NAT
> 

While not ideal, another option for customers who are stuck in this situation would be to get much larger amounts of IPv6 address space from an IPv6-over-IPv6 pr IPv6-over-IPv4 tunnel service provider. While the free services may dry up as IPv6 traffic increases, I don't see a reason why paid for services couldn't replace them.

It'd be an unfortunate tax to pay to have to get around a stuck in IPv4-think ISP, but at least it would provide the IPv6 address space the customer deserves and should have.

Regards,
Mark.

<snip>