Hi Ray, Thanks as ever for the comments, which I have integrated and commented on below....
On 23 Feb 2013, at 18:40, Ray Hunter <[email protected]> wrote: > 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? We assume that the CER has an interface to one or more ISPs, and to one or more internal subnets. See section 3.2 where topology is discussed. > This is my biggest worry. Do we have a good handle on the interface at > the border? The text talks about demarcation: "Demarcation of the CER. The CER(s) may or may not be managed by the ISP. If the demarcation point is such that the customer can provide or manage the CER, its configuration must be simple. Both models must be supported." > 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. Fair point, some of that has been copied. We don't use language like 'end-user network' in this text though; instead we use 'homenet'. > 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? Added to the definitions. > /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? Deleted, as it's covered under routing. > /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. Indeed. The elmination of NAT part has been left in though. > 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./ Yes, it would be preferable if internal ULAs were used, even if different, rather than GUAs. That should be (auto) configurable. > 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 seems you're commenting on older text here Ray? > /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. I think the statements (sentences two and three) hold; how it is implemented, as you discuss, is further detail to be discussed as solution(s) emerge? The demarcation text I mentioned above states that the CER may belong to the ISP or the user. > 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. I don't see it in the -07 text. You may be looking at an older version? > s/[I-D.ietf-6man-rfc3484bis]/[RFC6724]/ OK, you definitely are :) > 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. I don't see where this is stated. > /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. No one else has made that comment, as yet. It leads into the 4864 statement in the next 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./ Rewritten to focus on addressability and reachability. > 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./ That's a bit vague though? But this is clearly something we need to put to bed, one way or the other. > 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)./ This is a more general comment that the network may change over time... not really applicable to this section. I've added a note elsewhere in the 'support arbitrary topologies' section. > /There may also be a prefix associated with NAT64, if in use in the > homenet./ > Suggest delete. Out of scope. Deleted. > /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/ ? Not sure which part of the text this refers to. Old version? > 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? This doesn't exist in -07? > > 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./ That's a useful citation, thanks. > /This implies the use of ULAs as supported in RFC 6204./ > I think there's still some debate here. Suggest deleting this sentence. We need to resolve it properly, not just delete it :) > 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. Not sure that's needed though? Too much detail? Thanks! Tim > > 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
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
