[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: [IPv6] [EXTERNAL] Re: Comments on draft-ietf-6man-hbh-processing-12
From:       "Templin \(US\), Fred L" <Fred.L.Templin=40boeing.com () dmarc ! ietf ! org>
Date:       2023-11-29 22:22:59
Message-ID: 14a04071008448e2a123190d6ab505ab () boeing ! com
[Download RAW message or body]

Tom, good point - RFC9286 and RFC9486 makes two HBH options that have been published
relatively recently which were presumably intended for practical purposes (note the similar
document numbers as a matter of "IETF coincidence" also). I don't mind having limited
domain applicability for the short term, but would not want to preclude broader applicability
in the future as more and more routers begin to recognize and properly handle certain HBH
options.

Fred

> -----Original Message-----
> From: Tom Herbert <tom@herbertland.com>
> Sent: Wednesday, November 29, 2023 2:07 PM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: 6man <ipv6@ietf.org>
> Subject: [EXTERNAL] Re: [IPv6] Comments on draft-ietf-6man-hbh-processing-12
> 
> EXT email: be mindful of links/attachments.
> 
> 
> 
> On Wed, Nov 29, 2023 at 1:31 PM Templin (US), Fred L
> <Fred.L.Templin@boeing.com> wrote:
> >
> > Tom,
> >
> > > this topic). My conclusion wrt Hop-by-Hop Options is that most likely
> > > they'll only ever be productively used in limited domains. Even so,
> > > this draft is still important even if it's intent is to make HBH "more
> > > practical to use Hop-by-Hop options beyond such a single domain"
> >
> > RFC9268 was published not terribly long ago and specifies a HBH option
> > that I think was intended to be used beyond just a limited domain. Surely
> > that HBH option (and others like it) should be accommodated as broadly
> > as possible, right?
> 
> Fred,
> 
> It's a statement of practicality. The APNIC data indicates that the
> drop rate of Hop-by-Hop Options in the Internet is >99%. I believe
> this is a security policy where a network provider drops packets with
> HBH on ingress to their network since they target not just the
> destination host but also routers in their network infrastructure
> which make them a possible risk to the infrastructure. Given the
> apparent pervasiveness of this policy, I think it's going to be very
> difficult to undo this policy especially in the absence of having any
> globally useful Hop-by-Hop options. While RFC9268 could be used across
> the Internet, I'm not sure I would trust the information if it was
> being set by an anonymous router outside of my hosts's local domain
> (it's similar to how no one seems to trust ICMP errors coming into
> their network).
> 
> Within a limited domain, the story is very different. HBH options like
> IOAM are deployable and beneficial, and the security aspects are more
> manageable. I think HBH could flourish in limited domains, and there's
> always the possibility of connected providers to accept HBH options
> across the boundary thereby increasing the scope of limited domains.
> 
> Tom
> 
> 
> 
> >
> > Thank you - Fred
> >
> > > -----Original Message-----
> > > From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Tom Herbert
> > > Sent: Wednesday, November 29, 2023 9:18 AM
> > > To: 6man <ipv6@ietf.org>
> > > Subject: [IPv6] Comments on draft-ietf-6man-hbh-processing-12
> > >
> > > Hi,
> > >
> > > I have some comments in the draft...
> > >
> > > I recommend changing "Source"- to "source host" or adding term Source
> > > in the Terminology section
> > >
> > > >From the draft: "Source creating packets with a Hop-by-Hop Options
> > > header SHOULD use a method that is robust to network nodes processing
> > > only the first Hop-by-Hop option that is included in the packet
> > >
> > > I'm not sure what this means in terms of a "method that is robust". In
> > > both this draft and eh-limits it's specified that routers can choose
> > > to process 0, 1, or N consecutive options. I think that maybe the
> > > intent is that the host SHOULD assume that the most likely option to
> > > be processed is the first one and prioritize how it orders the list of
> > > options accordingly (mentioned in text below but maybe that should be
> > > the SHOULD).
> > >
> > > "A Source MAY, based on local configuration, include more than one
> > > Hop-by-Hop option [I-D.ietf-6man-eh-limits], but might wish to
> > > restrict the size to increase the likelihood of successful transfer
> > > across a network path."
> > >
> > > Could this be a "A source host SHOULD abide by the limits in Section 3
> > > of [I-D.ietf-6man-eh-limits] for sending Hop-by-Hop extension headers
> > > and options"
> > >
> > > "A router MUST NOT be configured to support the Hop-by-Hop Option
> > > header if it cannot process the first Hop-by-Hop option at full
> > > forwarding rate. If configured to do so, a router SHOULD process
> > > additional Hop-by-Hop options providing that these also can be
> > > processed at the full forwarding rate."
> > >
> > > This seems rather complex and it's unclear to me why the first option
> > > needs to be singled out as being special. Why no just say:
> > >
> > > "A router MUST process Hop-by-Hops at full forwarding rate. If a
> > > router encounters an option that it cannot process at full-forwarding
> > > rate then the option should be skipped per the procedures below"
> > >
> > > >From the draft: "If a router is unable to process any Hop-by-Hop
> > > option (or is not configured to do so), it SHOULD behave in the way
> > > specified for an unrecognized Option Type when the action bits were
> > > set to "00"."
> > >
> > > This effectively changes the semantics of options that are not 00 to
> > > be skippable. That might be a problem if there are two options in a
> > > packet with type 01 where the second might have a dependency on the
> > > first, so if the first is skipped, but the second is processed could
> > > lead to non-deterministic results. I suggest that if an option that is
> > > not 00 isn't processed, HBH processing should stop at that point and
> > > the rest of the options should be skipped.
> > >
> > > >From draft: "The size of a Hop-by-Hop option SHOULD NOT extend beyond
> > > what can be expected to be executed at full forwarding rate.". This is
> > > pretty ambiguous, I suggest referencing eh-limits which gives
> > > requirements for both what hosts can send and what receivers need to
> > > process. Per that, draft new Hop-by-Hop options should have a data
> > > length  less than or equal to 60 bytes as a baseline. There's a lot of
> > > factors, maybe we should just advise those designing new options to
> > > try to keep them compact as much as possible
> > >
> > > "From the draft: New Hop-by-Hop options SHOULD be designed expecting
> > > that a router might be configured to only process a subset of
> > > Hop-by-Hop options (e.g., the first) in the Hop-by-Hop Options
> > > header."
> > >
> > > Maybe this is equivalent to saying new options should be idempotent
> > > with any other options
> > >
> > > Instead of "In a controlled domain" maybe "limited domain" since that
> > > seems to be more typical (RFC8799)?
> > >
> > > >From the draft: "For example, an application can be designed to first
> > > send a test packet that includes the required option, or combination
> > > of options, and sends other packets without including the option.  The
> > > application then does not send additional packets that include this
> > > option (or set of options) until the test packet(s) is acknowledged."
> > >
> > > So this is a type of Happy EyeBalls for Hop-by-Hop Options? I've
> > > thought about this a lot and I believe that it would be a major effort
> > > to implement and make it robust (we'd probably need a draft just on
> > > this topic). My conclusion wrt Hop-by-Hop Options is that most likely
> > > they'll only ever be productively used in limited domains. Even so,
> > > this draft is still important even if it's intent is to make HBH "more
> > > practical to use Hop-by-Hop options beyond such a single domain"
> > >
> > > >From the draft "The document limited the default number of Hop-by-Hop
> > > options that can be included in a packet to a single Hop-by-Hop
> > > option."
> > >
> > > This contradicts eh-limits where the default number is 8. Note that
> > > since routers can have their own limits on how many options they
> > > process (0, 1, ...N), increasing the number of options shouldn't
> > > increase the probability of drops by routers (they just ignore options
> > > beyond their local limit), Also, a default of one very much limits
> > > future extensibility and it seems like this is more of BCP type value
> > > rather than an protocol protocol limit. I suggest removing this
> > > default here and just reference eh-limits.
> > >
> > > Tom
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf.org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> >

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread]