Subject: [homenet] ISP-delegated IPv6 prefixes (3.4.1) in draft-ietf-homenet-arch-07

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 5 Mar 2013 22:03:36 +0000

This section of the homenet architecture draft has the following paragraph:

  The home network needs to be adaptable to ISP prefix allocation
   policies, and thus make no assumptions about the stability of the
   prefix received from an ISP, or the length of the prefix that may be
   offered.  However, if only a /64 is offered by the ISP, the homenet
   may be severely constrained or even unable to function.  As stated
   above, attempting to use internal subnet prefixes longer than /64
   would break SLAAC, and is thus not recommended.  Using ULA prefixes
   internally with NPTv6 at the boundary is not recommended for reasons
   given elsewhere.  Reverting to bridging would destroy subnetting,
   breaks multicast if bridged onto 802.11 wireless networks and has
   serious limitations with regard to heterogeneous link layer
   technologies and LLNs.  For those reasons it is recommended that
   DHCP-PD or OSPFv3 capable routers have the ability to issue a warning
   upon receipt of a /64 if required to assign further prefixes within
   the home network.  Though some consideration needs to be given to how
   that should be presented to a typical home user.

<hat = "consumer"> I agree with the first 3 sentences. However, I disagree with the recommendation for the case where the delegated subnet is insufficient to meet the needs of the home network. This paragraph recommends that a DHCP-PD or OSPFv3 capable router issue a warning and recommends against doing anything else. As a home user who currently gets a /64 (via 6rd) from my ISP, I find this recommendation insufficient. I would prefer if a (internal) router that is not given a /64 provided me with a "warning" that offered options for alternate ways to configure the router. These options might include bridging, NPTv6, or even NAT66, and I would be told what I would be giving up (what would break) if I went with any of these choices. But I want choices from that router. Choices of "move to a different house where you can get service from a different ISP", "give up", or "complain" are not real choices. "Switch ISPs" is also not a choice, because there is no other ISP offering service to my home that can provide the bandwidth my family wants. And whatever someone else's reasons are for not wanting to use one of these configurations, those reasons may not apply to me. For example, I take great pleasure in breaking end-to-end connectivity to certain devices inside my home network. I don't mind if I don't have subnetting. I've seen multicast with Wi-Fi links work great where snooping is implemented on the link. I want the choice to be mine.

Barbara

---

From: Mark Andrews <[email-masked]>
Date: Wed, 06 Mar 2013 09:47:58 +1100

In message <[email-masked]
.sbc.com>, "STARK, BARBARA H" writes:
> <hat = "consumer"> I agree with the first 3 sentences. However, I disagree wi
> th the recommendation for the case where the delegated subnet is insufficient
>  to meet the needs of the home network. This paragraph recommends that a DHCP
> -PD or OSPFv3 capable router issue a warning and recommends against doing any
> thing else. As a home user who currently gets a /64 (via 6rd) from my ISP, I 
> find this recommendation insufficient. I would prefer if a (internal) router 
> that is not given a /64 provided me with a "warning" that offered options for
>  alternate ways to configure the router. These options might include bridging
> , NPTv6, or even NAT66, and I would be told what I would be giving up (what w
> ould break) if I went with any of these choices. But I want choices from that
>  router. Choices of "move to a different house where you can get service from
>  a different ISP", "give up", or "complain" are not real choices. "Switch ISP
> s" is also not a choice, because there is no other ISP offering se
>  rvice to my home that can provide the bandwidth my family wants. And whateve
> r someone else's reasons are for not wanting to use one of these configuratio
> ns, those reasons may not apply to me. For example, I take great pleasure in 
> breaking end-to-end connectivity to certain devices inside my home network. I
>  don't mind if I don't have subnetting. I've seen multicast with Wi-Fi links 
> work great where snooping is implemented on the link. I want the choice to be
>  mine.

If your ISP only supplies a /64 then switch ISP.  Truly this is the
only way to stop such stupidity.  If they only supply a /64 via 6rd
run away from them because they are incompentent.  It is not rocket
science to run multiple 6rd domains.

IPv6 prefixes are not scarse.  They are less than $0.03/annum per /48
to ISPs from RIRs.
 
> Barbara
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 5 Mar 2013 23:53:55 +0000

> If your ISP only supplies a /64 then switch ISP.  Truly this is the only way to
> stop such stupidity.  If they only supply a /64 via 6rd run away from them
> because they are incompentent.  It is not rocket science to run multiple 6rd
> domains.
> 
> IPv6 prefixes are not scarse.  They are less than $0.03/annum per /48 to ISPs
> from RIRs.

Switching ISPs is not an option at this time. This is the only provider who offers something close to 30Mbps at a consumer-friendly price. I'm not going to move, either. In the world of trade-offs and doing what's right for me, the /64 is among the least of my concerns. For IETF homenet to attempt to influence CE router vendors to force me to care, by recommending they not provide me with options that will meet my simplistic-consumer wants, strikes me as not a very nice thing to do. But in my experience, the CE router vendors tend to give consumers like me the options we want, no matter what the IETF recommends. I've just found that if the IETF can be convinced to describe the best way to do non-optimal options, rather than simply recommending against them, then consumers benefit.
Barbara

---

From: Mark Andrews <[email-masked]>
Date: Wed, 06 Mar 2013 11:22:56 +1100

In message <[email-masked]
.sbc.com>, "STARK, BARBARA H" writes:
> Switching ISPs is not an option at this time. This is the only provider 
> who offers something close to 30Mbps at a consumer-friendly price. I'm 
> not going to move, either. In the world of trade-offs and doing what's 
> right for me, the /64 is among the least of my concerns. For IETF homenet 
> to attempt to influence CE router vendors to force me to care, by 
> recommending they not provide me with options that will meet my 
> simplistic-consumer wants, strikes me as not a very nice thing to do. But 
> in my experience, the CE router vendors tend to give consumers like me 
> the options we want, no matter what the IETF recommends. I've just found 
> that if the IETF can be convinced to describe the best way to do 
> non-optimal options, rather than simply recommending against them, then 
> consumers benefit.
> Barbara

Then require that the homenet router be able to be turned to bridge
mode and be done with it.

All the ISP's the I am aware of that current only supply /64's have
stated that they intend to offer larger prefixes.  Most that are
doing it are because of broken CPE equipment not because they think
it is a good thing to do.

There is no real reasons for ISP's to only do /64s except spite the
customer.  The difference in costs from the RIRs for the bigger
address space is chump change even for developing states.  All their
equipment will support > /64 because the big players want to support
that.

Mark

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 6 Mar 2013 11:54:26 +0900

On Wed, Mar 6, 2013 at 7:03 AM, STARK, BARBARA H <[email-masked]> wrote:

> As a home user who currently gets a /64 (via 6rd) from my ISP, I find this
> recommendation insufficient.

Who is the ISP? Do you know why they are only handing out /64? Have you
tried to talk to them?

---

From: Mark Andrews <[email-masked]>
Date: Wed, 06 Mar 2013 14:27:20 +1100

In message <[email-masked]>
> Who is the ISP? Do you know why they are only handing out /64? Have you
 
Lots of ISP's took the easy way out and buried the entire 32 bits
of IPv4 address wasting tonnes of space.

	option 6rd 0 32 2001:DB8:: 2001:DB8::1 2001:DB8::2

When with 10 seconds of thought they could have given everyone a
/60 assuming their IPv4 addresses were in 16 or less /8's which
covers almost all ISPs on the planet.

	option 6rd 8 36 2001:DB8:0000: 2001:DB8:0000:1 2001:DB8:0000:2
	option 6rd 8 36 2001:DB8:1000: 2001:DB8:1000:1 2001:DB8:1000:2
	....
	option 6rd 8 36 2001:DB8:f000: 2001:DB8:f000:1 2001:DB8:f000:2

And if your addresses are on 32 or less /8's you hand out /61's.

	option 6rd 8 37 2001:DB8:0000: 2001:DB8:0000:1 2001:DB8:0000:2
	....
	option 6rd 8 37 2001:DB8:f800: 2001:DB8:f800:1 2001:DB8:f800:2

or they could have look at each of their IPv4 allocations and made
each one its own 6rd domain and handed out /48s.  Remember this is
all stuff the ISP advertises using DHCP.  The end user doesn't have
to enter any of this.

Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Mar 2013 08:56:42 +0000

On 05/03/2013 22:03, STARK, BARBARA H wrote:

> I would prefer if a (internal) router that is not given a /64 provided 
> me with a "warning" that offered options for alternate ways to configure 
> the router. These options might include bridging, NPTv6, or even NAT66,
> and I would be told what I would be giving up (what would break) if I
> went with any of these choices. 

There is no reason to consider NAT66. It could try ULA+NPTv6,
but I would have thought that Mark is right - telling you to set
all devices in bridge mode while looking for a better ISP is
probably the most practical option.

Whether this belongs in the IETF architecture description is
another matter.

    Brian

---

From: Simon Perreault <[email-masked]>
Date: Wed, 06 Mar 2013 10:03:31 +0100

Le 2013-03-05 23:03, STARK, BARBARA H a écrit :
> DHCP-PD or OSPFv3 capable routers have the ability to issue a
> warning upon receipt of a /64 if required to assign further prefixes
> within the home network.  Though some consideration needs to be given
> to how that should be presented to a typical home user.
>
> <hat = "consumer"> I agree with the first 3 sentences. However, I
> disagree with the recommendation for the case where the delegated
> subnet is insufficient to meet the needs of the home network. This
> paragraph recommends that a DHCP-PD or OSPFv3 capable router issue a
> warning and recommends against doing anything else. As a home user
> who currently gets a /64 (via 6rd) from my ISP, I find this
> recommendation insufficient. I would prefer if a (internal) router
> that is not given a /64 provided me with a "warning" that offered
> options for alternate ways to configure the router. These options
> might include bridging, NPTv6, or even NAT66, and I would be told
> what I would be giving up (what would break) if I went with any of
> these choices.

FWIW, I disagree with your proposal, and agree entirely with the current 
text.

Imagine we're in a world where homenet-compliant routers are commonly 
available in the shops. They're being installed by ISPs that control the 
CPE. There's a "homenet ready program" that certifies routers and puts 
stickers on them. This WG has done a good job, and the industry has 
adopted homenet. I believe this is what we're all aiming for, or should be.

Now, in that world, an ISP would be crazy to give a single /64 to its 
subscribers. They would instantly receive tons of support calls saying 
that "the router doesn't work". The ISP would get a bad reputation and 
would lose customers. All the incentives would be aligned to make proper 
prefix delegation not only possible, but the only logical choice. So 
ISPs would just give larger prefixes, like everyone wants them to.

That is the world I want to live in.

Current 6rd deployments that hand out /64s are temporary. And I believe 
they exist only because of lack of clue, given the early state of IPv6 
deployment at those well-intentioned ISPs. We have to build for the future.

Simon

---

From: Ray Hunter <[email-masked]>
Date: Wed, 06 Mar 2013 10:08:18 +0100

STARK, BARBARA H wrote:
> <hat =consumer"> I agree with the first 3 sentences. However, I disagree with the recommendation for the case where the delegated subnet is insufficient to meet the needs of the home network. This paragraph recommends that a DHCP-PD or OSPFv3 capable router issue a warning and recommends against doing anything else. As a home user who currently gets a /64 (via 6rd) from my ISP, I find this recommendation insufficient. I would prefer if a (internal) router that is not given a /64 provided me with a "warning" that offered options for alternate ways to configure the router. These options might include bridging, NPTv6, or even NAT66, and I would be told what I would be giving up (what would break) if I went with any of these choices. But I want choices from that router. Choices of "move to a different house where you can get service from a different ISP", "give up", or "complain" are not real choices. "Switch ISPs" is also not a choice, because there is no other ISP offering service to my home that can provide the bandwidth my family wants. And whatever someone else's reasons are for not wanting to use one of these configurations, those reasons may not apply to me. For example, I take great pleasure in breaking end-to-end connectivity to certain devices inside my home network. I don't mind if I don't have subnetting. I've seen multicast with Wi-Fi links work great where snooping is implemented on the link. I want the choice to be mine.
>
> Barbara
>
All IMVHO

Trying to make homenet work with a single /64 or insufficient /64s to
number every subnet uniquely, is unnecessary and a waste of cycles in
this WG. The homenet WG charter is to cover "multiple routers" using
"existing protocols".

Also, defining predictable fallback behavior in the presence of multiple
devices running autoconfig is doomed to failure.
Besides, people already know how to bridge, how to do NAPT, and how to
do 6204 bis.

I do not think that the current text excludes any of the actions Barbara
wants, provided the user accepts that they are no longer running a homenet.
Maybe we could make that clearer.

So perhaps add after the 1st sentence in the quoted paragraph.

"The homenet architecture is designed to work well when sufficient /64
prefixes are availableto uniquely number subnets using SLAAC."

And at the end of the paragraph:

"A homenet device may then revert to one of various fall back modes,
given various limitations on functionality. These fall back modes may be
acceptable to the user in certain limited circumstances, but it should
be very clear that the device is no longer functioning as defined by the
homenet architecture."

regards,
RayH

---

From: Mark Townsley <[email-masked]>
Date: Wed, 6 Mar 2013 14:36:22 +0100

If she is on the 6rd deployment I think she is, the gateway itself is getting a /60 from 6rd. The limitation is not 6rd or the ISP trying to be stingy per se. The limitation is that the gateway currently isn't sub-delegating to subtended routers, and the LAN ports are bridged and served by the same /64 anyway.

The current policies in ARIN and RIPE are such that there really is no excuse for an ISP to limit to /64 with 6rd, even without resorting to multiple domains. I don't know of any large 6rd deployments that are limiting themselves to /64 within the mapping rule itself today, but I've stopped keeping track now as it has become rather widely understood and available. 

- Mark

On Mar 6, 2013, at 3:54 AM, Lorenzo Colitti wrote:

> As a home user who currently gets a /64 (via 6rd) from my ISP, I find this recommendation insufficient.
> 
> Who is the ISP? Do you know why they are only handing out /64? Have you tried to talk to them?

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 6 Mar 2013 15:45:12 +0000

No. It's not AT&T's 6rd deployment. I can't get a 30Mbps service from AT&T.
It's actually listed as a trial, so it's not known to me how long it will be this way, and I don't think it's appropriate to flame or complain about an MSO's trial IPv6 6rd service, much as I might enjoy that. They say that they are headed to dual stack. But my personal philosophy is not to believe in promises of what will be (especially promises that have no date or timeline provided), and to accept the high likelihood that the current state of affairs will continue to exist for the next several years.
But since the following info is available publicly on the Internet, I'll point you to the following link:
http://www.myaccount.charter.com/customers/Support.aspx?SupportArticleID=2665
Specific 6rd trial info is on this page under the heading "Preparing for IPv6".

This is clearly labeled as a trial, and I would rather have them commended for offering this, than lambasted for the fact that it doesn't meet expectations of individuals in the IETF. I see no need to talk to them about it. I have no complaint with it.
Barbara

- Mark

On Wed, Mar 6, 2013 at 7:03 AM, STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> wrote:
As a home user who currently gets a /64 (via 6rd) from my ISP, I find this recommendation insufficient.

---

From: Chris Donley <[email-masked]>
Date: Wed, 6 Mar 2013 16:25:48 +0000

>equipment will support > /64 because the big players want to support
Actually, that's not quite right.  A number of ISPs are only offering /64s
because a significant number of IPv6-supporting home routers can't handle
shorter prefixes (although it's getting better) - we've seen this in our
lab.  ISPs I've spoken with plan to offer shorter prefixes as home routers
can support them.

---

From: Mark Townsley <[email-masked]>
Date: Wed, 6 Mar 2013 21:42:26 +0100

On Mar 6, 2013, at 4:45 PM, STARK, BARBARA H wrote:

> No. It’s not AT&T’s 6rd deployment. I can’t get a 30Mbps service from AT&T.

Silly me!

Indeed, they are deploying within a /32, leaving only a /64 for your RG. 
6rd Prefix = 2602:100::/32
Border Relay Address = 68.114.165.1
6rd prefix length = 32
IPv4 mask length = 0
Good they will move to dual-stack. If they find more users wanting to use 6rd and more gateways knowing what to do with more than a single /64, they should be able to get space from ARIN such that giving more than a /64 with 6rd is still possible (even with a single domain). We worked very hard on making sure that was possible at the policy level.

Thanks for the pointer, I was unaware of this one. 

- Mark

> It’s actually listed as a trial, so it’s not known to me how long it will be this way, and I don’t think it’s appropriate to flame or complain about an MSO’s trial IPv6 6rd service, much as I might enjoy that. They say that they are headed to dual stack. But my personal philosophy is not to believe in promises of what will be (especially promises that have no date or timeline provided), and to accept the high likelihood that the current state of affairs will continue to exist for the next several years.
> But since the following info is available publicly on the Internet, I’ll point you to the following link:
> Specific 6rd trial info is on this page under the heading “Preparing for IPv6”.
>  
> This is clearly labeled as a trial, and I would rather have them commended for offering this, than lambasted for the fact that it doesn’t meet expectations of individuals in the IETF. I see no need to talk to them about it. I have no complaint with it.
> Barbara
>

---

From: Ole Troan <[email-masked]>
Date: Fri, 8 Mar 2013 09:11:22 +0100

> lab.  ISPs I've spoken with plan to offer shorter prefixes as home routers

right. changing the homenet architecture because of buggy software seems like putting the cart in front of the horse.

I heard about this bug years ago, wasn't aware it still existed in current gear. does it?

Ole

---

From: Ray Hunter <[email-masked]>
Date: Fri, 08 Mar 2013 21:19:43 +0100

> I heard about this bug years ago, wasn't aware it still existed in current gear. does it?
Even if it does, so what?

We're not seriously trying to make homenet backwards compatible with old
routers that presume they are the only L3 device on the network?

I hope that we specify homenet assuming BCP 157. Then ISPs will know
that they should design their provisioning systems so that they always
delegate much more than a single /64 to any homenet customer. They might
even do so, as it'll probably be cheaper than handling the helpdesk
calls resulting from the hacks needed to deal withinadequate prefix
lengths in PD.

regards
RayH

---

From: Michael Richardson <[email-masked]>
Date: Fri, 08 Mar 2013 21:05:20 -0500

>>>>> "STARK," == STARK, BARBARA H <[email-masked]> writes:
    STARK> Switching ISPs is not an option at this time. This is the
    STARK> only provider who offers something close to 30Mbps at a
    STARK> consumer-friendly price. I'm not going to move, either. In
    STARK> the world of trade-offs and doing what's right for me, the
    STARK> /64 is among the least of my concerns. For IETF homenet to
    STARK> attempt to influence CE router vendors to force me to care,

I think you should, until your ISP and your CE router are sorted out,
turn off your IPv6 at your router, and just use Teredo or an explicit
tunnel with sixxs.net for your work-at-home IPv6 needs.

I don't think that homenet should accomodate the particular set of
constraints that you have.  I believe that they will go away.

(me: I prefer end to end connectivity over the multi-dozen-megabit/s
consumer-style, high-latency, bufferbloated incument telco junk. Mind
you, they can't even spell IPv6...)

-- 
Michael Richardson
-on the road-

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Mar 2013 20:15:14 +0000

> you, they can't even spell IPv6...)

The candidate -08 has a reference to BCP 157.

And text basically as per Ran stated.  If you get a /64, then if you're in a single subnet dual-stack network you may well be fine.  But you can't expect to route to further subnets internally under the architecture as defined (though you are of course free to manually configure bridging mode or NPTv6 yourself...).

Tim