RE: [v6ops] Possible issue with source address selection for ULAs...

[Vasilenko Eduard <[e-mail]>]

Hi all,
ULA is different from private IPv4 in the Telco environment
Because for any additional functionality in the data plane on the transit (like SRv6)
IPv6 needs to layer another IPv6 data plane: IPv6 should be encapsulated into IPv6 by RFC 2473.
This outer IPv6 data plane effectively shields the address type used inside the Telco environment.
If ICMP would happen then it would be destined to the source of the outer IPv6 data plane (Carrier PE), not to the source of the inner data plane (user host).
Hence, even for the case of IPv4 in the inner data plane, ICMP PTB would be properly processed on ingress IPv6 PE.

Anyway, I vote against ULA for Telco infrastructure.
Because ULA would impose Carrier to have double IPv6 data plane (and only IPv6 for outer data plane) forever for all services
to shield ULA from the external audience.

The tunneling story is broken when the outer data plane is MPLS over v6. MPLS does not have its own ICMP staff to handle it properly.

Reminder, that the majority of IPv4 traffic is carried in GRT (Global Routing Table), not inside VPN.
Because many features are not developed for VPNs. And because of additional scalability requirements to routers in a VPN case.
It would be not good if RFC 2473 tunnels would become mandatory for plain IPv6 Internet traffic.

RFC 2473 tunnels for inter-domain services would request ULA routing between Carriers
That looks like a violation of ULA specification and a low-probable address collision.

Maybe a need to connect infrastructure from the Internet
That would be blocked with ULA numbering.

Hence, I see just a list of limitations. I do not understand the advantage.
The story of better security is not viable. If somebody would like such type of filtering on the perimeter then filter GUA block. It would be possible to reverse if one would change his mind or stumble upon some limitations.
ULA is a one-way ticket, not flexible. Some limitations are already evident.

Eduard
-----Original Message-----
From: v6ops [mailto:[e-mail]] On Behalf Of Brian E Carpenter
Sent: Wednesday, January 5, 2022 10:52 PM
To: Michael Richardson <[e-mail]>; Manfredi (US), Albert E <[e-mail]>
Cc: IPv6 Ops WG <[e-mail]>; 6man WG <[e-mail]>
Subject: Re: [v6ops] Possible issue with source address selection for ULAs...

> If I can avoid using ULA, I would always do that.

All the same, it seems that we really need a document that characterises use cases for ULA usage and suggests guidelines.
We've tried and failed to do that it in the past, so the issue keeps coming up.

Regards
    Brian

On 06-Jan-22 04:46, Michael Richardson wrote:
> 
> Manfredi (US), Albert E <[e-mail]> wrote:
>      > What about air-gapped networks? I'm considering doing just this. 
It
>      > avoids involving any other organization, in the assignment of IPv6
>      > addresses, number of subnets, subnetting architecture, or any 
> of
that.
> 
> It also leaves you with no whois or rDNS for when the airgap fails, 
> your packets get out, and someone ponders who to tell.
> (I see this *REGULARLY*)
> 
> IPv6 is beyond plentiful.
> If I can avoid using ULA, I would always do that.  No technical entity 
> with more than 1000 people should be without their own assignment in my opinion.
> 
>      > Use the ULA prefix rules, to keep the addresses unique in each
>      > platform, document this, and no one else needs to be involved.
> 
> Exactly.  Nobody else is involved, so nobody can ever help you.
> 
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>             Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
> 

_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops