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

[Vasilenko Eduard <[e-mail]>]

In the case of multihoming,
The application would need to be associated with many RPL instances,
And choose which one to use for a particular session.
The problem is still here.

In the https://datatracker.ietf.org/doc/html/draft-vv-6man-nd-support-mhmp-01 section 5
We propose 7 potential ways how to decide what source address to use.
The list of solutions is extendable.

Example of te solution from the list:
"It is possible to check the longest match between the source and
     the destination address to choose the potentially closest address.
     This method looks most promising, it is partially discussed in
     [Default Address] section 7."

Eduard
-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[e-mail]] 
Sent: Monday, January 9, 2023 5:32 PM
To: Vasilenko Eduard <vasilenko.eduard=[e-mail]>; Vasilenko Eduard <[e-mail]>; Brian E Carpenter <[e-mail]>; otroan <[e-mail]>
Cc: Michael Richardson <[e-mail]>; 6man WG <[e-mail]>
Subject: RE: [IPv6] Suggestion for multi homed clients without NAT/NPT

Hello Eduard

In the context of RPL:

each application has an associated RPL instance (which is the indicator of the topology). So it is typically the application that pushes the RPL instance ID to the stack when the socket is created. The application also instructs the RPL aware node to participate to the RPL instance. The RPL instance is tailored by an objective function to match the application needs, typically in the terms I discussed, QoS, and sink point (to the outside == CE) that we call Root. E.g., in a sensor-home-network some sensors are associated to the power utility and the packets should be directed to the utility gateway, whereas other sensors would send data to some cloud app over the main home gateway using a different instance. Intermediate routers may participate to multiple instances. The HbH option is very much like a L3 version of the 802.1Q tag. On top of the RPL instance, we signal some OAM for routing assurance in the data path, which allows us to fix the routes reactively and save energy.

In the general context: in the case of the host doing it, you'd need to install something similar to a VPN software with policies that may decide the source address and would tag the packet with the HbH information that matches the source address and the application.  In the case of the router doing it, that could be DPI or at the minimum a src addr / dest port matching, and the router operation would be similar to SRv6, adding either a HbH option or an SRH to reach the appropriate CE router.

Note that the problem of knowing whether the PE is usable remains once the packet can be routed to the appropriate CE. For that we need either signaling to the host about prefix availability or a multihomed variation of happy eyeballs.

All the best

Pascal 



> -----Original Message-----
> From: Vasilenko Eduard <vasilenko.eduard=[e-mail]>
> Sent: lundi 9 janvier 2023 13:52
> To: Pascal Thubert (pthubert) <[e-mail]>; Vasilenko Eduard 
> <[e-mail]>; Brian E Carpenter 
> <[e-mail]>; otroan <[e-mail]>
> Cc: Michael Richardson <[e-mail]>; 6man WG 
> <[e-mail]>
> Subject: RE: [IPv6] Suggestion for multi homed clients without NAT/NPT
> 
> Hi Pascal,
> How host would choose which topology to choose?
> If the host randomly chooses the default router now.
> Eduard
> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Pascal Thubert
> (pthubert)
> Sent: Monday, January 9, 2023 1:45 PM
> To: Vasilenko Eduard <vasilenko.eduard=[e-mail]>;
> Brian E Carpenter <[e-mail]>; otroan 
> <[e-mail]>
> Cc: Michael Richardson <[e-mail]>; 6man WG 
> <[e-mail]>
> Subject: Re: [IPv6] Suggestion for multi homed clients without NAT/NPT
> 
> Hello Eduard
> 
> If we want all possible solutions on the table, there's also the multi 
> topology routing (MTR) way.
> 
> ROLL defines multiple RPL topologies and either the host or the access 
> router places the packet in one routing topology where the source is 
> topologically correct. The CE router to the matching provider is 
> typically the default GW for the topology.
> 
> The RPL topology can be tagged in the packet using RFC 6553, which 
> defines a HbH option. If it is the router doing it, you end up with 
> another variation of a tunnel to the CE. If it's the host, then 
> there's more control on what goes where but the stack is impacted, 
> back to the initial problem.
> 
> Pro: allows to build topologies for other reasons than multihoming, 
> e.g.; QoS (even DetNet), or zerotrust.
> Con: HbH header to process, I read above that Philipp does not want it
> 
> All the best,
> 
> Pascal
> 
> > -----Original Message-----
> > From: ipv6 <[e-mail]> On Behalf Of Vasilenko Eduard
> > Sent: lundi 9 janvier 2023 7:55
> > To: Brian E Carpenter <[e-mail]>; otroan 
> > <[e-mail]>
> > Cc: Michael Richardson <[e-mail]>; 6man WG 
> > <[e-mail]>
> > Subject: Re: [IPv6] Suggestion for multi homed clients without 
> > NAT/NPT
> >
> > Manual prefix assignment is not just inconvenient. It defeats the 
> > purpose of multihoming.
> > Multihoming is primarily for resiliency. If the prefix from the 
> > disconnected carrier would not be automatically deprecated fast 
> > enough then no resiliency.
> >
> > face:b00c:0:xxxx or ::200e is not a PA address. ULA (or PI) does not 
> > need source routing.
> >
> > NOC scripts are typically to detect something, not to fix it 
> > automatically (what we need here).
> >
> > People did play with source routing for ages. I did it in 1998 as a 
> > simplified form of traffic engineering.
> > Indeed, if Enterprise does not have MPLS what else is left?
> >
> > Eduard
> > -----Original Message-----
> > From: Brian E Carpenter [mailto:[e-mail]]
> > Sent: Sunday, January 8, 2023 11:44 PM
> > To: Vasilenko Eduard <[e-mail]>; otroan 
> > <[e-mail]>
> > Cc: Michael Richardson <[e-mail]>; 6man WG 
> > <[e-mail]>
> > Subject: Re: [IPv6] Suggestion for multi homed clients without 
> > NAT/NPT
> >
> > On 08-Jan-23 23:05, Vasilenko Eduard wrote:
> > >> “Manual configuration” which is anything from CLI, Ansible and 
> > >> vendor
> > proprietary interfaces to HNCP, autonomous networking hierarchical 
> > DHCP PD.
> > >
> > > - “Manual configuration” for a dynamic PA prefix is a low 
> > > probability
> > of acceptance.
> >
> > I think all that was intended was "something other than SLAAC or
> > DHCPv6 for address assignment." I do agree that literally manual 
> > techniques are unloved by operators.
> >
> > But if an enrerprise had decided, for example, that its public 
> > servers would all use IIDs like face:b00c:0:xxxx or ::200e, then 
> > this would be "manual"
> > assignment even if it was the result of running a script.
> >
> > > I would be surprised if anybody is using it in production for
> > business.
> > > - CLI, Ansible, SDN Controller (and ANIMA?) are possible. Any 
> > > examples
> > of the product?
> >
> > A lot of NOCs write quite complex configuration scripts, so I don't 
> > think we need an existence proof.
> >
> > > - HNCP was positioned for home, businesses would probably not 
> > > evaluate
> > this option.
> > > - DHCP-PD for multi-hop is not recommended by any standard, nor
> > supported by products.
> > > For sure, we do not have anything adopted by the industry.
> > > And we could say that "no standard" applies.
> > >
> > > Hence, no need for source routing yet.
> >
> > If that was true, the forums for router vendors would not be full of 
> > users asking how to configure source routing. As far as I can see, 
> > the standard answer is to set up a routing policy including a source 
> > address match.
> >
> > > Maybe in the future. Maybe not if NAT would be adopted instead of
> PA.
> > >
> > > Generally, multihop (routing) site is more complex than a single
> link.
> > > The sites that are presented in RFC 8678 are really complex.
> >
> > Yes, there are a lot of complex enterprise networks - precisely the 
> > ones most likely to insist on multihoming.
> >
> >      Brian
> >
> > > Ed/
> > > -----Original Message-----
> > > From: ipv6 [mailto:[e-mail]] On Behalf Of otroan
> > > Sent: Saturday, January 7, 2023 5:02 PM
> > > To: Vasilenko Eduard 
> > > <vasilenko.eduard=[e-mail]>
> > > Cc: Michael Richardson <[e-mail]>; 6man WG 
> > > <[e-mail]>
> > > Subject: Re: [IPv6] Suggestion for multi homed clients without 
> > > NAT/NPT
> > >
> > > Hi,
> > >
> > >> I agree that it is very desirable to have complex sites support 
> > >> (with
> > multiple routing hops) for MHMP too.
> > >> I am just stating the fact that it is not possible yet for PA 
> > >> address
> > space. If/when in the future 6man would standardize the way how to 
> > distribute PA addresses over such a complex site then RFC 8678 would 
> > become applicable (explanation on how to do source routing over such 
> > a site). Up to that time, RFC 8678 is useless - complex topology is 
> > just not possible to get.
> > >
> > > You come over as being very assertive. I don’t know if that is 
> > > what
> > you intend?
> > > I’m all in favour of assertiveness as one of the supported IETF
> > diversity factors (:-)).
> > >
> > > Here the assertiveness is combined with being wrong. At least not
> > nuanced.
> > >
> > > Networks with multiple routing hops are not complex. That’s what 
> > > the
> > we have done for many decades.
> > > Prefix assignment (is that what you mean when you say “distribute 
> > > PA
> > addresses”?) can be done in many ways.
> > > “Manual configuration” which is anything from CLI, Ansible and 
> > > vendor
> > proprietary interfaces to HNCP, autonomous networking hierarchical 
> > DHCP PD.
> > >
> > > We want to enable more routing not less. And if the approach is 
> > > “we
> > can only do multi-homing”, if the host is directly connected to the 
> > egress router, we have failed.
> > >
> > > If we really want to solve the multi-homing problem, we have to go
> > back to the work in multi6, shim6, ILNP. There’s also a lot of work 
> > having been done on multi-homing with single PA space, combined with 
> > tunnels that is interesting.
> > >
> > > MHMP is a dead end.
> > >
> > > O.
> > >
> > > ------------------------------------------------------------------
> > > -- 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
> > --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------