Re: [homenet] Egress Routing Discussion: Baker model

[Ole Troan <[e-mail]>]

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