Re: [IPv6] Suggestion for multi homed clients without NAT/NPT

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Brian

Eric and I tested the proposal in the RFC on Cisco IOS, adding a few lines of code here and there on the MIP base. It did the multihoming trick quite fine.
For all I know the MIP and NEMO code is still in IOS so you can play with it, but I doubt that there's appropriate tunneling optimization for use in production.
There was a early code in Windows till some intermediate MIP draft then MSFT dropped it. I've never seen it in a phone but others will know better.

The most important thing that MIPv6 is missing for this purpose would be a control message from the HA saying that the Home Address is usable or not (PE/CE up/down). 
This way the host can select the HA and associated Home Address based on the avail/usability of that address. 
Without it I guess the host could still play happy eyeballs between the multihomed v6 home addresses as it does between v4 and v6 addresses already.

All the best for this new year!

Pascal

> -----Original Message-----
> From: ipv6 <[e-mail]> On Behalf Of Brian E Carpenter
> Sent: mardi 3 janvier 2023 20:53
> To: Klaus Frank <[e-mail]>; Pascal Thubert (pthubert)
> <[e-mail]>; Vasilenko Eduard
> <vasilenko.eduard=[e-mail]>; [e-mail]
> Subject: Re: [IPv6] Suggestion for multi homed clients without NAT/NPT
> 
> On 04-Jan-23 04:20, Klaus Frank wrote:
> >
> > On 03.01.2023 09:28, Pascal Thubert (pthubert) wrote:
> >> Hello Brian:
> >>
> >> Quadrature du cercle, catch 22, whatever we call it, as you explain,
> changing the standards for hosts will not work. Left is to change the
> routers and tether phones.
> >>
> >> Combine that with SNAC where routers serving different prefixes must
> be aware of one another and you get something that's closer to ND than
> to a routing protocol where routers learn about each other and relay to
> the prefix owner based on the source address. And if the owner dies,
> then there's PAT as a plan B; though it's disruptive for existing
> connections, it's something that your communication software usually
> handles well and the disruption is often very short. At SNAC I suggested
> the phone could take over a home network that way when the ISP
> connection goes down.
> > With only NAT the connection will fail in almost all cases anyway
> > because of statefull firewalls on the other side. With my suggestions
> > applications (or the operating system) could establish multiple
> > connections one per source IP and transparently failover.
> >> This is something I've presented at various WGs including SNAP in
> London at the last IETF meeting. The draft is
> https://datatracker.ietf.org/doc/draft-thubert-6lo-prefix-registration/.
> It is also a fine complement to the prefix delegation to the host, and
> to the SNAC solution. Both are missing the little magic between DHCP and
> the routers.
> >>
> >> Alt: we've had like forever an MIPv6-based solution whereby the
> internal network is ULA only, and the hosts that need to go outside must
> obtain a home address from the egress routers, the public prefix serving
> as Home Network, the ULA as careof. This was hinted sections 3.4 and 4.7
> of RFC 4864, yes, 15 years ago (and a patent of mine BTW ;). Either
> unaware hosts are either cut from internet, or there's a conscious
> decision to PAT the ULA  prefix at the router as in plan B above.
> >
> > I never thought about it this way, but I kinda like this approach. But
> > sadly MIPv6 doesn't have that great software and documentation
> > coverage (yet)...
> 
> Strangely enough I quite like the proposal in RFC 4864, but my working
> assumption has been that MIPv6 is a mythical protocol. Is there actually
> running code?
> 
> (The patent really isn't an issue, IMHO, since the license is reciprocal
> RAND.)
> 
>     Brian
> 
> >
> > If we were still in the early phases of IPv6 standardization, I'd
> > suggest for making this the default/recommended setup. Probably would
> > also eliminate many of these "but it has a public IPv6 so it is
> > publicly reachable and therefore insecure" nonsense discussions...
> >
> > Speaking of which, UPnPv6 is another issue that should be addressed
> > someday. In many environments there is currently no way to open ports
> > for inbound connections dynamically through statefull firewalls with
> > IPv6 addresses (as UPnPv6 almost always doesn't work even if it is
> > present). Providing the same issue as NAT. But that's a topic for
> > another day...
> >
> >> All the best,
> >>
> >> Pascal
> >>
> >>> -----Original Message-----
> >>> From: ipv6 <[e-mail]> On Behalf Of Brian E Carpenter
> >>> Sent: lundi 2 janvier 2023 23:23
> >>> To: Vasilenko Eduard <vasilenko.eduard=[e-mail]>;
> >>> Klaus Frank <[e-mail]>; [e-mail]
> >>> Subject: Re: [IPv6] Suggestion for multi homed clients without
> >>> NAT/NPT
> >>>
> >>> On 02-Jan-23 22:10, Vasilenko Eduard wrote:
> >>>> Hi Klaus,
> >>>> It is already possible:
> >>>> 1. Use RIO (RFC 4191) to prioritize the choice of the next hop 2.
> >>>> Then use rule 5.5 RFC 6724 to restrict the choice of PIO among
> >>>> those
> >>> advertised by this router only.
> >>>
> >>> Let's not forget that (as pointed out previously) there is no
> >>> standardized way to update RFC 6724 behaviour in all nodes in a
> network.
> >>> Even if we issued RFC6724bis today with rule 5.5 raised to a MUST,
> >>> and changed the recommended default table, or suggested dynamic
> >>> updates to that table, nothing would change in existing hosts that
> >>> don't support rule 5.5.
> >>>
> >>> There's a bit the same problem in Klaus's proposal. It describes
> >>> some changes that would (I assume) work in Linux hosts, but they
> >>> would be different in non-Linux hosts, especially Windows, and there
> >>> is nothing a typical NOC could do that would deploy them.
> >>>
> >>> We need a holistic solution, and for now I'm not sure what that
> >>> could be.
> >>>
> >>> (I agree with you, BTW, that the question of when source address
> >>> selection occurs is also worth discussion. These problems are all
> >>> intertwined.)
> >>>
> >>>       Brian
> >>>
> >>>> The above is a little bit less powerful than the proposed below
> >>>> because If the router (advertised RIO) has many PIOs then which one
> >>>> to
> >>> use?
> >>>> Your answer below this question too.
> >>>> (RFC 7157 was discussing that it is possible to use RFC 7078 for
> >>>> this
> >>>> - it is extremely complex)
> >>>>
> >>>> I see your proposal as an extension of RFC 4191.
> >>>> I still like the reverse of decision logic in RFC 6724 (choose
> >>>> source address first then next hop), But your proposal looks
> >>>> reasonable to me
> >>> too.
> >>>> Eduard
> >>>> -----Original Message-----
> >>>> From: ipv6 [mailto:[e-mail]] On Behalf Of Klaus Frank
> >>>> Sent: Saturday, December 31, 2022 10:51 AM
> >>>> To: [e-mail]
> >>>> Subject: [IPv6] Suggestion for multi homed clients without NAT/NPT
> >>>>
> >>>> Hi,
> >>>>
> >>>> a few weeks ago I was part of a discussion about how to do IPv6
> >>>> without
> >>>> NAT66/NPT66 in a network with multiple up-links. And the result was
> >>> that it is currently not reasonably possible for a number of
> >>> limitations imposed by ISPs to end users (or global routing table
> size).
> >>>> Therefore after some investigation into this problem I'd like to
> >>> suggest two solutions without NAT that will work without manually
> >>> configuring clients.
> >>>> #1 RAPBR (Router Advertised Policy Based Routing)
> >>>> #2 Restricted source prefix flag within the Route Information
> >>>> Option
> >>>>
> >>>> The first one is more general and could be used independently for
> >>>> all
> >>> kinds of policy based routing, where as the 2nd one is a minimal
> >>> solution to specifically this problem. I'd like to suggest
> >>> standardizing (and adopting) both for exactly that reason.
> >>>> Please let me know what you think.
> >>>>
> >>>> Sincerely,
> >>>> Klaus Frank
> >>>>
> >>>>
> >>>>      Goal
> >>>>
> >>>> A user/small business wants to have redundant network connectivity
> >>>> and
> >>> also have a number of in-house hosted services. While keeping the
> >>> tech- stack simple and costs minimal.
> >>>> With IPv4 the setup looks like:
> >>>> * User buys dedicated DSL up-links from two different ISPs (and
> >>> potentially pays for cables being put into the ground).
> >>>> * User connects each of the DSL lines to the ISP provided CPE
> >>> (Customer-premises equipment).
> >>>> * User connects Load Balancer cluster with one cable each to the
> CPEs.
> >>>> * NAT44 happens twice in this configuration. First at the load
> >>> balancer and another time on the CPE.
> >>>> * (optional) CPEs could be configured to only serve as modems and
> >>>> the
> >>> Load Balancing device could do the login and connection, but that
> >>> doesn't change much except remove one of the two address
> translations.
> >>>> But it is a little bit more complex to setup. And could cause
> >>>> issues
> >>> with support/remote diagnostics. So going to ignore it and using the
> >>> general case.
> >>>> ISP 1 ======> Load Balancer <====== ISP 2
> >>>>                         ||
> >>>>                         ||
> >>>>                         \/
> >>>>                   Local Network
> >>>>
> >>>>
> >>>>      Currently possible setups
> >>>>
> >>>>
> >>>>        #1 peering with multiple ISPs
> >>>>
> >>>>
> >>>>          Cons
> >>>>
> >>>> * Own IP range  and ASN required
> >>>> * ISP needs to offer it. Most don't to normal end users.
> >>>> * Significantly more expensive
> >>>> * Advanced network setup (not for pro-users or non-enterprises
> >>>> admins)
> >>>> * If everyone that wants a dual up-link (or just the possibility to
> >>> have it later) would request a IPv6-PI space and an ASN number we'll
> >>> run into issues with the global routing table size. And a lot of
> >>> people were pushing back on the idea of using IPv6-PI space for
> >>> networks with multiple up-links.
> >>>>
> >>>>          Pros
> >>>>
> >>>> * The way IPv6 was designed to handle this
> >>>> * Conceptually the simplest one.
> >>>>
> >>>>
> >>>>        #2 NAT66/NPT66
> >>>>
> >>>>
> >>>>          Cons
> >>>>
> >>>> * NAT, breaks E2E visibility
> >>>> * Breaks P2P traffic (WebRTC, Torrent, ...)
> >>>> * Same issues as with NAT44, thereby destroys all benefits of
> >>>> simplifying the connection logic within applications (same NAT
> >>>> detection logic and workarounds required as with IPv4)
> >>>> * Issues with inbound traffic in general (not suitable for servers)
> >>>> * Pushes bad network design by using NAT. People will use it way
> >>>> too
> >>> often. It shouldn't be the goto solution for this problem or people
> >>> will start to use it everywhere like with IPv4.
> >>>> * Remote hosts may drop connection as source IP changed within one
> >>> connection and respond with a RST anyway (or get blocked by
> >>> statefull firewalls).
> >>>> * Clients completely unaware of the address translation. Remote
> >>>> sees
> >>> different IP than the client used as source. And that may result in
> >>> connectivity issues.
> >>>>
> >>>>          Pros
> >>>>
> >>>> * Known concept from IPv4. Basically the same network design. NAT
> >>>> at
> >>> the border.
> >>>> * Kinda works for some outbound traffic like web browsing.
> >>>>
> >>>>
> >>>>      Proposed Solutions
> >>>>
> >>>>
> >>>>        RAPBR (Router Advertised Policy Based Routing)
> >>>>
> >>>> RAPBR will basically extend the router advertisement messages to
> >>>> tell clients that a specific route is only valid with a specific
> >>>> source prefix. Now clients can just plug multiple CPE routers into
> >>>> a network and have both advertise their prefix and their routes. A
> >>>> client that receives such a message will configure its address as
> >>>> usual but when adding the route from the message will also add a
> source policy.
> >>>>
> >>>> e.g. `default via fe80::5139:b2ca:e8ad:1234 dev eth2  metric 1004
> >>>> src 2001:db8::1` instead of `default via fe80::5139:b2ca:e8ad:1234
> >>>> dev
> >>>> eth2 metric 1004` will be added to the routing table.
> >>>>
> >>>> Additionally to this also using a source prefix should be valid in
> >>>> the future (currently manually configured routes can use the src
> >>>> instruction, but router advertisements cannot; Also the src keyword
> >>>> currently only allows a single address and not a prefix. For a
> >>>> whole prefix a more complex setup using ip rule and tables is
> required).
> >>>>
> >>>> For this to work a new IPv6 Neighbor Discovery Option number is
> >>>> assigned (e.g. the next free one, 42) and using a package format
> of:
> >>>>
> >>>>           0 1                   2                   3
> >>>>            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
> >>>> 8 9 0
> >>>> 1
> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>           |     Type      |    Length     | Prefix Length |
> >>>> SrcPref.Length|
> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>           |                   Prefix (Variable
> >>> Length)
> >>>> | . .
> >>>> . .
> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>           |               Src Prefix (Variable
> >>> Length)
> >>>> | . .
> >>>> . .
> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>
> >>>>        Fields:
> >>>>
> >>>>        Type        42
> >>>>
> >>>>        Length      8-bit unsigned integer. The length of the option
> >>>>                    (including the Type and Length fields) in units
> of 8
> >>>>                    octets.  The Length field is 1, 2, or 3
> >>>> depending on
> >>> the
> >>>>                    Prefix Length.  If Prefix Length is greater than
> >>>> 64,
> >>> then
> >>>>                    Length must be 3.  If Prefix Length is greater
> >>>> than
> >>> 0,
> >>>>                    then Length must be 2 or 3.  If Prefix Length is
> >>> zero,
> >>>>                    then Length must be 1, 2, or 3.
> >>>>
> >>>>        Prefix Length
> >>>>                    8-bit unsigned integer.  The number of leading
> >>>> bits
> >>> in
> >>>>                    the Prefix that are valid.  The value ranges
> >>>> from 0
> >>> to
> >>>>                    128.  The Prefix field is 0, 8, or 16 octets
> >>> depending on
> >>>>                    Length.
> >>>>
> >>>>        SrcPrefix Length
> >>>>                    8-bit unsigned integer.  The number of leading
> >>>> bits
> >>> in
> >>>>                    the Source Address Prefix that are valid.  The
> value
> >>>>                    ranges from 0 to 128.  The Prefix field is 0, 8,
> or
> >>>>                    16 octets depending on Length.
> >>>>
> >>>>        Prefix
> >>>>                    Variable-length field containing an IP address
> or a
> >>>>                    prefix of an IP address.  The Prefix Length
> field
> >>>>                    contains the number of valid leading bits in the
> >>> prefix.
> >>>>        SrcPrefix
> >>>>                    Variable-length field containing an IP address
> or a
> >>>>                    prefix of an IP address.  The SrcPrefix Length
> field
> >>>>                    contains the number of valid leading bits in the
> >>> source
> >>>>                    prefix.
> >>>>
> >>>>
> >>>>        Restricted source prefix flag within the Route Information
> >>>> Option
> >>>>
> >>>> Alternatively to the above solution also using one of the bits of
> >>>> the reserved bits of Router Information Option (Type 24, RFC4191)
> >>>> for telling clients that advertised routes are only valid for the
> >>>> prefixes that are advertised by the same sender/within the same
> message.
> >>>>
> >>>>           0 1                   2                   3
> >>>>            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
> >>>> 8 9 0
> >>>> 1
> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>           |     Type      |    Length     | Prefix Length | Res
> >>>> |Prf|F|Res|
> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>           |                        Route
> >>> Lifetime
> >>>> |
> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>           |                   Prefix (Variable
> >>> Length)
> >>>> | . .
> >>>> . .
> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>
> >>>>        Res (Reserved)
> >>>>                    Two unused fields.  First one is 3-bit and the
> other
> >>>>                    one is 2-bit.  They MUST be initialized to
> >>>>                    zero by the sender and MUST be ignored by the
> >>> receiver.
> >>>>        F (Filtered)
> >>>>                    1-bit flag.  When set to 1 indicates to
> >>>> receivers
> >>> that
> >>>>                    this route must only ever be used with one of
> the
> >>>>                    advertised prefixes (See Type 3, RFC4861 section
> >>> 4.6.2).
> >>>> -------------------------------------------------------------------
> >>>> - IETF IPv6 working group mailing list [e-mail] Administrative
> >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>> -------------------------------------------------------------------
> >>>> -
> >>> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list [e-mail] Administrative
> >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------