What does a unicast source address actually indicate? (Re: RFC2460bis and draft-previdi-6man-segment-routing-header-08)

[Mark Smith <[e-mail]>]

Hi,

(Generalising the topic)

On 5 October 2015 at 21:06,  <[e-mail]> wrote:
>>>> How about something like this:
>>>>
>>>>    Extension headers are only allowed to be added to packets at
>>>>    the source node.
>>>>
>>>> I think that was always the intent and this would be a clarification to the specification.
>>> Bob,
>>> "source node" might not be sufficiently specific in the case of tunneling, and "added" can be read as their insertion is somehow independent and we want it to be coupled with the insertion of an IPv6 header.
>>>
>>> I think what we want to say is that extension headers can only be placed in packets by the same node that is placing the base IPv6 header in the packet. Hence they can not be added unless a preceeding IPv6 header is also added.
>>
>> Good suggestion.
>
> what about:
>
>    1.  If the SRH specifies the complete path from source to
>         destination, the router places the SRH directly in the datagram
>         itself.

So if this sort of processing occurs, we now have a single packet with
parts that have been created by two different devices, with only the
identify of one of them recorded in the packet's unicast source
address.

So that means that the source address in the packet isn't really a
"unicast" source address any more, because 'uni' means one, yet this
packet actually has two sources for its different parts. Semantically
it is a multi-source packet, yet one of the sources of the part of the
packet, and what part of the packet it created, isn't recorded in the
packet.

This lack of record of all packet part sources is what causes problems
with PMTUD if the addition of headers triggers it, as the identify of
the device that caused the packet to exceed the PMTU is not available.

It also causes problems with troubleshooting, because if you look at
the packet by itself, the fundamental assumption is that the device
identified by the source address is the device that created the whole
packet. Any faults you find you can only assume can be attributed to
the device with the recorded unicast source address.

The same sorts of problems can also show up when multiple hosts are
sharing the same "unicast" address e.g., load balancer scenario, an
anycast scenario or a 1:M NAT scenario. (I'd say that the sharing of
"unicast" addresses should be for the purpose of device selection, and
then the selected device's actual unicast/unique address is used from
then on.)

So I think a unicast source address is fundamentally intended to
identify a unique and single packet source, to which the contents of
the whole packet can be attributed.

Therefore, any time "multi-sourcing" of packets occurs, mechanisms
that assume and rely on a packet's unicast source address identifying
a single and unique source may fail, due to the now ambiguous source
address in the packet.

I think this ambiguity problem is also why we don't use multicast
addresses as packet source addresses.

In this SRH case, even though it costs packet overhead, by tunnelling
the original packet inside another IPv6 header with the SRH, the
unicast source address fields in each of the packet headers
unambiguously identify which parts of the packet were created by which
individually identified device. Any mechanisms or methods which either
assume or rely on a packet's unicast source address identifying a
single and unique source for the whole of the packet will now work
successfully.


Regards,
Mark.

>
>    2.  If the SRH only specifies a subset of the path from source to
>        destination, the router uses IPv6-in-IPv6 tunneling [RFC2473] and
>        places the SRH in the outer IPv6 header.  Use of tunneling
>        ensures that the datagram is delivered unmodified and that ICMP
>        errors return to the source of the SRH rather than the source of
>        the original datagram.
>
>
> which is verbatim from RFC6554.
>
> cheers,
> Ole
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>