ietf
[Top] [All Lists]

Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

2017-03-15 12:58:21

We do have today use cases where not only the source of a packet should be 
allowed to insert a header but also the source “domain” of a packet. I’ll try 
to explain.

In a domain controlled by a single organization (typically the set of ASs 
under control of the same operator) a packet enters at the edge where the 
ingress node applies a policy resulted into an additional outer ipv6 header 
that may or may not contain an extension header. Bottom line, the outer 
header means that now, it is a NEW packet, originated by the ingress node, 
with SA/DA representing the nodes that are inside the operator domain. 
Therefore, we can say that this new packet (formed by an outer header and 
encapsulated original packet) is now owned by the operator and whatever the 
operator does with this packet:

. The packet MUST leave the operator network in the exact same shape/format 
as it entered (i.e.: outer encapsulation removed).
. The outer header MAY change while in transit in the operator’s domain. 
Moreover, a header MAY be inserted while inside the operator’s domain 
(knowing that outer header and any other inserted header would be removed at 
egress). This means that an SRH MAY be inserted at the same time the outer 
header is added but it can also be that the ingress adds the outer header and 
some other node inserts an SRH (e.g.: fast reroute within operator’s 
infrastructure).
. While in transit, the operator network must handle aspects like MTU 
properly, taking into account the increased size of the packet.
DV: I concur with this explanation & needs.

Originally RFC2460 stated that only the source of the packet is entitled to 
add an EH. Now we’re going to propose that the source “domain” of the packet 
is allowed to insert EHs. The source domain being the set of nodes (including 
the ingress node adding the outer header) under common administration. This 
also implies that when the packet leaves the domain, it must recover its 
original format/shape.

In order to have a more productive discussion, we are writing a draft on 
header insertion that will be submitted as soon as the windows re-open 
(during ietf week).

In the mean time, I think it is way too premature to come to conclusion on 
what text should be used for RFC2460bis and I recommend that the current text 
is left unchanged until we figured out what to do with EH insertion.

DV: I support this recommendation, especially that there will be a document 
submitted in 2 weeks, stated here, that will add more context. Which position 
the WG good discussion.

Thanks.
s.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6(_at_)ietf(_dot_)org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


<Prev in Thread] Current Thread [Next in Thread>