[16NG] An interpretation of draft-iab-multilink-subnet-issues-02.txt in 16ng context

[Alexandru Petrescu <[e-mail]>]

Trying to find out under what conditions this draft recommends the use
of a prefix-per-mobile, and see how it applies to 802.16 IPv6CS ptp links.

I've purportedly choosen paragraphs that IMHO are relevant to
IPv6-over-IPv6CS.  If there are others, please point me to them.

> Some examples of protocols today that are known to embed some 
> assumption about the relationship between TTL and subnet prefix are:
> 
> 
> o Neighbor Discovery (ND) [RFC2461] uses messages with Hop Limit 255
>  checked on receipt, to resolve the link-layer address of any IP 
> address in the subnet.

Ok, ND checks Hop Limit to be 255.  No prefix-per-mobile recommendation yet.

> Some other examples of protocols today that are known to use a TTL 1
>  or 255, but do not appear to explicitly have any assumption about
> the relationship to subnet prefixes (other than the well-known
> link-local prefix) include:
> 
> o Link-Local Multicast Name Resolution [LLMNR] uses a TTL/Hop Limit 
> of 1.
> 
> o Multicast Listener Discovery (MLD) [RFC3810] uses a Hop Limit of 1.
> 
> 
Ok, MLD uses hop limit 1.  It's different than ND but not an issue,
because different protocols (MLD doesn't talk to ND).

> It is unknown whether any implementations of such protocols exist 
> that add such assumptions about the relationship to subnet prefixes 
> for other reasons.

I agree.

> The well-known examples of protocols using link-scoped multicast or 
> broadcast generally fall into one of the following groups: [...] For
>  example, ND uses link-scoped multicast to resolve the link-layer 
> address of an IP address in the same subnet prefix, and to do 
> duplicate address detection (see section 2.4 below) within the 
> subnet.

Nit to draft-iab comments, not relevant in this context, it's in the
fe80 prefix, which is not a subnet prefix.  [If BSD and/or linux
implement fe80 as a subnet prefix then it's a problem, not mine.]

> 4. Recommendations:
> 
> It is RECOMMENDED that one of the following two models be used:
> 
> o Multiaccess link model: In this model, there can be multiple nodes
>  on the same link, including zero or more routers.  Data packets sent
>  to the IPv4 link-local broadcast address (255.255.255.255) or to a 
> link-local multicast address can be received by all other interested
>  nodes on the link.  Two nodes on the link are able to communicate 
> without any IPv4 TTL or IPv6 Hop Limit decrement.  There can be any 
> number of layer 2 devices (bridges, switches, access points, 
> whatever) in the middle of the link.
> 
> o Point-to-point link model: In this model, there are exactly two 
> nodes on the same link.  Data packets sent to the IPv4 link-local 
> broadcast address or to a link-local multicast address can be 
> received by the other node on the link.  The two nodes are able to 
> communicate without any IPv4 TTL or IPv6 Hop Limit decrement. There 
> can be any number of layer 2 devices (bridges, switches, access 
> points, whatever) in the middle of the link.

Ok, we're point-to-point case (for IPv6-overIPv6CS).  Text above doesn't
cite prefix-per-link.

> Loop prevention: If physical loops cannot exist within the subnet, 
> then removing the TTL/Hop Limit decrement is not an issue. Otherwise,
>  implementers SHOULD either retain the decrement but use a separate 
> prefix per link, or else use some form of bridging protocol instead 
> (e.g., [BRIDGE] or [RBRIDGE]).

Physical loops can not exist within the ptp link, so no recommendation
to use prefix per link.  Do you think there can be physical loops?  How?

> One of the reasons sometimes cited for wanting a multilink subnet 
> model (rather than a multi-access link model), is to minimize the 
> ARP/ND traffic between end-nodes.  This is primarily a concern in 
> IPv4 where ARP results in a broadcast that would be seen by all 
> nodes, not just the node with the IPv4 address being resolved.  Even
>  if this is a significant concern, the use of a multilink subnet
> model is not necessary.  The point-to-point link model is one way to
> avoid this issue entirely.

Ok, this is IPv6 ptp, so use the point-to-point link model.

> In the multi-access link model, IPv6 ND traffic can be reduced by 
> using well-known multicast learning techniques (e.g., [RFC4541] at a
>  layer 2 intermediate device (bridge, switch, access point,
> whatever).
> 
Ok, this is about IPv6-over-IPv6CS, the rfc4541 is for IPv6-over-ETHCS.

Besides, if IPv6-over-IPv6CS is about the SS too the above paragraph
omits talk about the end node.

> Limiting broadcast (including all-hosts multicast): If there is no 
> efficiency requirement to prevent broadcast from going to other 
> on-link hosts, then flooding it within the subnet is not an issue. 
> Otherwise, implementers SHOULD either use a separate prefix per link,
>  or else flood broadcast other than ARP within the subnet (ARP is 
> covered below in section 4.3).

There is an efficiency requirement, flooding is an issue.

So either use prefix-per-link, or flood broadcast other than ARP within
subnet.  I take that 'other' to be IPv6 multicast.

> Limiting the scope of other multicast (including IPv6 Neighbor 
> Discovery): If there is no efficiency requirement to prevent 
> multicast from going to other on-link hosts, then flooding multicast
>  within the subnet is not an issue.  Otherwise, implementers SHOULD 
> either use a separate prefix per link, or else use IGMP/MLD snooping
>  [RFC4541] instead.

Yes, there is an efficiency goal - I think it is a goal in wireless
deployments to not wake up SSs under BS that haven't expressed interest
in receiving a certain multicast group.

So, instead of using prefix-per-link, and instead of using MLD snooping,
I think it is possible to use MLD.

It is something that I've tried several times to suggest to
IPv6-over-IPv6CS to structure the ptp link into something
multicast-capable; I gave my thoughts how that would be possible, but I
got rejected.

So one may need to decide between having multicast-capable ptp links or
using prefix-per-mobile with its address waste consequences.

It's a take, thanks,

Alex


_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng