As requested I have read draft-ietf-homenet-arch-07. Thanks everyone for
the effort so far.
IMHO I think the document is in very good shape, but that we're not
quite there yet
(which I guess means I'm obliged to supply comments on why I think
that's the case).
The main thrust of my comments below is an underlying feeling that we
haven't yet fully got a handle on the boundary at the ISP/customer
interface & the homenet/Internet interface, and that this will bite us
later.
I also think there's quite a bit of room to tighten up on nomenclature.
e.g. home network v. homenet. ISP uplink v. Customer Internet
connections. Border v. CER v. Border CER.
Perhaps rather surprisingly, "homenet" is not defined anywhere.
regards,
RayH
Detailed comments
===============
Section 1
s/While at the time of writing some complex home network topologies
exist, but most are/
While at the time of writing some complex home network topologies exist,
most are /
s/like to avoid such/like to avoid, such/
s/IPv6 with an eye/IPv6, with an eye/
s/can not be affected by new /cannot be modified by new /
/[RFC6204] defines basic requirements for customer edge routers
(CERs). The scope of this text is the internal homenet, and thus
specific features on the CER are out of scope for this text./
I find this particular formulation confusing.
Perhaps
/[RFC6204] defined basic requirements for customer edge routers (CERs),
which has recently been updated with the definition of requirements for
specific transition tools on the CER in RFC 6204-bis
[I-D.ietf-v6ops-6204bis] i.e. DS-Lite [RFC6333] and 6rd [RFC5969]. Such
detailed specification of CER devices is considered out of scope of this
architecture document, and we assume that any required update of the CER
device specification as a result of adopting this architecture will be
handled as separate and specific updates to these existing documents./
Section 1.1.
/CER: Customer Edge Router. A border router at the edge of the homenet./
I regularly read "Homenet BR" or "Border Router" on this list used
interchangeably with CER.
Are they different? Equivalent? Or do we need to change our
behaviour/definitions?
This is my biggest worry. Do we have a good handle on the interface at
the border?
Does the set of "End-User network(s)" in Section 3 map 1:1 with a homenet?
I don't think so: it includes the CER.
What is a "Service Provider Network"? The rest of the Internet that
isn't in the homenet?
Wouldn't harm to copy some more definitions from 6204.
Section 2.1
s/This is discussed later in the document./This is discussed in Section
3.7./
/border router(s)/
See comment on 1.1 Border Router v Customer Edge Router?
/There will also be the need to discover which routers in the homenet
are the border router(s) by an appropriate mechanism. Here, there
are a number of choices. These include an appropriate service
discovery protocol, or the use of a well-known name, resolved by some
local name service. Both might have to deal with handling more than
one router responding in multihomed environments./
Above paragraph does not make sense to me.
Seems to be a context shift in the middle of the paragraph.
How is a name service related to discovery of a border router?
We're not suggesting all CER's have to be called a particular hostname?
/2.2. Global addressability and elimination of NAT/
Strictly speaking, NAT won't be eliminated entirely. IPv4 will still use
NAT. IPv6 never had NAT.
How about just /2.2. Global addressability/
s/The end-to-end communication that is potentially enabled with IPv6/
The possibility for direct end-to-end communication on the Internet that
will be restored by the introduction of IPv6/
The Internet architecture always was, and still is, direct end-to-end
communication. We just temporarily lost the ability to do it due to lack
of addresses.
s/on the firewall/
on any firewall/
Section 2.3
s/Default Address Selection for IPv6[I-D.ietf-6man-rfc3484bis]/
Default Address Selection for Internet Protocol Version 6 (IPv6) [RFC6724]/
s/We discuss such challenges in multihoming later in this document./
We discuss such challenges of multihoming in Section 3.3.1./
Section 2.4
s/Despite this counter-argument, while setting a network up there may be
a period with no connectivity/
</p>Despite this counter-argument, there may be a period with no
connectivity while setting up a network/
s/when the ULA destination lies within a /48 ULA prefix known to be used
within the same homenet./
when the ULA source and destination addresses lie within a single /48
ULA prefix known to be used within the same homenet.
However, it should be noted that even if it were known that multiple /48
ULA prefixes are in use within a single homenet
(perhaps because multiple homenet routers each independently
auto-generate a /48 ULA prefix and then share routing information),
utilising a ULA source address and a ULA destination address from two
disjoint /48 ULA prefixes is not preferred over using GUA by the default
address selection rules [RFC6724]. In this case, special action may have
to be taken at the individual host level if this was desired behaviour
e.g. by modifying the address selection policy table./
Section 2.5 Security and Borders
s/The filtering policy to/from the homenet is an important
consideration, but the homenet/ISP border may not be the only border
in a homenet. It is desirable that there are mechanisms to detect
other types of borders, and then the means to apply different types
of filtering policies at those borders, e.g. whether naming and
service discovery should pass a given border. Any such policies
should be able to be easily applied by typical home users, e.g. to
give a visitor in a "guest" network access to media services in the
home, or access to a printer in the residence. Simple mechanisms to
apply policy changes, or associations between devices, will be
required./
There are many potential borders related to the homenet. Some of
these borders may be obvious by their nature
and direct relationship to a physical interface e.g. the border
between a high capacity network and a LLN, whilst others less so.
The borders may also change over time, dependent on the deployment
scenario
e.g. a LLN for building control may be fitted during construction as
a stand-alone network,
and then only later connect to a homenet when the residents move in.
The ISP/customer border is defined by ownership of equipment,
and this can also change over time e.g. one ISP may supply CER
routers, but a competitor ISP doesn't.
The filtering policy to/from the homenet to ISP networks is an
important consideration.
This might include standard ingress and egress filtering [BCP38],
as well as other default security policies designed to protect
customer-owned resources and ISP-owned resources.
It is desirable that there are mechanisms to automatically detect the
borders, including those that may be less obvious
e.g. a logical separation between a "guest" network and an "internal"
network,
and then the means to apply different types of filtering policies at
those borders.
Filtering should be considered in a wider context than just simple
packet filters e.g. whether a naming and
service discovery should pass a given border, the functions available
to a user
when connecting to a management interface froma certain network,
or filtering of information learned by dynamic routing protocols.
Any such policies should be able to be easily applied by typical home
users
e.g. to grant a "guest" user access to a printer on the "internal"
network.
Simple mechanisms to apply policy changes, or associations between
devices, will be required./
/It is desirable to classify the external border of the home network
as a unique logical interface separating the home network from
service provider network/s. This border interface may be a single
physical interface to a single service provider, multiple layer 2
sub-interfaces to a single service provider, or multiple connections
to a single or multiple providers. This border makes it possible to
describe edge operations and interface requirements across multiple
functional areas including security, routing, service discovery, and
router discovery./
I have a problem with the 2nd and 3rd sentences of this paragraph. It
mixes organisational interfaces and technical network interfaces.
When we start associating the external border with physical interfaces,
I think we risk running into problems given the current document.
In the current document, the customer may have two CER routers connected
to two providers (Figure 2)
One of these CER's could be provider managed CER1 and the other customer
managed CER2.
So the homenet extends to the WAN interface of each CER?
That isn't explicitly shown anywhere.
If the CER has to take part in autoconfiguration, that presumably means
that to support the architecture of figure 2 CER1 will have to accept
prefixes from ISP2. It'll also have to accept a default route to ISP2 if
the WAN interface to ISP1 goes down. At what point does the ISP
controlling CER1 truly have full management control if they can't even
control the routing, and they have to accept neighbours and dynamic
routing from a customer controlled device? Presumably they have to place
their BCP38 filters on the WAN interface? They'll also have to be
careful that any management traffic gets sent over the ISP1 interface
from an ISP1 prefix, and not to ISP2 (via the default route just learned
when the WAN interface goes down). Similarly, how is a customer going to
be able to control CER1 sufficiently to be able to add shared secrets
etc. required to pair with their devices, when it is controlled by ISP1?
I'm not optimistic that this is a workable operational situation.
The way we've traditionally handled this in the corporate world is to
define an Network to Network Interface (NNI) with one router managed by
each party connected back to back over a DMZ, and with no end user
devices connected on this interconnection LAN. There would almost
certainly need to be homenet specifications for both sides of the
border. But that would also break the current autoconfiguration drafts,
because they assume the device initiating autoconfiguration is the same
device performing DHCPv6 PD.
Section 3.3.1
/The alternative for a homenet would be to deploy NPTv6
[RFC6296] at the CER, with ULAs then typically used internally.
NPTv6 has some architectural cost, due to the prefix translation
used, but the internal part of the homenet (which is the scope of
this text) sees only the one prefix in use./
I think this is controversial, and as has been pointed out recently on
the WG list, is likely to break name resolution.
Also see section 3.4.4 of the architecture /those addresses must not be
altered in transit./
As such I think this sentence should be removed.
s/[I-D.ietf-6man-rfc3484bis]/[RFC6724]/
Section 3.4.2
Here's 2 examples of the fuzzy external border.
An IPv6-only homenet wouldn't have an IPv4 connection to the CER,
because the CER is within the homenet.
/functionality in the home gateway router, Such features are outside the
scope of this document however, being CER functions./
Isn't CER within the homenet?
Section 3.4.4
/In IPv4 NAT networks, the NAT provides an implicit firewall function./
Controversial and out of scope. Suggest delete this sentence.
Incorrect quotes going further than the original RFC:
s/ RFC 4864 implies an IPv6 "default deny" policy for inbound
connections be used for similar functionality to IPv4 NAT. /
RFC 4864 Section 4.2 states that "the use of firewalls and Intrusion
Detection Systems (IDSs) is recommended for those that want boundary
protection in addition to host defenses./
s/It should be noted that such a "default deny" approach would
effectively replace the need for IPv4 NAT traversal protocols with a
need to use a signalling protocol to request a firewall hole be opened./
It should be noted that applying a default deny rule for inbound traffic
may require use a signalling protocol to request a firewall hole be opened./
Section 3.4.5
There were many comments on the list about potential negative aspects of
ULA.
s/ULAs should be used within the scope of a homenet to support routing
between subnets regardless of whether a globally unique ISP-provided
prefix is available./ULAs could potentially be used within the scope
of a homenet to support routing between subnets regardless of whether a
globally unique ISP-provided prefix is available, although it should be
noted that ULA's may also have some limitations and downside./
Section 3.4.6
s/In general the routing protocol should support multiple ISP uplinks
and delegated prefixes in concurrent use/
In general the routing protocol should support multiple customer
internet connecions, and thus multiple delegated prefixes in concurrent use/
Section 3.4.7
Suggest adding a sentence or two on splitting and recombination
s /The homenet will need to be aware of the extent of its own "site", as
discussed in the previous section./
The homenet will need to be aware of the extent of its own "site", as
discussed in the previous section. It may be assumed that the homenet is
fully connected. If a homenet becomes segmented for whatever reason,
this may result in multiple separate, but fully functional, homenets
e.g. if the interlink between CER1 and CER2 in figure 2 were to break,
this might end up as two disjoint and completely separate homenets, with
all hosts still able to communicate with the Internet (using their
existing prefixes) via their remaining ISP link. The converse is also
true: when two or more homenet routers are (re)connected together (and
they can determine that it is intended that they communicate), it is is
expected that they will reconfigure to form a single contiguous homenet
(with or without disruption to existing communications)./
/There may also be a prefix associated with NAT64, if in use in the
homenet./
Suggest delete. Out of scope.
/border CER/
What is a "border CER"?
s/Where ULAs are used,/
If ULAs are used,/
s/The router should/
The elected router should/
s/should give each link a prefix/
should result in each link being assigned a stable prefix/
Section 3.4.9
What is a dual-stack residential gateway?
Suggest
s/The naming service should be able to resolve results for both IPv4 and
IPv6 addresses, and with queries transported over either IPv4 or IPv6,
where the homenet is running in dual stack operation/ ?
Section 3.4.10. Proxy or Extend?
Suggest moving the last two paragraphs of 3.4.9 into 3.4.10 and combine
3.4.10. Proxy or Extend?
Current service discovery protocols are generally aimed at single
subnets. There are two broad approaches for allowing services that would
otherwise be link-local to work across a homenet site, and these may
also need to be combined
in practical implementations.
In the example of service discovery, one approach is to take
protocols like mDNS and
have them run over site multicast within the homenet.
Implementing Extended mDNS (xmDNS) [I-D.lynn-homenet-site-mdns], may
require
IPv6 multicast to be available across the scope of the whole homenet.
This approach is fine if all hosts support the extension, and the
scope within any internal
borders is well-understood. But it's not backwards-compatible with
existing link-local protocols.
And it may have a negative impact on some hosts and media types.
In some parts of the homenet, e.g. LLNs, devices may be sleeping, in
which case a proxy for such nodes may be required, that can respond
to multicast service discovery requests. Those same parts of the
network may have less capacity for multicast traffic that may be
flooded from other parts of the network. In general, message
utilisation should be efficient considering the network technologies
the service may need to operate over.
The alternative approach is to proxy service discovery across each
link, to propagate it.
This is more complex, but is backwards-compatible. It would also need
to work with IPv6, and
dual-stack.
The homenet architecture proposes that any existing protocols that
are designed to only work within a subnet should be extended to work
across subnets, rather than defining proxy capabilities for each of
those functions. However, while it is desirable to extend protocols
to site scope operation rather than providing proxy functions on
subnet boundaries, the reality is that until all hosts can use site-
scope discovery protocols, existing link-local protocols would need
to be proxied anyway.
Some protocols already have proxy functions defined and in use, e.g.
DHCPv6 relays, in which case those protocols would be expected to
continue to operate that way.
Section 3.4.11
s/However, if only a /64 is offered by the ISP, the homenet may be
severely constrained, or even unable to function./
<p>BCP 157 [RFC6177] also states that " A key principle for address
management is that end sites always be
able to obtain a reasonable amount of address space for their
actual and planned usage, and over time ranges specified in years
rather than just months. In practice, that means at least one
/64, and in most cases significantly more. One particular
situation that must be avoided is having an end site feel
compelled to use IPv6-to-IPv6 Network Address Translation or other
burdensome address conservation techniques because it could not
get sufficient address space."
However, if insufficient address space is delegated by the ISP, the
homenet may be severely constrained, or even unable to function./
/This implies the use of ULAs as supported in RFC 6204./
I think there's still some debate here. Suggest deleting this sentence.
Section 3.5.
This misses one of the great challenges thrown down by "how to avoid
NAT' related to management boundaries.
Suggest adding
/IPv4/NAT/MAC address spoofing have been widely (ab)used to isolate
customer managed portions of the network from network service provider
managed portions. One of the expected challenges will be dealing with
increased inter-dependencies between a customer and the ISP, given the
new transparency of this interface, and the expected increased interaction.
regards,
RayH
Ray Bellis wrote:
> On 22 Feb 2013, at 15:15, Brian E Carpenter <[email protected]>
> wrote:
>
>> I went through the draft, and noticed an instance of the word "hoemnet" in
>> section 2.4.
>>
>> Otherwise I think this is now in good shape for publication.
>
> Brian - thanks for the review!
>
> Working Group participants:
>
> I know Tim has had some received some feedback directly, but so far on-list I
> make it one "ready to go" and one "more work required".
>
> Please *do* review this version as thoroughly as possible before March 4th.
>
> thanks,
>
> Ray
>
>
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
