Subject: Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07

From: Teco Boot <[email-masked]>
Date: Mon, 4 Mar 2013 09:09:30 +0100

Reading the homenet-arch, I can't find how multi-addressed hosts are guided to prefer one address over another. I think such facility is beneficial in multi-homed homenets.

Teco

Op 12 feb. 2013, om 16:00 heeft Ray Bellis het volgende geschreven:

> This email marks the commencement of Working Group Last Call for draft-ietf-homenet-arch-07.
> 
> The WGLC will end on Monday March 4th.
> 
> Ray and Mark.
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Ole Troan <[email-masked]>
Date: Mon, 4 Mar 2013 09:51:08 +0100

Teco,

> Reading the homenet-arch, I can't find how multi-addressed hosts are guided to prefer one address over another. I think such facility is beneficial in multi-homed homenets.

the intention is to propagate the SAS/DAS policy given with draft-ietf-6man-addr-select-opt,
and more specific routes learn on the border, combined with source address dependent forwarding.
as well as rule 5.5 of 6724.

that's in solution space though. there is already a reference to the multihoming-without-ipv6nat document.

do you have ideas of anything else we should add to the architecture document?

cheers,
Ole

---

From: Teco Boot <[email-masked]>
Date: Mon, 4 Mar 2013 12:56:01 +0100

> as well as rule 5.5 of 6724.
This will work when every access router is a DHCP server, right? What if no DHCP or DHCP-relay? Do we generate this option out of routing information? Or some other zero-config magic?

> do you have ideas of anything else we should add to the architecture document?
Maybe it is my reservations on the current suggested solutions. I don't understand why we don't make use of ND. Then, access routers can provide whatever they wish, from whatever source and the host can ignore or take some benefits.

Teco

---

From: Kazunori Fujiwara <[email-masked]>
Date: Mon, 04 Mar 2013 21:03:55 +0900 (JST)

last call comment to draft-ietf-homenet-arch-07

* Site local address only segments.

 Some sensors do not need global unicast addresses. In many cases,
 they need to connect their controller only.

 If this type of segments are useful, please add this in Section 2.1
 as "site only network". (filtering also support this type of network)

# homenet may be mix of GUA only, SLA only, GUA+SLA.

* Section 3.1.2 Minimize changes to hosts and routers

 In my opinion, changes to routers are easier than changes to hosts.
 I prefer adding such line:
    If we need some changes for routers or hosts,
    choose changes of routers rather than changes of hosts.

* Service Discovery

 Please add references to Service Discovery.

 Are current Service Discoveries implemented as Bonjour, UPnP or
 Service Location Protocol ?

Regards,

--
Kazunori Fujiwara, JPRS/WIDE, [email-masked]/[email-masked]

---

From: Ole Troan <[email-masked]>
Date: Mon, 4 Mar 2013 13:04:05 +0100

Teco,

> This will work when every access router is a DHCP server, right? What if no DHCP or DHCP-relay? Do we generate this option out of routing information? Or some other zero-config magic?

I don't think there is any intention of creating SAS/DAS policy on the fly. I was only thinking of passing that along to hosts.
the homenet will using SADR ensure that BCP38 rules are satisfied. nothing more.

I'm not sure what you mean by the DHCP question. DHCP has an option to pass SAS/DAS policy to hosts. I'm not suggesting DHCP is used to propagate that information around between routers in the home net.

> Maybe it is my reservations on the current suggested solutions. I don't understand why we don't make use of ND. Then, access routers can provide whatever they wish, from whatever source and the hos…

again I don't quite understand what you mean. which protocol is used to convey network information to the hosts doesn't much matter in my view...

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Mon, 4 Mar 2013 08:41:35 -0500

> Reading the homenet-arch, I can't find how multi-addressed hosts are guided to prefer one address over another. I think such facility is beneficial in multi-homed homenets.

On what basis would such guidance be offered?

---

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

Ultimately, I would like to see a host in a homenet with multiple prefixes have at least the same information for guiding source address selection as a host which is directly connected to multiple networks with multiple interfaces. 

- Mark

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Mar 2013 15:01:14 +0000

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-masked]> 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-masked]> 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
>> 
>>

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Mar 2013 20:27:02 +0000

> Ultimately, I would like to see a host in a homenet with multiple prefixes have at least the same information for guiding source address selection as a host which is directly connected to multiple…

This is hinted at in the arch text.

The implementation demonstrated at IETF85 shows how src/dst routing can be used.  I believe that's being presented briefly, with an update, tomorrow.

The arch text describes the minimal functionality required.

Tim

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Mar 2013 20:33:47 +0000

> # homenet may be mix of GUA only, SLA only, GUA+SLA.

The ULA-only case is clear for certain types of devices.  If a device has GUA-only, that implies non-use of ULAs.

>    choose changes of routers rather than changes of hosts.

I would agree.  I'd like to hear more views on this though.

> Service Location Protocol ?

It could be any of the above.

Tim

---

From: Teco Boot <[email-masked]>
Date: Wed, 20 Mar 2013 08:51:59 +0100

Ole,

Still I am puzzled how we can support multiple provisioning domains with multi-addressed hosts in a homenet. May I reference to the discussion in mif?
http://www.ietf.org/proceedings/86/slides/slides-86-mif-1.pdf 

For providing information on provisioning domains, we might look into DHCP _and_ ND. I think both can and should be supported. I think one of the problems is how to merge or multiplex information from/for these provisioning domains. Has DHCP a kind of ProvisioningDomain_ID on each (serf of) data element(s)? On SAS/DAS policy, how to create such automatically in network elements? If we can't on the fly, it might be irrelevant for homenet.

I agree SADR is a major part of the right solution. Source address indicates the provision domain, at least for IPv6. Hosts need to be updated and mif should take the lead here. But mif only can take the job if the network supports multiple provisioning domains well, e.g. SADR. Updated hosts need SADR as well. 

And of course the legacy stuff is out there.

Re-reading sections on multihoming (3.2.4, also 3.4.4), there is enough room for solution space. I would expect some more guidelines form an architecture, but now there are no constrains on what we may work out. That's fine.

May I suggest to add MPTCP (RFC 6824) at bottom of 3.2.4?

Teco

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Mar 2013 23:38:42 +0100

Teco,

> For providing information on provisioning domains, we might look into DHCP _and_ ND. I think both can and should be supported. I think one of the problems is how to merge or multiplex information f…

unmanaged and policy are at different ends of the scale. I don't know how you can do anything automatic with that.

in the homenet prototype I was talking about we implemented draft-bhandari-dhc-class-based-prefix-04.
where we attached a "colour" to each address prefix. this could then be used as a handle for SAS/DAS or for the application.
I don't think the homenet should get into the "policy" part of this, but rather just provide some simple tools/infrastructure.

> I agree SADR is a major part of the right solution. Source address indicates the provision domain, at least for IPv6. Hosts need to be updated and mif should take the lead here. But mif only can ta…

I've always seen SADR as a network function. hosts would do RFC6724.

there would be some gain in being able to signal hosts with routing information. not sure what that should be, unless we would just have hosts participate in the IGP.

> May I suggest to add MPTCP (RFC 6824) at bottom of 3.2.4?

agree.

cheers,
Ole

---

From: Teco Boot <[email-masked]>
Date: Thu, 21 Mar 2013 06:51:34 +0100

Hi Ole,

> unmanaged and policy are at different ends of the scale. I don't know how you can do anything automatic with that.

So we face a problem here...
That's why I think it is a bad idea to merge information from different provisioning domains into a single service. Multiplexing looks better, then policies from provisioning domains can be transferred to the mif hosts without mangling.
That brings me to the concept that provisioning domains are identified by (IPv6) prefixes and each prefix has its own configuration channel, either DHCP or ND.
With BRDP, my proposal is that the ND BRDP "border prefix" or "provision domain ID" is also the DHCP server address, so aware mif hosts can get policies from it.

> where we attached a "colour" to each address prefix. this could then be used as a handle for SAS/DAS or for the application.

OK, I missed this. I have my doubts on the proposed class encoding / coloring scheme.

> I don't think the homenet should get into the "policy" part of this, but rather just provide some simple tools/infrastructure.

Hmm.
I also prefer simple tools/infrastructure. But let's try to solve some problems, or at least we shall not block solving later on.

> I've always seen SADR as a network function. hosts would do RFC6724.

SADR on hosts is used quite often, where redundant links are in place.

> there would be some gain in being able to signal hosts with routing information. not sure what that should be, unless we would just have hosts participate in the IGP.

The IP stack of many host operating systems are able to route. So if we implement SADR on routers, hosts will have the code also one day.
I'm not so comfortable on having hosts running the routing deamon.
That's why I came on the BRDP based routing idea, where all nodes in the edge network act equivalent: route the packets with destinations external to the edge network to the right border router. Works with all routing protocols. Works for mif hosts. Only the Prefix_to_BorderRouter_table is needed, with some SADR forwarding logic.

Back to the draft-ietf-homenet-arch WGLC: this provisioning domain topic is not addresses very well. Question is if we will address it, hand it over to mif, or cooperate where we focus on the (plug&play) network part and mif takes the hosts.
@Ted: can you guide us here?

Teco

---

From: Ole Troan <[email-masked]>
Date: Thu, 21 Mar 2013 09:13:12 +0100

Teco,

[...]

> I also prefer simple tools/infrastructure. But let's try to solve some problems, or at least we shall not block solving later on.

are the problems clearly understood at this point?
written down?

> SADR on hosts is used quite often, where redundant links are in place.

that's not SADR. SADR is about _forwarding_ of packets.

[...]

> Back to the draft-ietf-homenet-arch WGLC: this provisioning domain topic is not addresses very well. Question is if we will address it, hand it over to mif, or cooperate where we focus on the (plug…

I think we have a fair idea of how to deal with the home network being multi-homed. i.e. two or more connections to the Internet.
we also have a decent idea of how to deal with multi-homing to non-congruent networks, see draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05
I'm not quite sure what problem "multiple provisioning domains" is trying to solve outwith that.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Mar 2013 06:45:57 -0400

> @Ted: can you guide us here?

There's a third alternative: help MIF to get it right.   The work is certainly in MIF's charter, and homenet has bitten off a pretty big chunk, so duplicate work is worth avoiding.   At the same time, I think MIF is in fact crucial to homenet, so if you want to see homenet succeed it's in your interests to help with the work MIF is doing as well.

I'm hearing a lot of useful thinking about the MIF architecture here, which I would like to see captured in the MIF architecture document.

---

From: Teco Boot <[email-masked]>
Date: Thu, 21 Mar 2013 20:46:41 +0100

Hi Ole,

> written down?

We have RFC6418 and RFC4477.
Maybe we need to write down the multiple DHCP server problem (homenet with set of CPE devices attach to different provides, each with "incompatible" DHCP info). v6ops-ipv6-multihoming-without-ipv6nat-05 points towards the problem, section 7.3.  Policy collision consideration.
However, in the abstract it says:
   ...  We conclude that DHCPv6 based
   solutions are suitable to solve the multihoming issues, described in
   this document, while NPTv6 may be required as an intermediate
   solution.
May I say I think DHCPv6 and NPTv6 don't fix the problems? Maybe they make live even harder for right shaped MIF hosts.

> that's not SADR. SADR is about _forwarding_ of packets.

The troan-homenet-sadr is written for routers. It applies to hosts with multiple interfaces or single interface with multiple next-hop routers as well: same problem, can use same solution. For both cases, RFC6724 hosts need a little luck to make best guesses.
So for me, Source Address Dependent Routing (SADR) and source address-based routing (out of multihoming-without-ipv6nat-05) are two names for same animal.

> I think we have a fair idea of how to deal with the home network being multi-homed. i.e. two or more connections to the Internet.

Yes, we can deal with routing: do something with source address.

> I'm not quite sure what problem "multiple provisioning domains" is trying to solve outwith that.

I don't think we decided how to deal with disjunct config options (DHCPv6 or learned via other means), on how we can relay this info over a homenet to a MIF host, without losing any functionality.
draft-boot-homenet-brdp-00 deals with it. It provides MIF hosts pointers to the border router, where for each provisioning domain there is a prefix and a border router with an address within that prefix. So an aware host can get all it wants to know.

Teco