Re: [homenet] Egress Routing Discussion: Baker model

[Ray Hunter <[e-mail]>]

> Lorenzo Colitti <mailto:[e-mail]>
> 25 February 2013 01:50
> On Fri, Feb 22, 2013 at 10:06 PM, Ole Troan <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     > IPv6 Host H1 will receive two PIO's, one each from R1 and R2, with
>     > autoconfiguration and on-link flags set, and configure /64
>     prefixes from
>     > both provider 1 and provider 2 (RFC 2461 4.6.2) and it will know
>     these
>     > as being on-link.
>     >
>     > But IMHO there's no further AS number/provider information/upstream
>     > topology information coupled to these /64 prefixes. There might be a
>     > router-router interconnect LAN between R1 and R2, or there might
>     not be.
>
>     if there is no interconnect between R1 and R2, then the host has two
>     interfaces connected to two separate connections. then I can't see how
>     that can be solved in the network. my assumption is that all
>     homenet routers must be connected (I see I haven't stated that
>     anywhere, but that should be added).
>
>
> Do we really need this?
>
Actually I meant a connection between 2 routers higher up the topology
i.e. not one where the only common connection between CER1 and CER2 is
also shared with (local) end hosts on the same LAN. But the discussion
has gone the right way anyway.
> When I originally put together the strawman it seemed to me that there
> are only two cases: either the two border routers have a path to each
> other, or they don't. If they do not have a path to each other, then
> the host cannot be connected to both routers using the same interface
> - because if it is, it's a broadcast interface and those two routers
> are also connected to each other.
>
> Should we write this in the draft?
>  
Figure 2 of the architecture is the problematic one, where there are end
hosts that share the only connection between 2 CERs (from competing ISPs).

The end hosts do not share the same information as the 2 routers
(the end hosts ignore routing, and the PIO sent by the 2 CERs are
non-overlapping, as they are configured by 2 independent ASs).
>
>     > How will the host H1 know to associate source address prefixes from
>     > provider2 with router2 for off link destinations e.g. to a
>     Provider2/56
>     > or Provider2/32?
>
>     in your case it will RFC6724, rule 5.5
>
>
> You don't need to invoke RFC 6724 for this. RFC 3484 (prefer outgoing
> interface) is enough. We should put this in the draft though.
>
No. From the hosts perspective, SA & SB are on the same interface.
>
>     > My expected host behavior would currently be that it'd just
>     choose one
>     > of the known available default routers from the list. If correct
>     fine.
>     > If not, then wait for an ICMPv6 redirect to be told to use the
>     other router.
>
>     you would only get that if the routers were connected of course.
>     whichever came first, you'd either get a unreachable code 5 (wrong
>     source)
>     or ICMP redirect, or the router would just forward the packet to
>     second router.
>
>
> Please let's not design something that requires ICMP redirects to
> work. It will be slow and unreliable.
>  
Agreed.
>
>     > Thus H1 should never send packets with a source address derived
>     from a
>     > PIO received in an RA from R2, to a potential default router R1 that
>     > sent an RA message but did not include a PIO for this particular
>     source
>     > prefix?
>     >
>     > Where is this behavior defined in an RFC? I don't see it in
>     > http://www.ietf.org/rfc/rfc2461.txt Section 4.2 or
>     > http://tools.ietf.org/html/rfc4862#page-18
>     > In fact section 6.3.6. on default router selection is quite
>     explicit and
>     > doesn't mention associating potential default routers with prefix
>     > information options at all AFAIK.
>
>     again, that's rule 5.5 (which is somewhat weak) in 6724.
>
>
> 3484 rule 5 too, right? Or not?
Nope. You'd need the updated version of address selection (RFC6724) rule
5.5. which binds SA to next hop, rather than outbound physical interface.
So this might be an issue with existing implementations, and those which
do not track which prefix assignment was learned from which next hop.

An alternative would be that CER1 learns prefixes from CER2, and
configures up addresses from the competitor ISP on its own router,
(potentially accepting a candidate default route too if its own WAN link
goes down), which might be problematic from a management and operations
perspective e.g. if CER1 is also providing ISP1 specific services like
TV or telephony.

Which is why I've raised concerns about the definition of the Homenet
border in the architecture document.
This never came into play in 6204 (single router, single AS)
> Ole Troan <mailto:[e-mail]>
> 22 February 2013 14:06
> Ray,
>
> [...]
>
>>>    2. Aren't we forgetting the first hop?
>>>
>>>    Given a shared subnet/prefix/link with 2 CPE routers performing some
>>>    fancy new form of forwarding (based on PBR or SADR or whatever)
>>>    that is
>>>    also shared by existing host implementations, how will the routers
>>>    signal these new default route semantics to end hosts?
>>>
>>>    Would we need a new prefix information option in ND?
>>>
>>>    Would we need an extension to RFC 4191 Section 2.3 Route Information
>>>    Option to include (source prefix,destination prefix) routes?
>>>
>>>    Would we need a new ICMPv6 redirect message to extend RFC2461 Section
>>>    4.5 to include the possibility of (source,destination) redirects?
>>>
>>>
>>> The beauty of this approach is that you don't need to signal anything
>>> to the hosts for things to work properly. The hosts pick whatever
>>> source address they choose and the network takes care of getting the
>>> packet to the right exit.
>>>
>> Don't understand. Maybe I'm being really dumb.
>>
>> What about figure 2 of the Homenet Architecture? <fixed width>
>>
>>           +-------+-------+     +-------+-------+         \
>>           |   Service     |     |   Service     |          \
>>           |  Provider A   |     |  Provider B   |           | Service
>>           |    Router     |     |    Router     |           | Provider
>>           +------+--------+     +-------+-------+           | network
>>                  |                      |                   /
>>                  |      Customer        |                  /
>>                  | Internet connections |                 /
>>                  |                      |
>>           +------+--------+     +-------+-------+         \
>>           |     IPv6      |     |    IPv6       |          \
>>           | Customer Edge |     | Customer Edge |           \
>>           |   Router 1    |     |   Router 2    |           /
>>           +------+--------+     +-------+-------+          /
>>                  |                      |                 /
>>                  |                      |                | End-User
>>     ---+---------+---+---------------+--+----------+---  | network(s)
>>        |             |               |             |      \
>>   +----+-----+ +-----+----+     +----+-----+ +-----+----+  \
>>   |IPv6 Host | |IPv6 Host |     | IPv6 Host| |IPv6 Host |  /
>>   |   H1     | |   H2     |     |    H3    | |    H4    | /
>>   +----------+ +----------+     +----------+ +----------+
>>
>>                                 Figure 2
>>
>> </fixed width>
>>
>> IPv6 Host H1 will receive RA messages from R1 and R2, and add them both
>> to the default router list (RFC2461 6.3.6).
>>
>> IPv6 Host H1 will receive two PIO's, one each from R1 and R2, with
>> autoconfiguration and on-link flags set, and configure /64 prefixes from
>> both provider 1 and provider 2 (RFC 2461 4.6.2) and it will know these
>> as being on-link.
>>
>> But IMHO there's no further AS number/provider information/upstream
>> topology information coupled to these /64 prefixes. There might be a
>> router-router interconnect LAN between R1 and R2, or there might not be.
>
> if there is no interconnect between R1 and R2, then the host has two
> interfaces connected to two separate connections. then I can't see how
> that can be solved in the network. my assumption is that all homenet routers
> must be connected (I see I haven't stated that anywhere, but that should be added).
>
>> How will the host H1 know to associate source address prefixes from
>> provider2 with router2 for off link destinations e.g. to a Provider2/56
>> or Provider2/32?
>
> in your case it will RFC6724, rule 5.5
>
>> My expected host behavior would currently be that it'd just choose one
>> of the known available default routers from the list. If correct fine.
>> If not, then wait for an ICMPv6 redirect to be told to use the other router.
>
> you would only get that if the routers were connected of course.
> whichever came first, you'd either get a unreachable code 5 (wrong source)
> or ICMP redirect, or the router would just forward the packet to second router.
>
>> But the ICMPv6 redirect doesn't have any facility to include source
>> prefix specific info: only a redirect for a destination prefix to use
>> another router (for all source prefixes), not for a source/destination
>> pair. In the situation depicted in Homenet Arch figure 2, there will
>> almost certainly be two valid routes to e.g. www.google.com, one via
>> each provider, with the correct 1st hop router dependent purely on the
>> source prefix.
>
> I agree, there is nothing useful the host learns from an ICMP redirect here.
>
>> Even with RFC4191, the extension only provides routing information for a
>> host to be able to select a default router based on the destination
>> prefix, not an associated source prefix.
>>
>> Are we saying that H1 should tightly couple source address selection
>> with RA PIO & default router selection?
>
> for directly connected hosts, we have that already. note that only applies when
> hosts are connected to the border router.
>
>> Thus H1 should never send packets with a source address derived from a
>> PIO received in an RA from R2, to a potential default router R1 that
>> sent an RA message but did not include a PIO for this particular source
>> prefix?
>>
>> Where is this behavior defined in an RFC? I don't see it in
>> http://www.ietf.org/rfc/rfc2461.txt Section 4.2 or
>> http://tools.ietf.org/html/rfc4862#page-18
>> In fact section 6.3.6. on default router selection is quite explicit and
>> doesn't mention associating potential default routers with prefix
>> information options at all AFAIK.
>
> again, that's rule 5.5 (which is somewhat weak) in 6724.
>
>> Are we saying that R1 should forward any packets it receives for
>> (source_provider_prefix 2, ::/0) back over the same LAN to R2 without an
>> ICMPv6 redirect? [Assuming R1 is managed by Provider 1 and R2 is managed
>> by Provider 2]
>
> yes, I think we probably would want to say that.
>
>> Won't the providers naturally want to apply their BCP38 ingress filter
>> on the LAN interface of their CPE routers? 
>> as per draft-ietf-v6ops-6204bis-12 L-14 [LAN side requirements]
>>
>> The IPv6 CE router MUST send an ICMPv6 Destination Unreachable
>>          message, code 5 (Source address failed ingress/egress policy)
>>          for packets forwarded to it that use an address from a prefix
>>          that has been invalidated.
>>
>>
>>> If the right exit is down or gone, then the packet gets dropped, but
>>> as the SADR draft explains, you can fix this by telling the homenet
>>> routers to deprecate prefixes for which there is no exit. The hosts
>>> will then avoid those source addresses for new connections. (The
>>> authors of said draft do not agree amongst themselves whether this is
>>> the right thing to do or not; but no doubt the WG will have useful
>>> opinions here).
>>>
>> Understand this. It's the first hop that bother me.
>>
>> Maybe Figure 2 in the Homenet Architecture is actually a fundamentally
>> flawed topology, purely from a management perspective.
>>> If you want the hosts to do better load-balancing, then you do need to
>>> give them more information. We haven't looked at this.
>>>
>>> If you want to support walled garden prefixes that do not have
>>> complete reachability, then you need to tell the hosts not to use
>>> them. I believe DHCPv6 options exist to configure RFC 6724 policy on
>>> hosts, but I don't know if anyone supports them, and I haven't thought
>>> about the security issues or how to propagate that information through
>>> the homenet.
>>>
>>>    3. Limiting this discussion strictly to Homenet requirements:
>>>     Aren't we
>>>    forgetting the inter-provider management boundary?
>>>
>>>    My view of the Homenet is a network that is potentially a member of
>>>    multiple overlapping AS's simultaneously, without being an AS itself.
>>>    That's highly unusual in routing protocol terms.
>>>
>>>    I think that it is very unlikely that any operator will allow any
>>>    dynamic routing between a CPE managed by a customer and a PE
>>>    managed by
>>>    the provider.
>>>
>>>    I think there's also a potential issue of anyone making any
>>>    assumptions
>>>    about dynamic routing being available between a provider-managed
>>>    CPE and
>>>    a customer owned CPE. Software version control will not be trivial.
>>>
>>>    The current most likely source of external routing information is
>>>    DHCPv6-PD, used to locally autoconfigure a "floating static" default
>>>    route on the Homenet BR, pointing out of the upstream interface to
>>>    "the
>>>    Internet".
>>>
>>>    As such, how will any routing information beyond a simple default
>>>    route
>>>    (related to a single delegated prefix) be injected into the Homenet?
>>>
>>>    Why are we importing the extra complexity (related to data centres and
>>>    enterprises) into Homenet?
>>>
>>>
>>> I thought the idea was that border routers would just do DHCPv6 PD and
>>> inject whatever routes they get into the homenet tagged with whatever
>>> source prefix they get.
>> Yes.
>>> They wouldn't participate in any routing protocol with the ISP. We
>>> don't currently have any other mechanism for learning external routes,
>>> but when we do we can simply treat them in the same way.
>>>
>>> Does this not work for some reason?
>>>
>> No problem, but why worry about it now if it greatly increases the
>> complexity?
>>
>> draft-ietf-v6ops-6204bis-12 effectively limits information in Homenet to
>> simple default routes per provider only.
>>
>> W-3:  Absent other routing information, the IPv6 CE router MUST use
>>         Router Discovery as specified in [RFC4861] to discover a
>>         default router(s) and install default route(s) in its routing
>>         table with the discovered router's address as the next hop.
>>
>> WPD-7:  By default, an IPv6 CE router MUST NOT initiate any dynamic
>>           routing protocol on its WAN interface.
>
> but 6204 does support more specific routes in RAs (RFC4191?)
>
>>>    6. Other potentially simpler approaches that might be faster to market
>>>    I have provided detailed feedback to Ole & Lorenzo, suggesting how
>>>    Homenet could potentially work without modifying any routing protocols
>>>    at all, with multi-homing, without resorting to NPT, and with BCP38
>>>    ingress/egress filters (albeit with a hard link to some
>>>    yet-to-be-defined autoconfiguration protocol, and a limit that the
>>>    prefixes of any walled-gardens must be disjoint from other AS's
>>>    directly
>>>    connected to this Homenet, and possibly some other limitations such as
>>>    dumb hosts should not be connected to dual routers from competing
>>>    providers).
>>>
>>>
>>> Did I miss this? Where can I find it? Was it sent to the list?
>> Yes. http://www.ietf.org/mail-archive/web/homenet/current/msg02130.html
>>> Ray Hunter <mailto:[e-mail]>
>>> 22 February 2013 10:52
>>> I have read all of your drafts, and those of the other authors,
>>> carefully, once. No doubt I'll have to re-read them.
>>>
>>> This response is limited to high level comments regarding the overall
>>> approach, and isprobably applicable to all 3 sets of authors :
>>>
>>> 1. Some drafts talk extensively about the need for an "extensible"
>>> routing protocol, and often mention the desirability of TLV
>>> (type-length-value) objects.
>>>
>>> I agree that a TLV structure potentially solves many issues of how to
>>> encode and transport new options between routing protocol speakers.
>>>
>>> But given that route determination is a distributed algorithm, and that
>>> Homenet devices will not always run the latest and greatest code,
>>> what action should nodes that are running older code take regarding any
>>> TLV options that they don't understand?
>>>
>>> Isn't there a danger that extensibility will lead to more routing loops,
>>> instability, and black holes?
>>>
>>> Is there a need for all speakers to first agree the (newest)
>>> commonly-understood subset of options that all speakers in a Homenet
>>> can/will honour before any extension options are transmitted?
>>>
>>> 2. Aren't we forgetting the first hop?
>>>
>>> Given a shared subnet/prefix/link with 2 CPE routers performing some
>>> fancy new form of forwarding (based on PBR or SADR or whatever) that is
>>> also shared by existing host implementations, how will the routers
>>> signal these new default route semantics to end hosts?
>>>
>>> Would we need a new prefix information option in ND?
>>>
>>> Would we need an extension to RFC 4191 Section 2.3 Route Information
>>> Option to include (source prefix,destination prefix) routes?
>>>
>>> Would we need a new ICMPv6 redirect message to extend RFC2461 Section
>>> 4.5 to include the possibility of (source,destination) redirects?
>>>
>>> 3. Limiting this discussion strictly to Homenet requirements: Aren't we
>>> forgetting the inter-provider management boundary?
>>>
>>> My view of the Homenet is a network that is potentially a member of
>>> multiple overlapping AS's simultaneously, without being an AS itself.
>>> That's highly unusual in routing protocol terms.
>>>
>>> I think that it is very unlikely that any operator will allow any
>>> dynamic routing between a CPE managed by a customer and a PE managed by
>>> the provider.
>>>
>>> I think there's also a potential issue of anyone making any assumptions
>>> about dynamic routing being available between a provider-managed CPE and
>>> a customer owned CPE. Software version control will not be trivial.
>>>
>>> The current most likely source of external routing information is
>>> DHCPv6-PD, used to locally autoconfigure a "floating static" default
>>> route on the Homenet BR, pointing out of the upstream interface to "the
>>> Internet".
>>>
>>> As such, how will any routing information beyond a simple default route
>>> (related to a single delegated prefix) be injected into the Homenet?
>>>
>>> Why are we importing the extra complexity (related to data centres and
>>> enterprises) into Homenet?
>>>
>>> 4. We're still planning on doing something about source address
>>> selection, aren't we?
>>> For all the suggested complexity of the packet routing solutions
>>> suggested so far, isn't the real "route" selection going to be performed
>>> in the host?
>>>
>>> 5. Flow label routing: hasn't rfc6437 scuppered any chance that the flow
>>> labels themselves will directly carry any meaning that could be
>>> realistically used to make deterministic forwarding decisions by
>>> low/mid-powered routers, because you're essentially going to have to
>>> reverse a 20 bit hash function to make a forwarding decision? Wouldn't
>>> the requirements in rfc6437 also suggest a routing table explosion,
>>> because each individual flow would have to be associated with an
>>> individual IS-IS route? Perhaps you could distribute some intermediate
>>> result to end hosts and routers via IS-IS,which is deterministic and
>>> related to policy based routing (such as including the tenant label in a
>>> TLV), but which after applying some hash transform and adding some
>>> entropy, would comply with the requirements of 6437? That'd potentially
>>> reduce the IS-IS routing table size dramatically. I've been waiting 15+
>>> years for fully dynamic PBR and I fully expect to wait some time longer.
>>> In any case, with all due respect, I don't think it's relevant for
>>> Homenet,
>>>
>>> 6. Other potentially simpler approaches that might be faster to market
>>> I have provided detailed feedback to Ole & Lorenzo, suggesting how
>>> Homenet could potentially work without modifying any routing protocols
>>> at all, with multi-homing, without resorting to NPT, and with BCP38
>>> ingress/egress filters (albeit with a hard link to some
>>> yet-to-be-defined autoconfiguration protocol, and a limit that the
>>> prefixes of any walled-gardens must be disjoint from other AS's directly
>>> connected to this Homenet, and possibly some other limitations such as
>>> dumb hosts should not be connected to dual routers from competing
>>> providers).
>>>
>>> Do I need to write a draft on this, or is this already clear?
>>> Would someone be willing to help out/ collaborate?
>>>
>>> If I have other detailed comments on the individual drafts, I'll come
>>> back with those.
>>>
>>> regards,
>>> RayH
>>>
>>> Fred Baker (fred) wrote:
>>>
>>> ------------------------------------------------------------------------
>
>
> cheers,
> Ole
>
> Ray Hunter <mailto:[e-mail]>
> 22 February 2013 13:53
>> Lorenzo Colitti <mailto:[e-mail]>
>> 22 February 2013 11:17
>> On Fri, Feb 22, 2013 at 6:52 PM, Ray Hunter <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>     But given that route determination is a distributed algorithm, and
>>     that
>>     Homenet devices will not always run the latest and greatest code,
>>     what action should nodes that are running older code take
>>     regarding any
>>     TLV options that they don't understand?
>>
>>     Isn't there a danger that extensibility will lead to more routing
>>     loops,
>>     instability, and black holes?
>>
>>
>> Yes. If intermediate devices don't understand SADR, you can get
>> routing loops. We should document that clearly and find out how to
>> avoid it.
>>  
> ACK.
>>     2. Aren't we forgetting the first hop?
>>
>>     Given a shared subnet/prefix/link with 2 CPE routers performing some
>>     fancy new form of forwarding (based on PBR or SADR or whatever)
>>     that is
>>     also shared by existing host implementations, how will the routers
>>     signal these new default route semantics to end hosts?
>>
>>     Would we need a new prefix information option in ND?
>>
>>     Would we need an extension to RFC 4191 Section 2.3 Route Information
>>     Option to include (source prefix,destination prefix) routes?
>>
>>     Would we need a new ICMPv6 redirect message to extend RFC2461 Section
>>     4.5 to include the possibility of (source,destination) redirects?
>>
>>
>> The beauty of this approach is that you don't need to signal anything
>> to the hosts for things to work properly. The hosts pick whatever
>> source address they choose and the network takes care of getting the
>> packet to the right exit.
>>
> Don't understand. Maybe I'm being really dumb.
>
> What about figure 2 of the Homenet Architecture? <fixed width>
>
>            +-------+-------+     +-------+-------+         \
>            |   Service     |     |   Service     |          \
>            |  Provider A   |     |  Provider B   |           | Service
>            |    Router     |     |    Router     |           | Provider
>            +------+--------+     +-------+-------+           | network
>                   |                      |                   /
>                   |      Customer        |                  /
>                   | Internet connections |                 /
>                   |                      |
>            +------+--------+     +-------+-------+         \
>            |     IPv6      |     |    IPv6       |          \
>            | Customer Edge |     | Customer Edge |           \
>            |   Router 1    |     |   Router 2    |           /
>            +------+--------+     +-------+-------+          /
>                   |                      |                 /
>                   |                      |                | End-User
>      ---+---------+---+---------------+--+----------+---  | network(s)
>         |             |               |             |      \
>    +----+-----+ +-----+----+     +----+-----+ +-----+----+  \
>    |IPv6 Host | |IPv6 Host |     | IPv6 Host| |IPv6 Host |  /
>    |   H1     | |   H2     |     |    H3    | |    H4    | /
>    +----------+ +----------+     +----------+ +----------+
>
>                                  Figure 2
>
> </fixed width>
>
> IPv6 Host H1 will receive RA messages from R1 and R2, and add them both
> to the default router list (RFC2461 6.3.6).
>
> IPv6 Host H1 will receive two PIO's, one each from R1 and R2, with
> autoconfiguration and on-link flags set, and configure /64 prefixes from
> both provider 1 and provider 2 (RFC 2461 4.6.2) and it will know these
> as being on-link.
>
> But IMHO there's no further AS number/provider information/upstream
> topology information coupled to these /64 prefixes. There might be a
> router-router interconnect LAN between R1 and R2, or there might not be.
>
> How will the host H1 know to associate source address prefixes from
> provider2 with router2 for off link destinations e.g. to a Provider2/56
> or Provider2/32?
>
> My expected host behavior would currently be that it'd just choose one
> of the known available default routers from the list. If correct fine.
> If not, then wait for an ICMPv6 redirect to be told to use the other router.
>
> But the ICMPv6 redirect doesn't have any facility to include source
> prefix specific info: only a redirect for a destination prefix to use
> another router (for all source prefixes), not for a source/destination
> pair. In the situation depicted in Homenet Arch figure 2, there will
> almost certainly be two valid routes to e.g. www.google.com, one via
> each provider, with the correct 1st hop router dependent purely on the
> source prefix.
>
> Even with RFC4191, the extension only provides routing information for a
> host to be able to select a default router based on the destination
> prefix, not an associated source prefix.
>
> Are we saying that H1 should tightly couple source address selection
> with RA PIO & default router selection?
>
> Thus H1 should never send packets with a source address derived from a
> PIO received in an RA from R2, to a potential default router R1 that
> sent an RA message but did not include a PIO for this particular source
> prefix?
>
> Where is this behavior defined in an RFC? I don't see it in
> http://www.ietf.org/rfc/rfc2461.txt Section 4.2 or
> http://tools.ietf.org/html/rfc4862#page-18
> In fact section 6.3.6. on default router selection is quite explicit and
> doesn't mention associating potential default routers with prefix
> information options at all AFAIK.
>
> Are we saying that R1 should forward any packets it receives for
> (source_provider_prefix 2, ::/0) back over the same LAN to R2 without an
> ICMPv6 redirect? [Assuming R1 is managed by Provider 1 and R2 is managed
> by Provider 2]
>
> Won't the providers naturally want to apply their BCP38 ingress filter
> on the LAN interface of their CPE routers? 
> as per draft-ietf-v6ops-6204bis-12 L-14 [LAN side requirements]
>
> The IPv6 CE router MUST send an ICMPv6 Destination Unreachable
>           message, code 5 (Source address failed ingress/egress policy)
>           for packets forwarded to it that use an address from a prefix
>           that has been invalidated.
>
>
>> If the right exit is down or gone, then the packet gets dropped, but
>> as the SADR draft explains, you can fix this by telling the homenet
>> routers to deprecate prefixes for which there is no exit. The hosts
>> will then avoid those source addresses for new connections. (The
>> authors of said draft do not agree amongst themselves whether this is
>> the right thing to do or not; but no doubt the WG will have useful
>> opinions here).
>>
> Understand this. It's the first hop that bother me.
>
> Maybe Figure 2 in the Homenet Architecture is actually a fundamentally
> flawed topology, purely from a management perspective.
>> If you want the hosts to do better load-balancing, then you do need to
>> give them more information. We haven't looked at this.
>>
>> If you want to support walled garden prefixes that do not have
>> complete reachability, then you need to tell the hosts not to use
>> them. I believe DHCPv6 options exist to configure RFC 6724 policy on
>> hosts, but I don't know if anyone supports them, and I haven't thought
>> about the security issues or how to propagate that information through
>> the homenet.
>>
>>     3. Limiting this discussion strictly to Homenet requirements:
>>      Aren't we
>>     forgetting the inter-provider management boundary?
>>
>>     My view of the Homenet is a network that is potentially a member of
>>     multiple overlapping AS's simultaneously, without being an AS itself.
>>     That's highly unusual in routing protocol terms.
>>
>>     I think that it is very unlikely that any operator will allow any
>>     dynamic routing between a CPE managed by a customer and a PE
>>     managed by
>>     the provider.
>>
>>     I think there's also a potential issue of anyone making any
>>     assumptions
>>     about dynamic routing being available between a provider-managed
>>     CPE and
>>     a customer owned CPE. Software version control will not be trivial.
>>
>>     The current most likely source of external routing information is
>>     DHCPv6-PD, used to locally autoconfigure a "floating static" default
>>     route on the Homenet BR, pointing out of the upstream interface to
>>     "the
>>     Internet".
>>
>>     As such, how will any routing information beyond a simple default
>>     route
>>     (related to a single delegated prefix) be injected into the Homenet?
>>
>>     Why are we importing the extra complexity (related to data centres and
>>     enterprises) into Homenet?
>>
>>
>> I thought the idea was that border routers would just do DHCPv6 PD and
>> inject whatever routes they get into the homenet tagged with whatever
>> source prefix they get.
> Yes.
>> They wouldn't participate in any routing protocol with the ISP. We
>> don't currently have any other mechanism for learning external routes,
>> but when we do we can simply treat them in the same way.
>>
>> Does this not work for some reason?
>>
> No problem, but why worry about it now if it greatly increases the
> complexity?
>
> draft-ietf-v6ops-6204bis-12 effectively limits information in Homenet to
> simple default routes per provider only.
>  
>  W-3:  Absent other routing information, the IPv6 CE router MUST use
>          Router Discovery as specified in [RFC4861] to discover a
>          default router(s) and install default route(s) in its routing
>          table with the discovered router's address as the next hop.
>
> WPD-7:  By default, an IPv6 CE router MUST NOT initiate any dynamic
>            routing protocol on its WAN interface.
>>     6. Other potentially simpler approaches that might be faster to market
>>     I have provided detailed feedback to Ole & Lorenzo, suggesting how
>>     Homenet could potentially work without modifying any routing protocols
>>     at all, with multi-homing, without resorting to NPT, and with BCP38
>>     ingress/egress filters (albeit with a hard link to some
>>     yet-to-be-defined autoconfiguration protocol, and a limit that the
>>     prefixes of any walled-gardens must be disjoint from other AS's
>>     directly
>>     connected to this Homenet, and possibly some other limitations such as
>>     dumb hosts should not be connected to dual routers from competing
>>     providers).
>>
>>
>> Did I miss this? Where can I find it? Was it sent to the list?
> Yes. http://www.ietf.org/mail-archive/web/homenet/current/msg02130.html
>> Ray Hunter <mailto:[e-mail]>
>> 22 February 2013 10:52
>> I have read all of your drafts, and those of the other authors,
>> carefully, once. No doubt I'll have to re-read them.
>>
>> This response is limited to high level comments regarding the overall
>> approach, and isprobably applicable to all 3 sets of authors :
>>
>> 1. Some drafts talk extensively about the need for an "extensible"
>> routing protocol, and often mention the desirability of TLV
>> (type-length-value) objects.
>>
>> I agree that a TLV structure potentially solves many issues of how to
>> encode and transport new options between routing protocol speakers.
>>
>> But given that route determination is a distributed algorithm, and that
>> Homenet devices will not always run the latest and greatest code,
>> what action should nodes that are running older code take regarding any
>> TLV options that they don't understand?
>>
>> Isn't there a danger that extensibility will lead to more routing loops,
>> instability, and black holes?
>>
>> Is there a need for all speakers to first agree the (newest)
>> commonly-understood subset of options that all speakers in a Homenet
>> can/will honour before any extension options are transmitted?
>>
>> 2. Aren't we forgetting the first hop?
>>
>> Given a shared subnet/prefix/link with 2 CPE routers performing some
>> fancy new form of forwarding (based on PBR or SADR or whatever) that is
>> also shared by existing host implementations, how will the routers
>> signal these new default route semantics to end hosts?
>>
>> Would we need a new prefix information option in ND?
>>
>> Would we need an extension to RFC 4191 Section 2.3 Route Information
>> Option to include (source prefix,destination prefix) routes?
>>
>> Would we need a new ICMPv6 redirect message to extend RFC2461 Section
>> 4.5 to include the possibility of (source,destination) redirects?
>>
>> 3. Limiting this discussion strictly to Homenet requirements: Aren't we
>> forgetting the inter-provider management boundary?
>>
>> My view of the Homenet is a network that is potentially a member of
>> multiple overlapping AS's simultaneously, without being an AS itself.
>> That's highly unusual in routing protocol terms.
>>
>> I think that it is very unlikely that any operator will allow any
>> dynamic routing between a CPE managed by a customer and a PE managed by
>> the provider.
>>
>> I think there's also a potential issue of anyone making any assumptions
>> about dynamic routing being available between a provider-managed CPE and
>> a customer owned CPE. Software version control will not be trivial.
>>
>> The current most likely source of external routing information is
>> DHCPv6-PD, used to locally autoconfigure a "floating static" default
>> route on the Homenet BR, pointing out of the upstream interface to "the
>> Internet".
>>
>> As such, how will any routing information beyond a simple default route
>> (related to a single delegated prefix) be injected into the Homenet?
>>
>> Why are we importing the extra complexity (related to data centres and
>> enterprises) into Homenet?
>>
>> 4. We're still planning on doing something about source address
>> selection, aren't we?
>> For all the suggested complexity of the packet routing solutions
>> suggested so far, isn't the real "route" selection going to be performed
>> in the host?
>>
>> 5. Flow label routing: hasn't rfc6437 scuppered any chance that the flow
>> labels themselves will directly carry any meaning that could be
>> realistically used to make deterministic forwarding decisions by
>> low/mid-powered routers, because you're essentially going to have to
>> reverse a 20 bit hash function to make a forwarding decision? Wouldn't
>> the requirements in rfc6437 also suggest a routing table explosion,
>> because each individual flow would have to be associated with an
>> individual IS-IS route? Perhaps you could distribute some intermediate
>> result to end hosts and routers via IS-IS,which is deterministic and
>> related to policy based routing (such as including the tenant label in a
>> TLV), but which after applying some hash transform and adding some
>> entropy, would comply with the requirements of 6437? That'd potentially
>> reduce the IS-IS routing table size dramatically. I've been waiting 15+
>> years for fully dynamic PBR and I fully expect to wait some time longer.
>> In any case, with all due respect, I don't think it's relevant for
>> Homenet,
>>
>> 6. Other potentially simpler approaches that might be faster to market
>> I have provided detailed feedback to Ole & Lorenzo, suggesting how
>> Homenet could potentially work without modifying any routing protocols
>> at all, with multi-homing, without resorting to NPT, and with BCP38
>> ingress/egress filters (albeit with a hard link to some
>> yet-to-be-defined autoconfiguration protocol, and a limit that the
>> prefixes of any walled-gardens must be disjoint from other AS's directly
>> connected to this Homenet, and possibly some other limitations such as
>> dumb hosts should not be connected to dual routers from competing
>> providers).
>>
>> Do I need to write a draft on this, or is this already clear?
>> Would someone be willing to help out/ collaborate?
>>
>> If I have other detailed comments on the individual drafts, I'll come
>> back with those.
>>
>> regards,
>> RayH
>>
>> Fred Baker (fred) wrote:
>>
>> ------------------------------------------------------------------------
>
> Lorenzo Colitti <mailto:[e-mail]>
> 22 February 2013 11:17
> On Fri, Feb 22, 2013 at 6:52 PM, Ray Hunter <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     But given that route determination is a distributed algorithm, and
>     that
>     Homenet devices will not always run the latest and greatest code,
>     what action should nodes that are running older code take
>     regarding any
>     TLV options that they don't understand?
>
>     Isn't there a danger that extensibility will lead to more routing
>     loops,
>     instability, and black holes?
>
>
> Yes. If intermediate devices don't understand SADR, you can get
> routing loops. We should document that clearly and find out how to
> avoid it.
>  
>
>     2. Aren't we forgetting the first hop?
>
>     Given a shared subnet/prefix/link with 2 CPE routers performing some
>     fancy new form of forwarding (based on PBR or SADR or whatever)
>     that is
>     also shared by existing host implementations, how will the routers
>     signal these new default route semantics to end hosts?
>
>     Would we need a new prefix information option in ND?
>
>     Would we need an extension to RFC 4191 Section 2.3 Route Information
>     Option to include (source prefix,destination prefix) routes?
>
>     Would we need a new ICMPv6 redirect message to extend RFC2461 Section
>     4.5 to include the possibility of (source,destination) redirects?
>
>
> The beauty of this approach is that you don't need to signal anything
> to the hosts for things to work properly. The hosts pick whatever
> source address they choose and the network takes care of getting the
> packet to the right exit.
>
> If the right exit is down or gone, then the packet gets dropped, but
> as the SADR draft explains, you can fix this by telling the homenet
> routers to deprecate prefixes for which there is no exit. The hosts
> will then avoid those source addresses for new connections. (The
> authors of said draft do not agree amongst themselves whether this is
> the right thing to do or not; but no doubt the WG will have useful
> opinions here).
>
> If you want the hosts to do better load-balancing, then you do need to
> give them more information. We haven't looked at this.
>
> If you want to support walled garden prefixes that do not have
> complete reachability, then you need to tell the hosts not to use
> them. I believe DHCPv6 options exist to configure RFC 6724 policy on
> hosts, but I don't know if anyone supports them, and I haven't thought
> about the security issues or how to propagate that information through
> the homenet.
>
>     3. Limiting this discussion strictly to Homenet requirements:
>      Aren't we
>     forgetting the inter-provider management boundary?
>
>     My view of the Homenet is a network that is potentially a member of
>     multiple overlapping AS's simultaneously, without being an AS itself.
>     That's highly unusual in routing protocol terms.
>
>     I think that it is very unlikely that any operator will allow any
>     dynamic routing between a CPE managed by a customer and a PE
>     managed by
>     the provider.
>
>     I think there's also a potential issue of anyone making any
>     assumptions
>     about dynamic routing being available between a provider-managed
>     CPE and
>     a customer owned CPE. Software version control will not be trivial.
>
>     The current most likely source of external routing information is
>     DHCPv6-PD, used to locally autoconfigure a "floating static" default
>     route on the Homenet BR, pointing out of the upstream interface to
>     "the
>     Internet".
>
>     As such, how will any routing information beyond a simple default
>     route
>     (related to a single delegated prefix) be injected into the Homenet?
>
>     Why are we importing the extra complexity (related to data centres and
>     enterprises) into Homenet?
>
>
> I thought the idea was that border routers would just do DHCPv6 PD and
> inject whatever routes they get into the homenet tagged with whatever
> source prefix they get. They wouldn't participate in any routing
> protocol with the ISP. We don't currently have any other mechanism for
> learning external routes, but when we do we can simply treat them in
> the same way.
>
> Does this not work for some reason?
>
>     6. Other potentially simpler approaches that might be faster to market
>     I have provided detailed feedback to Ole & Lorenzo, suggesting how
>     Homenet could potentially work without modifying any routing protocols
>     at all, with multi-homing, without resorting to NPT, and with BCP38
>     ingress/egress filters (albeit with a hard link to some
>     yet-to-be-defined autoconfiguration protocol, and a limit that the
>     prefixes of any walled-gardens must be disjoint from other AS's
>     directly
>     connected to this Homenet, and possibly some other limitations such as
>     dumb hosts should not be connected to dual routers from competing
>     providers).
>
>
> Did I miss this? Where can I find it? Was it sent to the list?
> Ray Hunter <mailto:[e-mail]>
> 22 February 2013 10:52
> I have read all of your drafts, and those of the other authors,
> carefully, once. No doubt I'll have to re-read them.
>
> This response is limited to high level comments regarding the overall
> approach, and isprobably applicable to all 3 sets of authors :
>
> 1. Some drafts talk extensively about the need for an "extensible"
> routing protocol, and often mention the desirability of TLV
> (type-length-value) objects.
>
> I agree that a TLV structure potentially solves many issues of how to
> encode and transport new options between routing protocol speakers.
>
> But given that route determination is a distributed algorithm, and that
> Homenet devices will not always run the latest and greatest code,
> what action should nodes that are running older code take regarding any
> TLV options that they don't understand?
>
> Isn't there a danger that extensibility will lead to more routing loops,
> instability, and black holes?
>
> Is there a need for all speakers to first agree the (newest)
> commonly-understood subset of options that all speakers in a Homenet
> can/will honour before any extension options are transmitted?
>
> 2. Aren't we forgetting the first hop?
>
> Given a shared subnet/prefix/link with 2 CPE routers performing some
> fancy new form of forwarding (based on PBR or SADR or whatever) that is
> also shared by existing host implementations, how will the routers
> signal these new default route semantics to end hosts?
>
> Would we need a new prefix information option in ND?
>
> Would we need an extension to RFC 4191 Section 2.3 Route Information
> Option to include (source prefix,destination prefix) routes?
>
> Would we need a new ICMPv6 redirect message to extend RFC2461 Section
> 4.5 to include the possibility of (source,destination) redirects?
>
> 3. Limiting this discussion strictly to Homenet requirements: Aren't we
> forgetting the inter-provider management boundary?
>
> My view of the Homenet is a network that is potentially a member of
> multiple overlapping AS's simultaneously, without being an AS itself.
> That's highly unusual in routing protocol terms.
>
> I think that it is very unlikely that any operator will allow any
> dynamic routing between a CPE managed by a customer and a PE managed by
> the provider.
>
> I think there's also a potential issue of anyone making any assumptions
> about dynamic routing being available between a provider-managed CPE and
> a customer owned CPE. Software version control will not be trivial.
>
> The current most likely source of external routing information is
> DHCPv6-PD, used to locally autoconfigure a "floating static" default
> route on the Homenet BR, pointing out of the upstream interface to "the
> Internet".
>
> As such, how will any routing information beyond a simple default route
> (related to a single delegated prefix) be injected into the Homenet?
>
> Why are we importing the extra complexity (related to data centres and
> enterprises) into Homenet?
>
> 4. We're still planning on doing something about source address
> selection, aren't we?
> For all the suggested complexity of the packet routing solutions
> suggested so far, isn't the real "route" selection going to be performed
> in the host?
>
> 5. Flow label routing: hasn't rfc6437 scuppered any chance that the flow
> labels themselves will directly carry any meaning that could be
> realistically used to make deterministic forwarding decisions by
> low/mid-powered routers, because you're essentially going to have to
> reverse a 20 bit hash function to make a forwarding decision? Wouldn't
> the requirements in rfc6437 also suggest a routing table explosion,
> because each individual flow would have to be associated with an
> individual IS-IS route? Perhaps you could distribute some intermediate
> result to end hosts and routers via IS-IS,which is deterministic and
> related to policy based routing (such as including the tenant label in a
> TLV), but which after applying some hash transform and adding some
> entropy, would comply with the requirements of 6437? That'd potentially
> reduce the IS-IS routing table size dramatically. I've been waiting 15+
> years for fully dynamic PBR and I fully expect to wait some time longer.
> In any case, with all due respect, I don't think it's relevant for
> Homenet,
>
> 6. Other potentially simpler approaches that might be faster to market
> I have provided detailed feedback to Ole & Lorenzo, suggesting how
> Homenet could potentially work without modifying any routing protocols
> at all, with multi-homing, without resorting to NPT, and with BCP38
> ingress/egress filters (albeit with a hard link to some
> yet-to-be-defined autoconfiguration protocol, and a limit that the
> prefixes of any walled-gardens must be disjoint from other AS's directly
> connected to this Homenet, and possibly some other limitations such as
> dumb hosts should not be connected to dual routers from competing
> providers).
>
> Do I need to write a draft on this, or is this already clear?
> Would someone be willing to help out/ collaborate?
>
> If I have other detailed comments on the individual drafts, I'll come
> back with those.
>
> regards,
> RayH
>
> Fred Baker (fred) wrote:
>
> ------------------------------------------------------------------------