Subject: [homenet] draft-ietf-homenet-arch comments

From: Ole Troan <[email-masked]>
Date: Wed, 19 Jun 2013 00:19:48 +0200

I've battled through the whole document again. I'm quite happy to see this document proceed as is.
some nits and comments below. note I'm also a co-author although I haven't held the pen for a while.

cheers,
Ole

-----

this document could benefit from some weight loss throughout. the text is riddled with excess, just in the abstract alone
you can cut: increasingly, general, associated, briefly, suggests, can be employed (are used), 

s/pro-active management/active management

s/CER/CE router/?
how many names do we need for a CPE, Home Gateway, Residential Gateway, CE, CE Router, pick one of the existing ones

section 2.2 on global addressablity - include a paragraph stating that the network is exposed to ISP renumbering the network
to a much larger degree than before. NAT isolated the user against ISP renumbering to some extent.

section 2.4 ULA
paragraph on security by restricting reachability. ULAs can be used by default for devices that without configuration
only should offer services to the internal network. e.g. a printer could only accept incoming connections on a ULA,
until configured to be globally reachable.

section 3.3.2 largest possible subnets.
this seems to say, if something can be bridged together do so. is that what we want to recommend?
I don't know enough about bridging wired to wireless, versus routing wired to wireless, but someone
seemed to indicate that there were problems with bridging interfaces of greatly differing speeds.
anyone who can provide insight?

remove this paragraph from section 3.4.1
   There are reports that some CER equipment does not support receipt of
   a prefix bigger than /64, but the homenet architecture is designed
   for future IPv6 home networks, and we assume that such restricted
   equipment will become rarer over time.

the sentence: "It is expected that ISPs will deliver a relatively stable prefix" is repeated at least twice if not three times

section 3.4.1 with regards to flash renumbering. it might be noted that while the network can support flash renumbering, it will have adverse effects on applications.

section 3.4.3 s/internal prefix delegation/internal prefix assignment/ alternatively prefix configuration

"However, where ULAs are used, most likely but not necessarily in parallel with global prefixes,"
remove "but not necessarily"

section 3.4.3 remove references to possible solution drafts

section 3.4.4 shouldn't it say something more about distribution of other configuration information?

---

From: Tim Chown <[email-masked]>
Date: Wed, 19 Jun 2013 00:12:53 +0100

> some nits and comments below. note I'm also a co-author although I haven't held the pen for a while.

You are always welcome to pick it up again; you have the xml :)  We should agree the full list of changes first though.

> you can cut: increasingly, general, associated, briefly, suggests, can be employed (are used), 

Probably, yes.  Mark and Ray are concerned that any -08 to -09 changes should be no more than needed, so that the tools diff view isn't bigger than it needs to be. Let's see what they say about that.

> how many names do we need for a CPE, Home Gateway, Residential Gateway, CE, CE Router, pick one of the existing ones

So now you want the text longer :)  I really don't mind, again, let's see what the chairs want.

> to a much larger degree than before. NAT isolated the user against ISP renumbering to some extent.

True, but that is also the point of using ULAs.  We can make it more explicit though.

> until configured to be globally reachable.

Yes, I think the text talks about the user being able to toggle this.  Though I don't off-hand recall specifically where.

> anyone who can provide insight?

My interprettaion is that it means "largest possible subnets within the constraints of the media"; one reason we cite for multiple subnets is the variety of media deployed in a homenet; most likely at least Ethernet, WLAN and LLN.

>   equipment will become rarer over time.

OK.

> section 3.4.1 with regards to flash renumbering. it might be noted that while the network can support flash renumbering, it will have adverse effects on applications.

Indeed, though ULAs should protect internal applications, provided ULA prefixes are stable within the homenet.

> remove "but not necessarily"

OK.

> section 3.4.3 remove references to possible solution drafts

Ray/Mark agreed to do this more widely in the text.

> section 3.4.4 shouldn't it say something more about distribution of other configuration information? 

It could do; this was a tpic Jari raised previously.

Tim
> 
> 
> 
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Ray Hunter <[email-masked]>
Date: Wed, 19 Jun 2013 08:37:27 +0200

> until configured to be globally reachable.

This is a good example of why I am concerned about ULA.

ULA may be preferred over GUA [assuming we either take action on 6724 to
inject additional /48's into the policy table or older nodes are present
that still run 3484 or something else.]

Although ULA prefixes are recommended to be filtered at the site
boundary (Section 4.3 RFC4193)
they also may be used for inter-site VPN's (section 4.7 RFC4193).

Making additional/ unnecessary assumptions about reachability and
security is IMHO yet another .local / RFC1918 problem waiting to strike.

If you want security, the device providing the security needs to
understand the topology e.g. where the site border is in relation to the
endpoints of the connection request. Merely relying on addressing
schemes is insufficient IMHO.

---

From: Ole Troan <[email-masked]>
Date: Wed, 19 Jun 2013 09:49:55 +0200

Ray,

> schemes is insufficient IMHO.

I certainly didn't intend to equal the use of ULAs with security.
but there is no doubt that the use of ULAs limit the attack surface compared to global addresses.

cheers,
Ole

---

From: Mark Townsley <[email-masked]>
Date: Wed, 19 Jun 2013 11:35:19 +0200

Let's focus on the substantive technical changes, with minimum diffs given this is already 2nd WGLC. For the abbreviation and jargon consistency, overuse of adverbs at the start of sentences, etc. - these are important of course, but let's log them for inclusion in the doc shepherd writeup for the RFC Editor to look at. They are the professionals for that type of thing.

- Mark

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Jun 2013 10:36:41 -0400

Ray Hunter <[email-masked]> wrote:
    ray> Although ULA prefixes are recommended to be filtered at the site
    ray> boundary (Section 4.3 RFC4193) they also may be used for inter-site
    ray> VPN's (section 4.7 RFC4193).

1) is anyone actually doing this now?

2) the RIRs need to be pushed by the IETF to make some Non-Connected Network (aka
   "ULA-Central") space available at very minimal cost to Enterprises.

3) ULAs across sites would piss me, and anyone else off who had to debug.
   You need reverse DNS and whois in a big enterprise.  The proliferation
   and confusion as a result of RFC1918 in enterprises proves this.

So, maybe we can push back here at 6man, and suggest that section 4.7 of 4193
should be deprecated.

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Michael Thomas <[email-masked]>
Date: Wed, 19 Jun 2013 07:48:20 -0700

>     and confusion as a result of RFC1918 in enterprises proves this.

The corpro-IT types typically think of your laptop as being part of their site,
not your home. So getting a corpro ula would probably seem right to them.
In either case though: just being attached by vpn may make getting corpro
ula's inevitable regardless of desire: autoconfiguring them is what the host
wants to do, so any bit of config oops will land them there.

Tunnels are strange beasts.

Mike

---

From: Ray Hunter <[email-masked]>
Date: Wed, 19 Jun 2013 17:41:57 +0200

> Michael Richardson <mailto:[email-masked]>
> 19 June 2013 16:36

I don't know anyone who's actually doing it already , but I've certainly
seen plenty of evidence of people thinking of doing it.

People are talking Internet centric. So a deployment model of an
automatically configured tunnel network running over public Internet for
private enterprise traffic, plus a number of NPTv6 gateways breaking out
to the public Internet makes perfect sense to them. There are a number
of products that do this already for IPv4 e.g. Meraki, and it wouldn't
be rocket science to extend the concept to IPv6. Using ULA means you
don't even have to pay for PI space for small remote offices, and you
also "fix" your intercontinental multi-homing problems. [not that I
necessarily agree that this is the best deployment model, but it is
certainly valid and does not require deploying anything more than
existing IETF standards documents]

An awful lot of people work from home, or on small sales sites, where
they tunnel back into the corporate network, or even simultaneously to a
3rd party's machines for some collaboration. That VPN can terminate
either on your laptops' VPN driver, or a homenet router.

Relying on address class to determine security context is a non-starter
IMHO.

> "ULA-Central") space available at very minimal cost to Enterprises.
Not sure that's related or how it would help..

> and confusion as a result of RFC1918 in enterprises proves this.

Yes. You'll probably also need split DNS. Hence my comments.
> So, maybe we can push back here at 6man, and suggest that section 4.7
Too late IMHO. I think it might be more constructive to initially treat
the requirements for a corporate VPN link as "just another ISP uplink"

>
> Ray Hunter <mailto:[email-masked]>
> 19 June 2013 08:37
> Ole Troan wrote:
> ------------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Jun 2013 08:41:51 +1200

> Not sure that's related or how it would help..

And it's way out of scope for homenets; typical home users will not
be going off to register a ULA prefix to avoid a minute chance
of collision.

> Yes. You'll probably also need split DNS. 

Which is of course standard practice in thousands of enterprise
networks.

> Hence my comments.

> the requirements for a corporate VPN link as "just another ISP uplink"

In the sense that a "foreign" ULA prefix is just another global prefix,
with tailored routing rules, that's exactly right and fully consistent
with existing practice in large corporates. ULAs are a simplification
compared with de-aggregating GUA prefixes for the same purpose.

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 Jun 2013 11:01:16 +1000

In terms of ULA address and the DNS, IPv6 needs a scoped type in the DNS to
hold IPv6 addresses.  This would help with both ULA and Link-Local scoped
addresses.  It also needs to be able to advertise whether a address is
deprecated or not.

	<IPv6-ADDRESS> <DEPRECATED> <SPACE-IDENTIFIER>

Where <DEPRECATED> indicates the address is deprecated (1) so that
this address sorted to the end of the potential addresses.

Where <SPACE-IDENTIFIER> is a domain name and should be choosen to
be globally unique for the space.  "." is the global namespace.
RA's would advertise which namespaces are valid for the link.  There
would also be DHCP options (4 and 6) which specify which spaces are
valid for the relevent address family.

I have 3 non-temporary address on currently one of my interfaces.

inet6 fe80::6233:4bff:fe01:7585%en1 prefixlen 64 scopeid 0x5 
inet6 fd92:7065:b8e::6233:4bff:fe01:7585 prefixlen 64 autoconf 
inet6 2001:470:1f00:820:6233:4bff:fe01:7585 prefixlen 64 autoconf 

	fe80::6233:4bff:fe01:7585 0 link1.dv.isv.org.
	fd92:7065:b8e::6233:4bff:fe01:7585 0 dv.isv.org.
	2001:470:1f00:820:6233:4bff:fe01:7585 0 .

The RA/DHCP would say that "wireless.dv.isv.org", "dv.isv.org" and
"." are valid for this link and getaddrinfo() would filter addresses
( controllable via a flag) based on that information and fill in
the scopeid field appropriately for the linklocal address.

This interface also has a RFC 1918 address

inet 192.168.191.223 netmask 0xffffff00 broadcast 192.168.191.255

and this would also be in the RRset as a mapped address giving

	fe80::6233:4bff:fe01:7585 0 link1.dv.isv.org.
	fd92:7065:b8e::6233:4bff:fe01:7585 0 dv.isv.org.
	2001:470:1f00:820:6233:4bff:fe01:7585 0 .
	::ffff:192.168.191.223 0 dv.isv.org.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Jun 2013 21:35:54 -0400

> this address sorted to the end of the potential addresses.

Why would you even publish a deprecated address?   If you're renumbering, a connection from a deprecated address to a new address ought to work, so there's no reason to have the deprecated addresses in the DNS at all.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 Jun 2013 13:15:32 +1000

In message <[email-masked]>, Ted Lemon writes:
> Why would you even publish a deprecated address?   If you're renumbering,
> a connection from a deprecated address to a new address ought to work, so
> there's no reason to have the deprecated addresses in the DNS at all.

Well for one thing you need it for address -> PTR -> AAAA checking.
For a second thing you can have routing issues with one prefix and
not the other.  The address is "deprecated" not "gone".  At the moment
you have to remove the AAAA too early or risk a deprecated address
being used in preference to a non deprecated address.

Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Jun 2013 15:19:39 +1200

On 20/06/2013 15:15, Mark Andrews wrote:
...
> Well for one thing you need it for address -> PTR -> AAAA checking.

Maybe we could deprecate that check first.

> For a second thing you can have routing issues with one prefix and

So why wouldn't you publish the deprecated *prefix* rather than
a large bunch of /128s?

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 Jun 2013 13:37:17 +1000

> Maybe we could deprecate that check first.

What's wrong with a sanity check?
 
> So why wouldn't you publish the deprecated *prefix* rather than

Who was talking about /128's vs short prefixes?

---

From: Tim Chown <[email-masked]>
Date: Thu, 20 Jun 2013 14:12:18 +0100

> Who was talking about /128's vs short prefixes?

While discussion is fine, it would be very useful if the focus was on specific suggested changes to text for the -08 arch text.

Tim

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 21 Jun 2013 00:54:26 +0200

I don't see any mention of the need to handle topologies with links of
widely varying speed (except for the incidental mention in 3.2.3).

A typical home network grows organically, and combines different
generations of technlogies.  In a typical home today, you'll find
Gigabit Ethernet as well as the 1Mbit/s wifi link to the shack in the
garden.  That's four orders of magnitude difference, and I expect this
difference to get worse with time.

This has some important consequences, notably the fact that it's
possibly hazardous to implement multicast by flooding.

-- Juliusz

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Jun 2013 15:53:48 +1200

> What's wrong with a sanity check?

I've never believed that that's a check worth doing, since its success
might be due to an accomplished fraudster (unless, I guess, DNSSEC is
universal) and its failure might be due to somebody who sees no
particular reason to create PTR records.

> Who was talking about /128's vs short prefixes?

I thought you were suggesting an additional RR for every
/128 in a deprecated state. It seems to me that a single RR
for each prefix in a deprecated state would be more
economical. (In fact I can see a positive value for it during
a renumbering event, but that is a further digression.)

   Brian

---

From: Ole Troan <[email-masked]>
Date: Fri, 21 Jun 2013 10:10:03 +0200

Juliusz,

> possibly hazardous to implement multicast by flooding.

do you have any references that could be included or would you mind proposing some text?
if it turns out to be multicast specific it could go in 3.5.1.
if there are more general issues to consider then perhaps a new sub-section?

cheers,
Ole

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 21 Jun 2013 14:28:11 +0200

> if there are more general issues to consider then perhaps a new sub-section?

No, I think it's more general.  What about something like the following:

  Homenets tend to grow organically over many years, and a homenet
  will typically be built over link-layer technologies from different
  generations.  Current homenets typically use links ranging from
  1Mbit/s up to 1Gbit/s, which is a three orders of magnitude speed
  discrepancy.  We expect this discrepancy to get worse as both
  high-speed and low-power technogies are deployed.

  Homenet protocols should be designed to deal well with
  interconnecting links of very different speeds.  In particular,
  flows local to a link should not be flooded throughout the homenet,
  even when sent over multicast, and, whenever possible, the homenet
  protocols should be able to choose the faster links and avoid the
  slower ones.

If you wish, I can add a sentence saying "This implies that a link-state
protocol must be used in the homenet" ;-)

-- Juliusz

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Jun 2013 14:22:00 +1200

On 19/06/2013 18:37, Ray Hunter wrote:

...
> schemes is insufficient IMHO.

Absolutely. You are certainly correct that "ULA safe, GUA dangerous"
is not always true. But is this different from a case where a GUA
prefix is leaked to a friend via a VPN; if you're doing that with a
ULA prefix it's exactly the same. You need per-prefix rules.

Unfortunately, with the complexity of homenets that people seem to
envisage for the future, I think we're going to see these enterprise
type issues in complex homenets.

    Brian

---

From: Jim Gettys <[email-masked]>
Date: Mon, 24 Jun 2013 10:37:38 -0400

> protocol must be used in the homenet" ;-)

I'll stay out of the routing discussion....

But I'd like to point out that the problems we're already facing are not
just multicast, as Dave Taht has educated me recently  The scarcest
resource can often now be "transmit-opportunities", or txopts; certainly
this is true for WiFi (you get around 1000/second, and that's it...).

So anything that causes packets to require their own txopt for
transmission makes them very expensive.  So, for example, whether it is
even wise to use the hardware priority queues WiFi nominally has (even if
they work correctly) at all is questionable; under a loaded network,
bundling your voip traffic into the first available transmit opportunity
along with other traffic you have queued is clearly better than having to
burn an extra txopt to use the "feature" of the hardware queue, if no
further delay will be incurred by doing so.

Multicast is evil not only due to its inefficient use of the available
bandwidth, but because it forces use of a separate txopt for transmission.

The real point is we have several technological drivers toward wanting to
avoid the network being "chatty", and liking protocols that allow for
aggregation of packets when transmissions do occur.

I'm not sure I can easily express this in RFCese, however.
                                              - Jim

---

From: Ted Lemon <[email-masked]>
Date: Mon, 24 Jun 2013 11:04:09 -0400

> I'm not sure I can easily express this in RFCese, however.  

You seem to have expressed it quite well in email-ese.   Why not try?

---

From: Jim Gettys <[email-masked]>
Date: Mon, 24 Jun 2013 11:36:11 -0400

>   protocols should be able to choose the faster links and avoid the

Here's a version derived from Juliusz's try.  I also substitute
"bandwidth" for "speed", as
being sloppy about the language has tended to get us into the bufferbloat
mess.
                                                   - Jim

Homenets tend to grow organically over many years, and a homenet
will typically be built over link-layer technologies from different
generations.  Current homenets typically use links ranging from
1Mbit/s up to 1Gbit/s, which is a three orders of magnitude bandwidth
discrepancy.  We expect this discrepancy to widen further as both
high-speed and low-power technologies are deployed.

Homenet protocols should be designed to deal well with interconnecting
links of very different bandwidths.  In particular, flows local to a link
should
not be flooded throughout the homenet, even when sent over multicast,
and, whenever possible, the homenet protocols should be able to choose the
faster links and avoid the slower ones.

Links (particularly wireless links) may also have limited numbers of
transmit opportunities
(txops), and there is a clear trend driven by both power and downward
compatibility constraints
toward aggregation of packets into these limited txops while increasing
bandwidth.
Transmit opportunities may be your scarcest resource and therefore also
strongly limit
actual bandwidth available.

Therefore protocols that avoid being "chatty", do not require flooding, and
enable isolation
of traffic between subnets are preferable to those which burn scarce
resources.

---

From: Ole Troan <[email-masked]>
Date: Mon, 24 Jun 2013 11:48:20 -0400

thanks Jim and Juliusz, I like that text.

cheers,
Ole

On Jun 24, 2013, at 11:36 , Jim Gettys <[email-masked]> wrote:

> 
> On Fri, Jun 21, 2013 at 8:28 AM, Juliusz Chroboczek <[email-masked]> wrote:
> Here's a version derived from Juliusz's try.  I also substitute "bandwidth" for "speed", as
> being sloppy about the language has tended to get us into the bufferbloat mess.
>                                                    - Jim
> 
> 
> links of very different bandwidths.  In particular, flows local to a link should 
> Links (particularly wireless links) may also have limited numbers of transmit opportunities 
> (txops), and there is a clear trend driven by both power and downward compatibility constraints 
> toward aggregation of packets into these limited txops while increasing bandwidth.
> Transmit opportunities may be your scarcest resource and therefore also strongly limit
> Therefore protocols that avoid being "chatty", do not require flooding, and enable isolation
> of traffic between subnets are preferable to those which burn scarce resources.
> 
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 24 Jun 2013 20:11:29 +0200

Please use "throughput" rather than "bandwidth".  The latter has
a precise technical meaning.

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Mon, 24 Jun 2013 21:58:35 +0200

> a precise technical meaning.

I agree... as soon as you meet someone specialized in radio
technology, Bandwidth will be something measured in Hertz.

Henning Rogge

--
We began as wanderers, and we are wanderers still. We have lingered
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

---

From: Jim Gettys <[email-masked]>
Date: Mon, 24 Jun 2013 16:03:55 -0400

> technology, Bandwidth will be something measured in Hertz.

I'm happy with that correction and will try to do likewise when I write
other items.

We have to get away from conflating "speed", with throughput or bandwidth,
however: that is where we've gone wrong in the past.

Speed is how "fast" something is for a user; for most applications, latency
rather than throughput dominates performance in today's Internet.  Unless
all you care about is downloading your next episode of "Game of Thrones"
;-)....
                                        - Jim

---

From: Tim Chown <[email-masked]>
Date: Tue, 25 Jun 2013 11:46:56 +0100

> a precise technical meaning.

The text seems fine to me, thanks.

Note that the variance in media is noted in the text already as one reason for routing within the homenet, but this makes the broader problem more explicit.

Related is the edit to clarify that multicast may flow to/from the home, not just within it.

And another reason for link-state is indeed welcome ;)

Tim