Re: [Last-Call] Secdir last call review of draft-ietf-6man-sids-03

[Suresh Krishnan <suresh.krishnan@xxxxxxxxx>]

Hi Linda,

  Thanks again. Please find responses inline.

On Oct 30, 2023, at 12:39 PM, Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx> wrote:

Suresh, 

 

Thank you for the explanation. 

 

See my comments & questions added below:

 

Linda

-----Original Message-----
From: Suresh Krishnan <suresh.krishnan@xxxxxxxxx> 
Sent: Thursday, October 26, 2023 9:54 AM
To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>
Cc: secdir@xxxxxxxx; draft-ietf-6man-sids.all@xxxxxxxx; ipv6@xxxxxxxx; last-call@xxxxxxxx
Subject: Re: Secdir last call review of draft-ietf-6man-sids-03

 

Hi Linda,

  Thanks a lot for your review. Please find responses inline.

 

 

> On Oct 25, 2023, at 4:38 PM, Linda Dunbar via Datatracker <noreply@xxxxxxxx> wrote:

> 

> Reviewer: Linda Dunbar

> Review result: Not Ready

> 

> I have reviewed this document as part of the security directorate's 

> ongoing effort to review all IETF documents being processed by the 

> IESG. These comments were written primarily for the benefit of the 

> security area directors. Document editors and WG chairs should treat 

> these comments just like any other last call comments.

> 

> Summary: this document is intended to clarify the relationship of SRv6 

> SIDs to the IPv6 Addressing Architecture.

> 

> Major issue:

> The document explains the SRv6 SID characteristics very well, which 

> was the repeat of RFC8754. As the SRv6 SID is the same as the IPv6 

> address, the document fails to explain if there are any forwarding 

> behavior differences on the  non-SRv6 capable intermediate nodes. As 

> the intermediate SRv6 nodes use the next SID (a standard IPv6 address) 

> as the packet's outer destination, does it mean that those non-SRv6 

> intermediate nodes forward the packets the same as before?

 

Yes. For the non-SRv6 intermediate nodes (“transit nodes”) the forwarding behavior is as specified in [BCP198] and described further in Section 3.

 

> If Yes, why need this document?

 

This document describes how SRv6 SIDs are structured and how this structure is different from RFC4291. The fact that the SRv6 SIDs do not affect non-SRv6 transit nodes is by design and a key fact to be emphasized. The transit nodes treat them as any IPv6 destination addresses performing a longest prefix match as usual. Please let me know if you would like me to clarify any of the text in Section 3.

 

[Linda] It would be very helpful to add the following explanation to Section 3:

• When both SRH and IPv6 Hop-by-hop Extension header are present in the packet, does the intermediate nodes process the Hop-by-Hop header in the same way as if there is no SRH? 

As per RFC8200 the Hop-by-hop option header (if it is present) needs to occur right after the IPv6 header. So no difference due to the presence of the SRH.

• There are lots of studies showing that IPv6 packets with Extension Headers tend to be dropped in the network. Does it happen to IPv6 packets with SRH?

Since SRH is intended to be used inside SR Domains [RFC8402] I would assume that this will not happen, but I am unsure as to how this is relevant to this draft. I think maybe a good discussion to have in spring regarding the operational considerations of SRH.

• If IPv6 addresses not compliant with the requirement set forth in RFC4291 get forwarded without error, why need the requirements of RFC4291? 

RFC4291 defines requirements for addresses that are assigned on interfaces. This draft solely deals with the other case. For addresses that need to be assigned on interfaces RFC4291 does apply as stated in Section 3:

"As stated above, the non-SRv6-SID elements that appear in the SRH SID list are simply IPv6 addresses assigned to local interfaces and they need to conform to [RFC4291]"

Thanks

Suresh

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call