Subject: [homenet] Scope of Work: broken kit & deployments out-of-scope

From: RJ Atkinson <[email-masked]>
Date: Sat, 9 Mar 2013 11:46:40 -0500

Consistent with previous comments by many others, and in my 
personal opinion, the following items ought to be out-of-scope 
for the HomeNet documents (and WG activities):

* CPE devices that don't comply with IETF IPv6 specifications
  (e.g. a CPE device that only can cope with a /64 prefix
   is broken and hence out of scope for HomeNet WG.)

* IPv6 deployments that are inconsistent with existing IETF
  and RIR guidance on IPv6 prefix management and guidance
  on IPv6 prefix allocations.
  (e.g. an IPv6 deployment that refuses to let an end user
   have a prefix shorter than /64 is broken and out-of-scope)

Consistent with that IETF and RIR guidance, the HomeNet WG 
ought to document that users ought to be granted a prefix 
shorter than /64 and also that HomeNet equipment is required 
to comply with IETF IPv6 standards-track specifications.

While these might seem obvious to folks who read RFCs regularly,
they ought to be documented for the benefit of someone
with good intentions who doesn't read RFCs regularly or often
and might not understand the "obvious" prerequisites for
the HomeNet document(s).

The IETF can't prevent others from doing silly things, 
whether in products or deployments, but we can and should 
avoid spending WG time trying to build kludges around broken
products and broken deployments.

Yours,

Ran Atkinson

---

From: Ted Lemon <[email-masked]>
Date: Sat, 9 Mar 2013 11:57:32 -0500

I am a bit skeptical that we don't have to deal with the case where an end-user buys a broken gateway and then plugs a homenet gateway into it.   The way we deal with it might be to recommend that the homegate, when it gets no delegation, set up a captive portal to notify the user of the problem, but to simply punt on it seems like a bad option.

BTW, an example of a router that might be a decent homenet router is the Almond router: http://www.kickstarter.com/projects/2037429657/almond-80211ac-touchscreen-wifi-router-smart-home?ref=email

It has an LCD display, so informing the user that they have set up a broken network is pretty easy.   But we probably ought to have a document that walks homenet gateway implementors through the various issues and options, even if we don't propose a solution that makes it work.

---

From: Andrew McGregor <[email-masked]>
Date: Sat, 9 Mar 2013 11:11:27 -0800

Also, we need to distinguish between a deployment that will hand out
exactly one /64 (broken) and one that will hand out multiple /64s on
request, just not necessarily contiguous (strange, but not so broken).

On Sat, Mar 9, 2013 at 8:57 AM, Ted Lemon <[email-masked]> wrote:

> I am a bit skeptical that we don't have to deal with the case where an
> end-user buys a broken gateway and then plugs a homenet gateway into it.
> The way we deal with it might be to recommend that the homegate, when it
> gets no delegation, set up a captive portal to notify the user of the
> problem, but to simply punt on it seems like a bad option.
>
> BTW, an example of a router that might be a decent homenet router is the
> Almond router:
> http://www.kickstarter.com/projects/2037429657/almond-80211ac-touchscreen-wifi-router-smart-home?ref=email
>
> It has an LCD display, so informing the user that they have set up a
> broken network is pretty easy.   But we probably ought to have a document
> that walks homenet gateway implementors through the various issues and
> options, even if we don't propose a solution that makes it work.
>
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 10 Mar 2013 23:50:12 -0400

On Mar 10, 2013, at 8:42 PM, H. Peter Anvin <[email-masked]> wrote:
> Not even all that strange, after all it lets the ISP manage the network
> in a pretty straightforward way.  The hard part about this is that there
> doesn't seem to be a good way in DHCPv6 to ask for "I need X networks of
> width Y" and have the upstream choose between a single narrower net or
> multiple networks.

Actually there is.   Just send another IA_PD with a different IAID.   If the server is willing to give you another prefix, it will.  This isn't documented anywhere, but it's really the only way to do it—the server isn't allowed to generate new IAIDs.

---

From: "H. Peter Anvin" <[email-masked]>
Date: Sun, 10 Mar 2013 17:42:22 -0700

Not even all that strange, after all it lets the ISP manage the network
in a pretty straightforward way.  The hard part about this is that there
doesn't seem to be a good way in DHCPv6 to ask for "I need X networks of
width Y" and have the upstream choose between a single narrower net or
multiple networks.  Multiple prefixes returned in the DHCPv6-PD request
is supposed to mean that those prefixes should be used in parallel, not
that they should be portioned out.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

---

From: "H. Peter Anvin" <[email-masked]>
Date: Sun, 10 Mar 2013 22:31:47 -0700

That doesn't give the option to the server, though... the client has to ask for one or the other.

Ted Lemon <[email-masked]> wrote:

>Actually there is.   Just send another IA_PD with a different IAID.  
>If the server is willing to give you another prefix, it will.  This
>isn't documented anywhere, but it's really the only way to do it—the
>server isn't allowed to generate new IAIDs.

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 Mar 2013 08:45:32 -0400

> That doesn't give the option to the server, though... the client has to ask for one or the other.

What I would suggest is that if the client doesn't get a big enough allocation, it request an additional allocation, rather than that it try to anticipate what the server will return and prepare for the worst.

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Mar 2013 19:59:37 +0000

> What I would suggest is that if the client doesn't get a big enough allocation, it request an additional allocation, rather than that it try to anticipate what the server will return and prepare fo…

I agree with Ran's original comments.  These are reinforced in the candidate -08 text.

Are there IPv6 ISPs out there who would allocate an additional (say) /60 if the CER requested an additional prefix?  Would it not be simpler to state that the prefix in use in the homenet from any ISP should be contiguous, and sufficient in size for the homenet's requirement, as per 6177 (which recommends "significantly more than a single /64"?)

Tim

---

From: Andrew McGregor <[email-masked]>
Date: Wed, 13 Mar 2013 16:11:35 -0400

I've met one that will allocate more /48s if you ask, and have met a DHCPv6
server implementation that would give you a new prefix if you generated a
new client ID.  So, yes, they easily can exist and in at least one case do.

On Wed, Mar 13, 2013 at 3:59 PM, Tim Chown <[email-masked]> wrote:

> > What I would suggest is that if the client doesn't get a big enough
> allocation, it request an additional allocation, rather than that it try to
> anticipate what the server will return and prepare for the worst.
>
> Are there IPv6 ISPs out there who would allocate an additional (say) /60
> if the CER requested an additional prefix?  Would it not be simpler to
> state that the prefix in use in the homenet from any ISP should be
> contiguous, and sufficient in size for the homenet's requirement, as per
> 6177 (which recommends "significantly more than a single /64"?)
>
> Tim

---

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

On 13 Mar 2013, at 20:11, Andrew McGregor <[email-masked]> wrote:

> I've met one that will allocate more /48s if you ask, and have met a DHCPv6 server implementation that would give you a new prefix if you generated a new client ID.  So, yes, they easily can exist and in at least one case do.

OK, thanks, but presumably the ISP wouldn't hand out such additional prefixes indefinitely?  

The question is whether the arch text should say "if you don't get a big enough prefix, before entering some error state, try asking for more..."?

Tim

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Mar 2013 16:57:04 -0400

On Mar 13, 2013, at 3:59 PM, Tim Chown <[email-masked]> wrote:
> Are there IPv6 ISPs out there who would allocate an additional (say) /60 if the CER requested an additional prefix?

I know of at least one.

> Would it not be simpler to state that the prefix in use in the homenet from any ISP should be contiguous, and sufficient in size for the homenet's requirement, as per 6177 (which recommends "significantly more than a single /64"?)

Yes, it would be simpler.   :)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Mar 2013 16:57:47 -0400

> The question is whether the arch text should say "if you don't get a big enough prefix, before entering some error state, try asking for more..."?

I think it should, although we haven't said how to ask for more, so we'd want to address that in future work once the architecture document is done.