Re: [v6ops] Why MHMP is still not operational

I am not aware of much progress on MHMP since RFC7157 and RFC8043.

O.

> On 1 Aug 2022, at 22:11, Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org> wrote:
> 
> Hi all,
> There were a few comments on IETF to draft-vv-6man-nd-support-mhmp that the problem was resolved.
> The finger was pointed to PvD (provisioning domains) RFC 8801.
> I would say that RFC 8028 is more relevant (fixed more MHMP ND issues), but let's discuss PvD.
>  
> PvD in principle has a negligible influence on MHMP at the ND level.
> Explicit (special ND options) or Implicit (separate LLA+RA) PvD just helps to emulate many virtual routers out of one physical.
> Exactly the same effect would be on the link if many physical routers would be on the link.
> It does not matter whether virtual or physical routers are feeding different information to the link.
> OK. We would make this comment in the next version of the document. It looks obvious.
> In fact, just a PIOs list per router is enough information to make an MHMP decision for ND. PvD does not help ND.
> PvD is very valuable to connect PIOs to DNSes that is very needed for MHMP in general (proper DNS is important too) but not for the ND part.
>  
> The problem is about the assumption made throughout SASA (RFC 6724) that the next hop is chosen before the source address.
> Section 7: “This specification of source address selection assumes that routing (more precisely, selecting an outgoing interface on a node with multiple interfaces) is done before source address selection.”
> As Brian pointed out to me, bind() may help to choose the source address first. That is probably the case for server applications.
> The normal client application would probably use getaddrinfo() in the majority of cases. All OSes are compliant with RFC 6724. It means that the next hop would be chosen before the source address.
> The next hop choice is currently specified as a random round-robin by RFC 4861.
> Reminder, RFC 8028 and RFC 6724 have “Rule 5.5 of RFC 6724 states that the source address used to send to a given destination address should, if possible, be chosen from a prefix known to be advertised by the next-hop router for that destination.”
> It means that the only PIO1 leading to the “walled garden” would become not available for choice because it is sourced from Router1 only that was not chosen at random.
> Ups, getaddrinfo() would choose the next hop (random) and then source address that would be filtered on the internet (it would not reach the destination).
> The same problem would prevent choosing the best Carrier for cost/delay/latency/policy reasons. getaddrinfo() just randomly points to the wrong source address. In full compliance with RFC 6724.
>  
> RFC 6724 logic should be reversed. RFC 6724 is ready for it – it was assumed as an option.
> draft-vv-6man-nd-support-mhmp section 4 and 6.1 discusses how to choose a source address.
> DNS, PvD, and simpler methods are included.
>  
> It is the reason why ULA+NPT is the only way for Carrier redundancy yet.
> getaddrinfo() randomly chooses the wrong source address if it has the choice.
>  
> PS: I am extremely surprised how it did happen that the forwarding decision (next hop) has been decided to make before the packet is constructed (source address is not chosen)?!? It is illogical. It is a request for trouble.
>  
> <image001.png>
> Best Regards
> Eduard Vasilenko
> Senior Architect
> Europe Standardization & Industry Development Department
> Tel: +7(985) 910-1105, +7(916) 800-5506
>  
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops