Subject: Re: [homenet] draft-ietf-homenet-arch-04

From: RJ Atkinson <[email-masked]>
Date: Mon, 1 Oct 2012 08:59:18 -0400

On 30  Sep 2012, at 19:33 , Curtis Villamizar wrote:
Claim (A):
> Breaking SLAAC is bad.

Breaking SLAAC breaks interoperability, and will keep
various networked devices disconnected, which is a
*fundamental* problem.

Fundamentally, DHCPv6 is not widely enough supported 
(today / soon) for it to be a sufficient answer 
to getting network-capable devices onto the network.  

There might be a time in future where the situation 
with DHCPv6 support changes, but we aren't there today, 
and we won't be there soon.

Claim (B):
> Consumer oriented providers handing out /64s
> to home nets is also bad.

Agreed (s/consumer-oriented/any/). 

HomeNet WG ought to be VERY clear about this.

HomeNet WG ALSO ought NOT "enable" or "encourage" 
such behaviour by encouraging ANY scenarios 
where SLAAC can't work properly.

Claim (C):
> But if a homenet does get nothing more than a /64,
> and multiple subnets are needed, then SLAAC gets broken.

I don't think that last bit above is broadly agreed,
at least as of now.

It does not obviously follow that "keeping devices 
disconnected" is better than "not being able to subnet 
as much as desired".

Separately, it is not obvious that those are the *only* 
two possible approaches to the issue you seem concerned 
with (i.e. /64 from a provider && desire subnets).

SUMMARY:

From my perspective, there is a logic fault in the
combination of the quoted statements.  The quoted 
text is equivalent to logic of this form:

	If (A && B) THEN C.

However, from where I sit, the combination of (A && B) 
does not necessarily imply C.  It could mean that one
decides to waive the requirement (B) to keep every device
connected, or that one devices a new alternative (D), 
or something else entirely.

If there are some additional data that would make the
above true, then it would help to get those onto the
table, and figure out how they would factor into the logic.

Cheers,

Ran

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 01 Oct 2012 15:01:14 -0400

> table, and figure out how they would factor into the logic.

Ran,

You are suggesting if A then !B.  I prefer if A and B, then C.

Your proposed if A then !B implies:

  1.  A guest subnet cannot be supported.

  2.  A separate legacy device subnet with IPv4 NAT can't be
      supported.

  3.  A subnet for delay sensitive local audio and/or video devices
      can't be supported.

  4.  Delay and jitter sensitive devices such as SIP phone can't be
      put on a separate subnet.

  5.  All WiFi and LOWPAN and GbE segments must be bridged together
      ragardless of preformance penalties.

  6.  Performance pigs can't be isolated.

I think these were all objectives we would like to support.  If
supporting this means splitting up a /64 if A, then I'm for it.

If some device can't live without SLAAC, then the consumer has two
choices.  Either 1) bridge everything together, or 2) complain until
you get a firmware upgrade or get rid of that device.

I'd pick 2 above, but I'm not the average consumer and neither is
anyone on this list.  I suspect many of us (but not most) already have
subnets in our homes, and do so for good reasons.

Curtis

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 1 Oct 2012 15:18:29 -0400

On 01  Oct 2012, at 15:01 , Curtis Villamizar wrote:
> You are suggesting if A then !B.  

No, my apologies for being unclear. 
I am NOT, repeat NOT, suggesting that.

(A & !B) is a possible deployment option, of course,
but it is not the ONLY option either.

> I prefer if A and B, then C.

I understand you have a personal preference.

A set of people on this list have indicated that
particular preference is strongly undesirable.

However, disallowing SLAAC is NOT the ONLY conceivable 
approach.  One ought to try to think of other options
(each of which probably has different tradeoffs).

Yours,

Ran

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 01 Oct 2012 17:33:07 -0400

> particular preference is strongly undesirable.

I agree that it is *very* undesirable.  It does work.  I've tried it.

> (each of which probably has different tradeoffs).

AFAIK SLAAC requires a /64 prefix.  Is that not true?  Or are you
suggesting changing it?

> Ran

If A and B, then C is a possibility.

Only if C does SLAAC have to get disabled.  It's not a good option and
not every toy is going to play nice but if it is forced, for some it
may be the best option.  Another option is to use a tunnel rather than
the ISP native IPv6 if the ISP won't allocate prefixes other than /64.

I've had a lengthy off-list discussion with Joel.  There is mixed
response from one MSO, with /128 in a lame limited city trial today,
/64 RSN (for some unspecified value of RSN), and shorter prefix still
later.  Its this sort of preference for a one size fits all least
common denominator at a provider that has me concerned that some
consumers may be stuck with a /64.

It would be helpful if we had a consumer-ISP requirements from some
WG, but homenet might not be the place.  

It may be the homenet can say that in order for things to work in the
home certain things are required of the ISP or highly desireable
(DHCPv6 prefix allocation, DNS and rDNS delegation and secondary, at
least /60 on request and preferably without additional charge, etc).
Would that be out-of-scope for homenet, and if so, in what WG would it
be in-scope?  If none, then can it become in-scope (charter update)?

Curtis

btw- if DHCP is not used, then dynamic DNS has to get popluated
directly from the host and each host needs the key needed to make its
DDNS update (and not someone else's DDNS update) and it also needs to
know where the DDNS server is.  This seems a lot more problematic than
putting DHCPv6 client on the host.  Lack of either means DDNS doesn't
get updated.  Also if DHCPv6 is not used, the domain name, DNS search
list, nameserver list, ntpservers, .. etc, still have to be populated.

---

From: Dave Taht <[email-masked]>
Date: Mon, 1 Oct 2012 14:41:27 -0700

I have been tracking this conversation for a while, excuse the top post.

0) The state of cable modems is rather dismal as yet, with none that
I'm aware of able to distribute anything bigger than /64. 6to4 is
still the best option on that technology in the US.
1) At least some markets outside the USA (NZ, for sure) are managing
to distribute /56 addresses via DSL/fiber
2) SLAAC is needed, too many dumb devices only implement that.

I note that dnsmasq now contains a clever hack to utilize dhcpv4
information to correctly assign names to SLAAC based addresses.

3) I gave up on the whole /64 and slaac vs dhcpv6 debate years ago and
went to ahcp, not that I'm ever going to get any traction on it,
regardless of how well it solves 0, above.

On Mon, Oct 1, 2012 at 2:33 PM, Curtis Villamizar <[email-masked]> wrote:
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Andrew McGregor <[email-masked]>
Date: Tue, 2 Oct 2012 11:50:07 +1300

In fact, my connection in NZ gives me a /48 via DHCPv6 PD, although some providers I gather are doing /56.

Andrew

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 2 Oct 2012 06:45:49 -0400

> I agree that it is *very* undesirable.  It does work.  I've tried it.

It does not *generally* work.  

If it works for you, that says more about what kind of 
equipment you are connecting -- and the capabilities 
of that equipment (e.g. DHCPv6) than anything else.

Particularly, DHCPv6 does not work with some widely 
deployed consumer electronics gear -- gear that 
only supports SLAAC.

> AFAIK SLAAC requires a /64 prefix.  

Yes.

> Or are you suggesting changing it?

No.

> If A and B, then C is a possibility.

One of several different possibilities.
That one is particularly ugly because it means
that some devices won't be able to connect 
to the network *at all*.

Most consumers expect ALL of their devices to be
able to connect with and use their home network.
Anything less generally is viewed as not satisfactory.

> Another option is to use a tunnel rather than

Yes.
Other options also exist.

> It may be the homenet can say that in order for things to work
> in the home certain things are required of the ISP or highly
> desirable (DHCPv6 prefix allocation, DNS and rDNS delegation
> and secondary, at least /60 on request and preferably without
> additional charge, etc).

That sounds sensible to me -- and HIGHLY preferable
to having HomeNet encourage ISPs to delegate /64s 
(or even longer prefixes) by standardising kludges
that work only for special cases -- or only for 
equipment with features not universally available 
now/soon.

> btw- if DHCP is not used, then dynamic DNS
> has to get populated directly from the host

This likely is true EVEN IF one has DHCPv6 in use.

Running DHCPv6 does NOT automatically mean that the
DNS gets populated correctly.  Some DHCPv6 servers
might have this capability, but other DHCPv6 servers
definitely do not do this.

(new topic)

You seem to have a very particular brand/make/model of
equipment in mind when you write about deployments.

IMHO, HomeNet needs to work *in the general case*, 
without limiting its workability to Brand X, Model Y 
equipment running software version Z.

Yours,

Ran

---

From: Tim Chown <[email-masked]>
Date: Thu, 11 Oct 2012 12:09:25 +0100

> where SLAAC can't work properly.

There is clear consensus in this thread that homenet must support SLAAC and DHCPv6, and thus the architecture text should reinforce the comments that Ran has made.

The residential deployments I am aware of in Europe all support at least /60 and up to /48.  The most common is probably /56.  We should not add complexity to homenet scenarios and break SLAAC to account for ISPs that might currently only offer a /64.  

There have been recent discussions elsewhere I believe on limitations of prefix delegation in certain types of mobile networks where only a /64 is offered currently, but those one would hope are temporary until DHCPv6-PD is supported there.

Curtis can of course take proposals to 6man for discussion, but the architecture text here would not include those.

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Oct 2012 13:22:09 +0100

> The residential deployments I am aware of in Europe all support at least /60 and up to /48.  The most common is probably /56.  We should not add complexity to homenet scenarios and break SLAAC to a…

+1. We are supposed to be specifying the future, not the past.

   Brian