Subject: Re: [homenet] homenet-arch review

From: Mark Townsley <[email-masked]>
Date: Wed, 6 Mar 2013 05:34:10 +0100

Replying, changing the very misleading subject. 

Thanks for the comments, please see inline.

On Mar 1, 2013, at 2:45 AM, Brzozowski, John wrote:

> Tim,
> 
> 
> Per your request below here are some comments pertaining to the section
> you mention below.
> 
> * The section seems to hint at two extremes stable on one end and very
> dynamic i.e. at each CER reboot.  I think it is important to note that
> there is middle ground here and that providers typically have good reason
> for requiring prefix changes, largely related to network capacity
> management.  It is not clear to me if this need to be called out in the
> text, however, I thought you should know.
> * Agreed regarding /64 subnet lengths
> * This section does not differentiate between a residential service and a
> commercial or SOHO service.  Is this outlined elsewhere in the draft?
> Does it need to be?

That's more of a charter question. While we should aim to create technology that is generally useful outside the home, the defined scope is the home. Among other things, this should help underscore the auto-configuration requirement as the further you dip into SOHO territory, the more likelihood that there is an administrator of some sort (whether it be a remote worker's IT department or otherwise) becomes more and more prevalent. 

While the "SO" absolutely must be able to work with our "HO" (what looks to us like a special type of additional ISP, if you will), we stop short of, say, trying to define the VPN router's security policy or whether it should use IPsec Tunnel mode or GRE with Transport Mode or SSL or... 

(Personally, I would like to see homenet's technology have impact outside the home - we're tackling some important problems IPv6 has had for a while.) 

> * Note - some devices today can only utilize a /64 and nothing more these
> would not break.

Good point, and this brings up a general issue of working with existing non-homenet routers that support IPv6. The document should probably highlight this. 

> * No NPTv6 please

Section 2.4

"As such, neither IPv6 NAT or NPTv6 is recommended for use in the homenet architecture."

> * ULAs support could be introduced at a later date

Why wait?

> * Agreed regarding bridging avoidance
> * How is "relatively stable prefix" defined?

Relative to changing the prefix whenever the CER is reset:

"Some ISPs may offer relatively stable prefixes, while others may change the prefix whenever the CER is reset."

Feel free to offer up a better description. I think the salient point ends up being that the home network is going to have to be resilient to prefix change. 

> * Good text regarding PIA
> * Regarding renumbering also note that operators take precautions to
> ensure this is seamless as well including lease time lowering in advance
> of the renumbering event.  We have been doing this for years.

Consistent with RFC 4912 or not? (because that is what we are pointing to right now)

> * Forced renumbering for privacy sounds unfortunate but based on various
> emails I have seen lately this seems to be something that must be
> supported.

Yes, sadly. 

> * Agreed that service discovery is essential
> 
> I hope these comments are useful, I recognize I was not overly verbose.  I
> hope this is a feature not a bug.  Please let know if you wish to discuss
> further.

Thank you for the review and input, John.

- Mark

> 
> John
> -----Original Message-----
> From: Tim Chown <[email-masked]>
> Date: Wednesday, February 27, 2013 5:56 AM
> To: "[email-masked]" <[email-masked]>
> Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt
> 
>> 
>> On 26 Feb 2013, at 14:07, "Brzozowski, John"
>> <[email-masked]> wrote:
>> 
>> 
>> [jjmb] incorrect I have both, just stating that I have both.  Apologies if
>> I was not clear.  I also have a good # of home routers actively using IPv6
>> enabled broadband today, ~3%.
>> 
>> 
>> 
>> 
>> Congratulations, btw. That must be a large number when converted to real
>> customers :)
>> 
>> 
>> The homenet architecture assumes a CPE rather than a single host. It
>> discusses ISP allocations in section 3.4.1 of
>> http://tools.ietf.org/html/draft-ietf-homenet-arch-07.  As that text
>> is in WGLC, any comments on that section would be welcome (preferably on
>> the homenet list).
>> 
>> 
>> Tim
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Mar 2013 13:22:51 +0000

Thanks again for the comments Jon.  All noted and I agree with Mark's response.

Tim