[Snac] Diffs from the SNAC IETF 118 meeting

["Darren Dukes (ddukes)" <[e-mail]>]

Hello working group,

The chairs want to thank everyone for participating in the live document editing session today. Ted and Jonathan did an amazing job editing live and the rest of the group provided impressive collaboration and contribution, we were very happy with how this worked out and hope you are too.

As we promised, the changes produced would be sent to the list for discussion. See below and attached (for side-by-side) The diff was generated from
https://notes.ietf.org/R-tkJFdYSCCWqeBDXMReLQ?view
from:  Thu, Nov 9, 2023 1:30 PM
to: Fri, Nov 10, 2023 4:05 AM
(note, times may be local, they’re not UTC)

We also ask Ted and or Jonathan to generate the associated pull requests (including any further editing necessary) for these changes to get in to the next revision.

Thanks again to everyone for an engaging and very productive working group meeting.

Sincerely
  Darren and Kiran

INTRODUCTION, paragraph 1:
OLD:

# Issues:

NEW:

# SNAC Simple Issues:


INTRODUCTION, paragraph 2:
OLD:

## 1. ~~add a state machine for NAT64 #25~~
For next. Should it be in simple doc?

NEW:

## 1. ~~add a state machine for NAT64 #25~~
For next. Should it be in simple doc?
it is in scope simple.


INTRODUCTION, paragraph 3:
OLD:

## 2. Some points to address from Darren Dukes' review #29
– section 5.2.1 discusses stub router restarts. I assume the two stub routers
are connected to the same AIL and to the same stub network. I also assume the
remembered prefix time includes remembering the prefix... The text doesn’t
state this clearly.

NEW:

Ted: A bridge too far for this meeting.


INTRODUCTION, paragraph 4:
OLD:

## 3. Add restriction that usable prefix must be /64; reference RFC 7084 section 4.3 requirement L-2 #30
section 5.2.3

NEW:

## 2. [x] Some points to address from Darren Dukes' review #29
– section 5.2.1 discusses stub router restarts. I assume the two stub routers are connected to the same AIL and to the same stub network. I also assume the remembered prefix time includes remembering the prefix... The text doesn’t state this clearly.

## 3. [x] Add restriction that usable prefix must be /64; reference RFC 7084 section 4.3 requirement L-2 #30
section 5.2.3


INTRODUCTION, paragraph 6:
OLD:

So that shows why any PIO other than /64 on the Wi-Fi or Ethernet link is not
usable: because a host won't use it for SLAAC.

NEW:

So that shows why any PIO other than /64 on the Wi-Fi or Ethernet link is not usable: because a host won't use it for SLAAC.


INTRODUCTION, paragraph 7:
OLD:

## 4. Relax the requirement on a single 'root' ULA prefix generated by stub router #31
  Section 5.2.2 Current text (-02) has:

NEW:

## 4. [x] Relax the requirement on a single 'root' ULA prefix generated by stub router #31
  Section 5.2.2 Current text (-02) has:


INTRODUCTION, paragraph 8:
OLD:

A stub router MUST allocate a single ULA prefix for use in providing on-link
prefixes to the stub network and the infrastructure network, as needed.

NEW:

A stub router MUST allocate a single ULA prefix for use in providing on-link prefixes to the stub network and the infrastructure network, as needed.


INTRODUCTION, paragraph 9:
OLD:

However, there may be good reasons to deviate from this. Thread for example
uses a generated prefix for the AIL that uses the 64 random bits of the
Extended PAN ID of the Thread Network as the bits for the ULA prefix global ID
and subnet ID. This has the benefit that a more stable ULA prefix is obtained
on the AIL, in the presence of rebooting / changing stub routers.

NEW:

However, there may be good reasons to deviate from this. Thread for example uses a generated prefix for the AIL that uses the 64 random bits of the Extended PAN ID of the Thread Network as the bits for the ULA prefix global ID and subnet ID. This has the benefit that a more stable ULA prefix is obtained on the AIL, in the presence of rebooting / changing stub routers.


INTRODUCTION, paragraph 10:
OLD:

Proposal here is to relax this requirement in some way by allowing a different
(random) ULA prefix for the AIL.

NEW:

Proposal here is to relax this requirement in some way by allowing a different (random) ULA prefix for the AIL.


INTRODUCTION, paragraph 11:
OLD:

>>Conclusion:
Based on email discussion, a conclusion is reached in this message
(https://mailarchive.ietf.org/arch/msg/snac/IDvew688_weuF_ePVxfpEJskxv4/) at
the end.

NEW:

>>Conclusion:
Based on email discussion, a conclusion is reached in this message
(https://mailarchive.ietf.org/arch/msg/snac/IDvew688_weuF_ePVxfpEJskxv4/) at the end.


INTRODUCTION, paragraph 13:
OLD:

Because there can be multiple stub routers on a site (/home), and because each
stub router would automatically and independently pick such a ULA prefix, it's
impossible to get to the situation that the site would employ a single
top-level ULA prefix from which all the stub network prefixes are derived.

NEW:

Because there can be multiple stub routers on a site (/home), and because each stub router would automatically and independently pick such a ULA prefix, it's impossible to get to the situation that the site would employ a single top-level ULA prefix from which all the stub network prefixes are derived.


INTRODUCTION, paragraph 14:
OLD:

So there will be anyway different prefixes in play (at AIL plus stubs) in case
of multiple stub routers on multiple stub networks.

NEW:

So there will be anyway different prefixes in play (at AIL plus stubs) in case of multiple stub routers on multiple stub networks.


INTRODUCTION, paragraph 15:
OLD:

The SHOULD requirement helps to reduce the ULA prefix variation for the case of
a single stub network on the site. I.e. avoid having needless variation.

NEW:

The SHOULD requirement helps to reduce the ULA prefix variation for the case of a single stub network on the site. I.e. avoid having needless variation.


INTRODUCTION, paragraph 16:
OLD:

## 5. Should a stub router learn RA header parameters from other routers? #32

NEW:

> Editorial:
> * don't forget to shoulder every SHOULD with a "unless" clause.
> * imho, the text about (un)partitioning would benefit of having its own sub-section
> [name=Éric Vyncke]

## 5. [x] Should a stub router learn RA header parameters from other routers? #32


INTRODUCTION, paragraph 17:
OLD:

Section 5.1.2.4

NEW:

Section 5.1.2.4
[Lorenzo] per RFC 4861 the host believes the most recently observed flag - linux is known to comply.
[Ted] - three cases - no advertisements on link(except for stub), one advertisment on link, conflicting advertisement on link
[Ted] - New section to describe how RA flags are used (use last that was observed) and how they're constructed (on stub and not)
[ACTION] - Ted or Jonathan to write the section text post-meeting - consider writing a state machine if clear


INTRODUCTION, paragraph 18:
OLD:

However, it's not very clear to me how the host should handle the M flag from
different sources:

NEW:

However, it's not very clear to me how the host should handle the M flag from different sources:


INTRODUCTION, paragraph 19:
OLD:

Use the union of the M flags. That probably means the host thinks there's a
DHCPv6 server on the Wi-FI network.
or
Respect the M flag from the most recently received RA header.

NEW:

Use the union of the M flags. That probably means the host thinks there's a DHCPv6 server on the Wi-FI network.
or
Respect the M flag from the most recently received RA header.


INTRODUCTION, paragraph 21:
OLD:

5.2.2 has currently:

NEW:

[Ted] This needs to be addressed as part of point 5.


INTRODUCTION, paragraph 22:
OLD:

A stub router MUST allocate a single ULA prefix for use in providing on-link
prefixes to the stub network and the infrastructure network, as needed.

NEW:

5.2.2 has currently:


INTRODUCTION, paragraph 23:
OLD:

The "as needed" part here is not so clear and needs to be detailed. E.g.

NEW:

A stub router MUST allocate a single ULA prefix for use in providing on-link prefixes to the stub network and the infrastructure network, as needed.


INTRODUCTION, paragraph 24:
OLD:

only if an on-link prefix on the AIL is not present, the stub router provides
one from its own ULA prefix
only if the stub network does not have an on-link prefix or on-mesh prefix
(whatever applies), then it creates one from its own ULA prefix.
sizes of the involved prefixes? Better to either specify sizes or say it's up
to implementation.
state some randomness requirements - although for the ULA Global ID it may be
clear that it must be randomized; we also have Subnet ID to have requirements
for (or not). In any case state these assumptions.

NEW:

The "as needed" part here is not so clear and needs to be detailed. E.g., only if an on-link prefix on the AIL is not present, the stub router provides one from its own ULA prefix only if the stub network does not have an on-link prefix or on-mesh prefix (whatever applies), then it creates one from its own ULA prefix. sizes of the involved prefixes? Better to either specify sizes or say it's up to implementation.
state some randomness requirements - although for the ULA Global ID it may be clear that it must be randomized; we also have Subnet ID to have requirements for (or not). In any case state these assumptions.


INTRODUCTION, paragraph 26:
OLD:

Based on the original comment:
https://mailarchive.ietf.org/arch/msg/snac/SXIt8RGKYyqDsg41Kucg-qVhIj4/
and the response: https://mailarchive.ietf.org/arch/msg/snac/ZXCDdBUjFn39Vr6sc5lZiEqo4NE/

NEW:

[Ted] This needs to be addressed as part of point 5.

Based on the original comment:
https://mailarchive.ietf.org/arch/msg/snac/SXIt8RGKYyqDsg41Kucg-qVhIj4/
and the response: https://mailarchive.ietf.org/arch/msg/snac/ZXCDdBUjFn39Vr6sc5lZiEqo4NE/


INTRODUCTION, paragraph 28:
OLD:

     - advertising itself as a default router on the AIL;
     - advertising a default route on the AIL.
For correct operation the stub router MUST NOT advertise both of these. While
Section 5.4 has requirements for default router/route advertising on the stub
network, there is no section yet with specific requirements for the AIL side.
This needs to be added.

NEW:

     - advertising itself as a default router on the AIL;
     - advertising a default route on the AIL.
For correct operation the stub router MUST NOT advertise both of these. While Section 5.4 has requirements for default router/route advertising on the stub network, there is no section yet with specific requirements for the AIL side.
This needs to be added.


INTRODUCTION, paragraph 29:
OLD:

## 8. Clarify SNAC solution assumes the IPv6 host on AIL is a Type C Host #35
Section 5.3??

NEW:

## 8. Clarify SNAC solution assumes the IPv6 host on AIL is a Type C Host #35

[Lorenzo] Explicitly say RA Guard will not work with snac unless PD is implemented.
[Darren] sounded like conclusion was Type C works, A and B may not work in all cases and this is OK.

Section 5.3??


INTRODUCTION, paragraph 30:
OLD:

it is clear that the SNAC stub router solution may in some cases not work if
the IPv6 Host on the AIL that needs to send an IPv6 packet to a host on a stub
network is a Type A or Type B Host. In fact, our assumption so far has been
that it is a Type C host.

NEW:

it is clear that the SNAC stub router solution may in some cases not work if the IPv6 Host on the AIL that needs to send an IPv6 packet to a host on a stub network is a Type A or Type B Host. In fact, our assumption so far has been that it is a Type C host.


INTRODUCTION, paragraph 31:
OLD:

Proposal: add clarification that solution scope is intended for Type C hosts on
the AIL. (Though it might work for Type A and B hosts in particular cases, this
is not in our scope.)
Refer to RFC 4191 Section for the 3 host types.

NEW:

Proposal: add clarification that solution scope is intended for Type C hosts on the AIL. (Though it might work for Type A and B hosts in particular cases, this is not in our scope.)
Refer to RFC 4191 Section for the 3 host types.


INTRODUCTION, paragraph 32:
OLD:

## 9. Make all contents of RA sent by stub router explicit, and with rationale #36
  >> This is a case for several stub routers on same AIL.
Based on email discussion:
https://mailarchive.ietf.org/arch/msg/snac/cST1bdMJ7g52nnws0Si71jAF7io/ (lower
part)
It's proposed to make all the elements of the stub router RA explicit,
including rationale for the settings.
This would also include the M / O flag settings of #32

NEW:

## 9. Make all contents of RA sent by stub router explicit, and with rationale #36
[Darren] sounded like this requires the same update in RA section as per item 8

  >> This is a case for several stub routers on same AIL.
Based on email discussion:
https://mailarchive.ietf.org/arch/msg/snac/cST1bdMJ7g52nnws0Si71jAF7io/ (lower part)
It's proposed to make all the elements of the stub router RA explicit, including rationale for the settings. This would also include the M / O flag settings of #32


INTRODUCTION, paragraph 34:
OLD:

     Section 5.2.3 defines the mandatory DHCPv6-PD client role for the stub router.
     However, there are no details here what should trigger the stub router to
     renew/rebind the prefix lease.

NEW:

[Ted] These clarifications should be brought to the DHC working group. Out of scope for stub network doc.
[Darren] Jen noted RFC8415bis last call closes soon, Esko will initiate a thread on this.

     Section 5.2.3 defines the mandatory DHCPv6-PD client role for the stub router.
     However, there are no details here what should trigger the stub router to
     renew/rebind the prefix lease.


INTRODUCTION, paragraph 36:
OLD:

## 11. Review if any of the draft-ietf-v6ops-dhcp-pd-per-device-04 are useful /
applicable to stub router #3

NEW:

## 11. Review if any of the draft-ietf-v6ops-dhcp-pd-per-device-04 are useful /
[Darren] when prefixes change for any reason we need to support that - short lifetimes initially
[Lorenzo/Esko] Mention PD release in the doc.

applicable to stub router #3


Section 5.1., paragraph 2:
OLD:

5.1.1.  Usable On-Link Prefixes

NEW:

5.1.1.  Suitable On-Link Prefixes


Section 5.1., paragraph 3:
OLD:

    IPv6 addressing is considered to be present on the link if a usable
    on-link prefix is advertised on the AIL.  A usable on-link prefix is
    a prefix advertised on the link that has a preferred lifetime of 30
    minutes or more, is marked on-link and allows autonomous
    configuration.

NEW:

    Stub routers must evaluate prefixes that are advertised on-link as to
    their suitability for use in communicating with devices on the stub
    network. If no suitable prefix is found, a stub router MUST advertise
    one.

    An on-link prefix is considered suitable if it is advertised on the link
    in an RA and has
        * a preferred lifetime of 30 minutes or more
        * is marked on-link
        * has a width of 64 bits ([RFC7421], Section 1), and
        * allows autonomous configuration.


Section 5.2.1., paragraph 1:
OLD:

    Stub routers may restart from time to time; when a restart occurs,
    the stub router may have been advertising state to the network which,
    following the restart, is no longer required.

NEW:

Issue: – section 5.2.1 discusses stub router restarts. I assume the two stub routers
are connected to the same AIL and to the same stub network. I also assume the
remembered prefix time includes remembering the prefix... The text doesn’t
state this clearly.

Ted: Text should say we have to remember the prefix and the time.

    Stub routers may restart from time to time; when a restart occurs,
    the stub router may have been advertising state to the network which,
    following the restart, is no longer required.


Section 5.2.1., paragraph 4:
OLD:

    To address this problem, stub routers SHOULD remember the last time a
    prefix was advertised across restarts.  On restart, the router can
    immediately begin deprecating the prefix, and can stop after the
    prefix valid lifetime goes to zero, based on the recorded time that
    the last advertisement was sent.

NEW:

    To address this problem, stub routers SHOULD remember the last time a
    prefix was advertised across restarts.  On restart, the router configures
    the prefix on its interface but does not advertise it in router advertisements.
    Devices that are still using that prefix will be seen as
    on-link to the router, and so packets will be delivered using ND on-link
    rather than forwarded to the default router.


Section 5.2.1., paragraph 5:
OLD:

    When a stub router has only flash memory with limited write lifetime,
    it may be inappropriate to do a write to flash every time an RA
    beacon containing a prefix is sent.  In this case, the router SHOULD
    record the set of prefixes that have been advertised on
    infrastructure and the maximum valid lifetime that was advertised.
    On restart, the router should assume that hosts on the infrastructure
    link have received advertisements for any such prefixes, and should
    immediately deprecate them, and continue to do so until the maximum
    valid lifetime has elapsed after restart.

NEW:

    When a stub router has only flash memory with limited write lifetime,
    it may be inappropriate to do a write to flash every time an RA
    beacon containing a prefix is sent.  In this case, the router SHOULD
    record the set of prefixes that have been advertised on
    infrastructure and the maximum valid lifetime that was advertised.
    On restart, the router should assume that hosts on the infrastructure
    link have received advertisements for any such prefixes.


Section 5.2.1., paragraph 6:
OLD:

    [WG: we could actually just not advertise the prefix, rather than
    deprecating it.  In this case, the host should wind up preferring
    some other prefix for new connections anyway, because it will have a
    later preferred lifetime expiry.  As long as we remember the route
    and resume forwarding for it, existing connections can continue until
    the prefix becomes invalid.

NEW:

    When possible, it is best if all stub routers serving a particular
    stub network use the same prefix on the AIL. For example, Thread stub
    routers use the 40 most significant bits of the Thread Extended PANID
    to generate the ULA prefix. This conforms to RFC4193 because the
    Extended PANID is generated randomly using the same mechanism that is
    specified in RFC4193 for the ULA prefix bits.


Section 5.2.1., paragraph 7:
OLD:

    Further experience with this shows that this solution doesn't work
    well at all.  Ideally the stub routers would all use some identifier
    specific to the stub network to construct the prefix advertised on
    the AIL.  At present Thread uses the Thread "extended PAN ID", which
    is a 64-bit quantity.  Perhaps something like the SSID could be used
    for a WiFi stub network.  I don't think there's a way to specify this
    generally.  But it seems as if the solution proposed here probably
    isn't worth doing.]

NEW:

5.2.2.  Generating a per-stub-router ULA site prefix


Section 5.2.1., paragraph 8:
OLD:

5.2.2.  Generating a ULA prefix to provide addressability

NEW:

    Terminology: stub-router ULA, stub network ULA, ULA site prefix, ULA link prefix


Section 5.2.1., paragraph 9:
OLD:

    In order to be able to provide addressability either on the stub
    network or on an adjacent infrastructure network, a stub router must
    allocate its own ULA prefix.  ULA prefixes, described in Unique Local
    IPv6 Unicast Addresses ([RFC4193]) are randomly allocated prefixes.
    A stub router MUST allocate a single ULA prefix for use in providing
    on-link prefixes to the stub network and the infrastructure network,
    as needed.

NEW:

    Some technologies used for stub networks, for example Thread or 6LoWPAN mesh networks, can
    produce partitioned networks, where what is notionally the same stub
    network winds up looking like two or more discrete links. For mesh
    networks, such partitions can form and rejoin over time as a result of
    either changes in radio propagation or the addition of, or removal
    of, devices on the mesh.

    On stub networks that can partition, one way of detecting that a partition
    has occurred is to notice that the stub router that has advertised the on-link
    prefix for the stub network is no longer reachable. When this occurs, stub
    routers that notice this loss of reachability MUST advertise a ULA link
    prefix derived from their ULA site prefix on the stub network.

    An implication of this is that when such a partition forms, the same
    ULA link (?) prefix can't be advertised on both partitions, since this will
    result in ambiguous routing. We address this problem by requiring that
    each stub router generate its own ULA site prefix. This prefix is then
    available for two purposes: providing addressing on the AIL, if needed,
    and providing addressing on the stub network, if needed.

    A stub router must
    therefore allocate its own ULA site prefix.  ULA prefixes, described in Unique Local
    IPv6 Unicast Addresses ([RFC4193]), are randomly allocated prefixes.
    A stub router MUST allocate a single ULA site prefix for use in providing
    on-link prefixes to the stub network and the infrastructure network,
    as needed.


Section 5.2.1., paragraph 10:
OLD:

    The ULA prefix allocated by a stub router SHOULD be maintained across
    reboots, and SHOULD remain stable over time.  For privacy reasons, a
    stub router that roams from network to network may wish to allocate a
    different ULA prefix each time it connects to a different
    infrastructure network.

NEW:

    The ULA prefix allocated by a stub router SHOULD be maintained across
    reboots, and SHOULD remain stable over time.  (TBD: mention the SHOULD exception cases)
    However, for privacy reasons, a
    stub router that roams from network to network SHOULD allocate a
    different ULA prefix each time it connects to a different
    infrastructure network, unless configured to behave otherwise.