RE: Automatically connecting to stub networks...

[Vasilenko Eduard <[e-mail]>]

Ted,
I did think a little more
And come to conclusion
That it does not make sense to specify stub network as the routed network.
It is better to have it as multi-link (L2).

Because MHMP is still the big and unresolved problem on IPv6.
MHMP should coordinate:

1.      Source address selected

2.      With next hop on the host

3.      With source routing inside site (up to Carrier)
The good idea is presented in RFC 8028 - not pushed through all related RFCs and not accepted by the market yet.
Hence, it is better to avoid MHMP ground. All assumptions here are shaky.
Unfortunately, If you would insist on routed solution for stub network – you have to have to deal with MHMP.
/64, DNS, renumbering - would be bonus problems.

PS: IPv4 has just NAT on every border to Carrier to get the redundancy.

Ed
From: Vasilenko Eduard
Sent: 3 декабря 2020 г. 17:46
To: 'Ted Lemon' <[e-mail]>
Cc: 6MAN <[e-mail]>
Subject: RE: Automatically connecting to stub networks...

Pascal has developed good solution for multi-link. He claims that it is extremely good specifically for low powered wireless. I tend to believe him, but maybe I need additional investigation.
Fred is developing some sort of multi-link. For wireless again☺
You are talking about L2 proxy – it means that L2 was not ruled out completely.
But then why you are talking just about L2 proxy?
IMHO: it is better to say that L2 is ruled out in principle – put it out of the scope. It is “only routing” option research.
Or tell why WiND is not suitable. Look to other solutions above L2 proxy.

By the way, L2 solution would not have many problem of routing solution:
L2 is not dependent on /64 problem, DNS is easy (including mDNS), etc.
Does it matter for research?
Ed/
From: Ted Lemon [mailto:[e-mail]]
Sent: 3 декабря 2020 г. 17:27
To: Vasilenko Eduard <[e-mail]<mailto:[e-mail]>>
Cc: 6MAN <[e-mail]<mailto:[e-mail]>>
Subject: Re: Automatically connecting to stub networks...

On Dec 3, 2020, at 5:15 AM, Vasilenko Eduard <[e-mail]<mailto:[e-mail]>> wrote:
I believe that it is very big question should it be L2 or L3 solution for stub router?

An L2 solution simply isn’t possible when the media in question have such different characteristics. E.g., there’s no way to do this with 6lowpan.  The closest you can easily get is proxy ARP, which is discussed in the document. This is particularly problematic if you have multiple ingresses to the stub network. Implementation becomes complex. Doing it at L3 is much simpler. My goal here is to come up with simple solutions, not interesting problems. :)

In any case, an L2 solution is simply a different solution. It’s not a stub network. If you can make it work for you, great, but if you can’t, that’s when a stub network solution may be a better choice.