Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?

[Mark Smith <[e-mail]>]

Hi Michael,

On Thu, 26 Nov 2020, 04:26 Michael Richardson, <[e-mail]>
wrote:

>
> Philip Homburg <[e-mail]> wrote:
>     >> In
>     >> general, defining something special for P2P topology (or P2MP) is
>     >> not a bad architecture decision. Why not? P2P has really big
>     >> difference from Multi-Access for address resolution point of view.
>
>     > So we get something like
>     > - If the downstream network does homenet, delegate prefixes using
> homenet.
>     > - If the downstream network is p2p (for example a VPN client), do RA
> or DHCP PD
>     > - If the downstream network is configured as p2p ethernet then do RA
> or
>     > DHCP PD
>     > - If the downstream network is other ethernet do DHCP PD.
>
> A point of draft-richardson-6man-cpe-provisioning-00 (expired, rather
> immature),
> was to allow the downstream device to declare what they were, and how they
> wanted to get addresses.   I was imagining an IP6CP option that would
> simply
> advise what the downstream is, and what the upstream could support.
> This avoids assigning a /64 (and running RA) to the link if it makes no
> sense.
>

This would have been making a specific layer 2 involved in layer 3,
coupling layer 3 advancement to that layer 2.

IPv6 has moved away from layer 2 extensions or protocols to operate or
configure layer 3, and the advantage is that options can be added to a
protocol that operates at the IPv6 layer, and it automatically works over
all current and future link layers.

A good example. With IPv4 over PPP, there are very limited things to that
can be configured remotely via IPCP in a residential environment e.g. SIP
servers can't. With IPv6 over PPP, and DHCPv6 being used, SIP and all of
the other DHCPv6 options, current and new, automatically works over PPP.

All IPv6 requires from a link layer is unicast and multicast capability,
and a payload type value or a way to implicitly represent that the IPv6 is
being carried (e.g. MPLS label - although see RFC8469 for why implicit
isn't a great). Everything else in IPv6 should happen at the IPv6 layer
independent of the link layer.


Regards,
Mark.



> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>