Subject: Re: FW: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt

From: Erik Kline <[email-masked]>
Date: Wed, 21 Jul 2021 14:15:15 -0700

Giuseppe,

I think in S2.1 "MUST NOT" be used outside a "controlled domain" is perhaps
a bit too strong.  Similarly in S6, "MUST be applied in...controlled
domains" might be moderated down to "SHOULD only be applied...".

I'll note that it is possible for an AH option to be used to ensure the
DstOpt variant is unmodified en route, and these two in conjunction can be
used wherever desired to send such packets outside the given domain
(subject, of course, to all the middlebox interference any such
packet would inevitably receive -- but that's a separate issue).

On Tue, Jun 22, 2021 at 11:27 AM Giuseppe Fioccola <
[email-masked]> wrote:

> Dear Stewart, Christopher, Yoshi, All,
> Please note that I just submitted a new version of the draft. It has been
> thoroughly reviewed to address the comments received during the Last Call.
>
> Your inputs are always welcome.
>
> Regards,
>
> Giuseppe
>
> -----Original Message-----
> From: ipv6 <[email-masked]> On Behalf Of [email-masked]
> Sent: Tuesday, June 22, 2021 8:13 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 Maintenance WG of the IETF.
>
>         Title           : IPv6 Application of the Alternate Marking Method
>         Authors         : Giuseppe Fioccola
>                           Tianran Zhou
>                           Mauro Cociglio
>                           Fengwei Qin
>                           Ran Pang
>         Filename        : draft-ietf-6man-ipv6-alt-mark-07.txt
>         Pages           : 21
>         Date            : 2021-06-22
>
> Abstract:
>    This document describes how the Alternate Marking Method can be used
>    as a passive performance measurement tool in an IPv6 domain.  It
>    defines a new Extension Header Option to encode Alternate Marking
>    information in both the Hop-by-Hop Options Header and Destination
>    Options Header.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-alt-mark-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ipv6-alt-mark-07
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Giuseppe Fioccola <[email-masked]>
Date: Thu, 22 Jul 2021 14:08:12 +0000

Hi Erik,
Thanks for the input.
I tend to agree that the condition “MUST” can be changed to “SHOULD”. I can address your comments in the -08 version.

Regards,

Giuseppe

From: Erik Kline <[email-masked]>
Sent: Wednesday, July 21, 2021 11:15 PM
To: Giuseppe Fioccola <[email-masked]>
Cc: Stewart Bryant <[email-masked]>; Christopher Wood <[email-masked]>; Yoshifumi Nishida <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: FW: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt

Giuseppe,

I think in S2.1 "MUST NOT" be used outside a "controlled domain" is perhaps a bit too strong.  Similarly in S6, "MUST be applied in...controlled domains" might be moderated down to "SHOULD only be applied...".

I'll note that it is possible for an AH option to be used to ensure the DstOpt variant is unmodified en route, and these two in conjunction can be used wherever desired to send such packets outside the given domain (subject, of course, to all the middlebox interference any such packet would inevitably receive -- but that's a separate issue).

On Tue, Jun 22, 2021 at 11:27 AM Giuseppe Fioccola <[email-masked]<mailto:[email-masked]>> wrote:
Dear Stewart, Christopher, Yoshi, All,
Please note that I just submitted a new version of the draft. It has been thoroughly reviewed to address the comments received during the Last Call.

Regards,

Giuseppe

-----Original Message-----
From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, June 22, 2021 8:13 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance WG of the IETF.

Abstract:

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 22 Jul 2021 15:43:18 +0100

HI,

Later in the text in section 6 (security) it says

As stated above, the precondition for the application of the
   Alternate Marking is that it MUST be applied in specific controlled
   domains, thus confining the potential attack vectors within the
   network domain. 

If section 2 text is weaked, it both contradicts and weakens the security assumptions.

I suppose you could say that authentication MUST be used if the protocol is deployed outside a controlled domain, but I don’t think you can let it run in the wild as is.

- Stewart

> On 22 Jul 2021, at 15:08, Giuseppe Fioccola <[email-masked]> wrote:
> 
> Hi Erik,
> Thanks for the input.
> From: Erik Kline <[email-masked] <mailto:[email-masked]>> 
> To: Giuseppe Fioccola <[email-masked] <mailto:[email-masked]>>
> Cc: Stewart Bryant <[email-masked] <mailto:[email-masked]>>; Christopher Wood <[email-masked] <mailto:[email-masked]>>; Yoshifumi Nishida <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> On Tue, Jun 22, 2021 at 11:27 AM Giuseppe Fioccola <[email-masked] <mailto:[email-masked]>> wrote:
> From: ipv6 <[email-masked] <mailto:[email-masked]>> On Behalf Of [email-masked] <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
> https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/ <https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/>
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-alt-mark-07 <https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-alt-mark-07>
> 
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ipv6-alt-mark-07 <https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ipv6-alt-mark-07>
> 
> 
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> 
> 
> [email-masked] <mailto:[email-masked]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: Mike Simpson <[email-masked]>
Date: Fri, 23 Jul 2021 08:35:54 +0100

Why not just keep it at MUST so that you don’t pollute the internets. 

We will end up having to filter for it anyway as always but it seems foolhardy and unpleasant to intentionally weaken the language. 

Your new hotness belongs in your controlled domain. If you are going to try and force it onto networks you don’t control then it’s not going to work and you will end up having to tunnel it anyways. 

Why is this so hard to understand?

> On 22 Jul 2021, at 15:09, Giuseppe Fioccola <[email-masked]> wrote:
> 
> 
> Hi Erik,
> Thanks for the input.
> On Tue, Jun 22, 2021 at 11:27 AM Giuseppe Fioccola <[email-masked]> wrote:

---

From: Giuseppe Fioccola <[email-masked]>
Date: Fri, 23 Jul 2021 08:05:17 +0000

Hi Stewart,
Yes, my intention is to specify that, if it is needed to apply the Alternate Marking outside a controlled domain (e.g. e2e service monitoring) authentication MUST necessarily be used.
Regards,

Giuseppe

From: Stewart Bryant <[email-masked]>
Sent: Thursday, July 22, 2021 4:43 PM
To: Giuseppe Fioccola <[email-masked]>
Cc: Stewart Bryant <[email-masked]>; Erik Kline <[email-masked]>; Christopher Wood <[email-masked]>; Yoshifumi Nishida <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt

HI,

   network domain.

- Stewart

On 22 Jul 2021, at 15:08, Giuseppe Fioccola <[email-masked]<mailto:[email-masked]>> wrote:

Hi Erik,
Thanks for the input.

Regards,

Giuseppe

From: Erik Kline <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, July 21, 2021 11:15 PM
To: Giuseppe Fioccola <[email-masked]<mailto:[email-masked]>>
Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; Christopher Wood <[email-masked]<mailto:[email-masked]>>; Yoshifumi Nishida <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: FW: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt

Giuseppe,

Regards,

Giuseppe

-----Original Message-----
From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, June 22, 2021 8:13 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt

Abstract:

---

From: Giuseppe Fioccola <[email-masked]>
Date: Fri, 23 Jul 2021 08:19:25 +0000

Hi Mike,
To avoid misunderstanding, the precondition of controlled domain may be kept as MUST. We can further specify that authentication MUST be used if, for specific scenarios, it is applied outside a controlled domain.

Regards,

Giuseppe

From: Mike Simpson <[email-masked]>
Sent: Friday, July 23, 2021 9:36 AM
To: Giuseppe Fioccola <[email-masked]>
Cc: Erik Kline <[email-masked]>; Yoshifumi Nishida <[email-masked]>; [email-masked]; Christopher Wood <[email-masked]>; [email-masked]
Subject: Re: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt

On 22 Jul 2021, at 15:09, Giuseppe Fioccola <[email-masked]<mailto:[email-masked]>> wrote:

Hi Erik,
Thanks for the input.

Regards,

Giuseppe

Giuseppe,

Regards,

Giuseppe

-----Original Message-----
From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, June 22, 2021 8:13 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt

Abstract:

---

From: Mark Smith <[email-masked]>
Date: Sat, 24 Jul 2021 09:00:05 +1000

On Fri, 23 Jul 2021, 18:20 Giuseppe Fioccola, <[email-masked]>
wrote:

> Hi Mike,
>
> To avoid misunderstanding, the precondition of controlled domain may be
> kept as MUST. We can further specify that authentication MUST be used if,
> for specific scenarios, it is applied outside a controlled domain.
>

Realise that a "MUST be limited to a controlled domain" in an RFC is
nothing more than an aspiration. It's theory rather than reality.

Packets are encouraged to try to exit "controlled" domains attached to the
Internet due to the domain's default route, and then can leave the
controlled domain ("leak") due failure of the controlling boundary because
of implementation bugs, operator configuration error or partial node
failure.

Authentication must be a MUST for anything that is designed for a
controlled domain if the controlled domain may be attached to the Internet,
which is a possibility for any of them if they use IPv6.

Packets getting to where they shouldn't would be one of the motivations of
Postel's "Be conservative with what you send".

Regards,
Mark.

>
> Regards,
>
>
>
> Giuseppe
>
>
>
>
>
> *From:* Mike Simpson <[email-masked]>
> *Sent:* Friday, July 23, 2021 9:36 AM
> *To:* Giuseppe Fioccola <[email-masked]>
> *Cc:* Erik Kline <[email-masked]>; Yoshifumi Nishida <
> [email-masked]>; [email-masked]; Christopher Wood <[email-masked]>;
> [email-masked]
> *Subject:* Re: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt
>
>
>
> We will end up having to filter for it anyway as always but it seems
> foolhardy and unpleasant to intentionally weaken the language.
>
>
>
> Your new hotness belongs in your controlled domain. If you are going to
> try and force it onto networks you don’t control then it’s not going to
> work and you will end up having to tunnel it anyways.
>
>
>
> I tend to agree that the condition “MUST” can be changed to “SHOULD”. I
> can address your comments in the -08 version.
>
>
>
> Regards,
>
>
>
> Giuseppe
>
>
>
> *From:* Erik Kline <[email-masked]>
> *Sent:* Wednesday, July 21, 2021 11:15 PM
> *To:* Giuseppe Fioccola <[email-masked]>
> *Cc:* Stewart Bryant <[email-masked]>; Christopher Wood <
> [email-masked]>; Yoshifumi Nishida <[email-masked]>;
> [email-masked]; [email-masked]
> *Subject:* Re: FW: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt
>
>
>
> Giuseppe,
>
>
>
> I think in S2.1 "MUST NOT" be used outside a "controlled domain" is
> perhaps a bit too strong.  Similarly in S6, "MUST be applied
> in...controlled domains" might be moderated down to "SHOULD only be
> applied...".
>
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Sat, 24 Jul 2021 10:39:47 +0100

All of which is why MPLS or some evolution therefore is a better approach to providing a packet transport network (or other controlled domain). The operator of an MPLS network has complete control over the separation of the user traffic and their infrastructure traffic.

It is going to be really interesting to see whether SRv6 triumphs or crashes out because of the difficulty of providing the degree of traffic separation that is intrinsic to  MPLS.

- Stewart

> On 24 Jul 2021, at 00:00, Mark Smith <[email-masked]> wrote:
> 
> 
> 
> On Fri, 23 Jul 2021, 18:20 Giuseppe Fioccola, <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Mike,
> 
> Realise that a "MUST be limited to a controlled domain" in an RFC is nothing more than an aspiration. It's theory rather than reality.
> 
> Packets are encouraged to try to exit "controlled" domains attached to the Internet due to the domain's default route, and then can leave the controlled domain ("leak") due failure of the controlling boundary because of implementation bugs, operator configuration error or partial node failure.
> 
> Authentication must be a MUST for anything that is designed for a controlled domain if the controlled domain may be attached to the Internet, which is a possibility for any of them if they use IPv6.
> 
> Packets getting to where they shouldn't would be one of the motivations of Postel's "Be conservative with what you send".
> 
> 
> Regards,
> Mark.
> 
> 
>  
> 
> Regards,
> 
>  
> 
> Giuseppe
> 
>  
> 
>  
> 
> From: Mike Simpson <[email-masked] <mailto:[email-masked]>> 
> Cc: Erik Kline <[email-masked] <mailto:[email-masked]>>; Yoshifumi Nishida <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Christopher Wood <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On 22 Jul 2021, at 15:09, Giuseppe Fioccola <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
> Hi Erik,
> 
> Thanks for the input.
>

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 26 Jul 2021 08:05:40 +0000

Hi Mark,
I agree. In an RFC the conservative approach must be recommended.
Regards,

Giuseppe

-----Original Message-----
From: Mark Smith <[email-masked]> 
Sent: Saturday, July 24, 2021 1:00 AM
To: Giuseppe Fioccola <[email-masked]>
Cc: Mike Simpson <[email-masked]>; Yoshifumi Nishida <[email-masked]>; 6MAN <[email-masked]>; Christopher Wood <[email-masked]>; [email-masked]
Subject: Re: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt

On Fri, 23 Jul 2021, 18:20 Giuseppe Fioccola, <[email-masked]>
wrote:

> Hi Mike,
>
> To avoid misunderstanding, the precondition of controlled domain may 
> be kept as MUST. We can further specify that authentication MUST be 
> used if, for specific scenarios, it is applied outside a controlled domain.
>

Regards,
Mark.

> [email-masked]>; [email-masked]; Christopher Wood 
> <[email-masked]>; [email-masked]
> Your new hotness belongs in your controlled domain. If you are going 
> to try and force it onto networks you don’t control then it’s not 
> going to work and you will end up having to tunnel it anyways.
>
>
>
> On 22 Jul 2021, at 15:09, Giuseppe Fioccola 
> <[email-masked]>
> wrote:
>
> 
>
> Hi Erik,
>
> Thanks for the input.
>
> I tend to agree that the condition “MUST” can be changed to “SHOULD”. 
> I can address your comments in the -08 version.
>
>
>
> Regards,
>
>
>
> Giuseppe
>
>
>
> I'll note that it is possible for an AH option to be used to ensure 
> the DstOpt variant is unmodified en route, and these two in 
> conjunction can be used wherever desired to send such packets outside 
> the given domain (subject, of course, to all the middlebox 
> interference any such packet would inevitably receive -- but that's a separate issue).
>
>
>
> Dear Stewart, Christopher, Yoshi, All, Please note that I just 
> submitted a new version of the draft. It has been thoroughly reviewed 
> to address the comments received during the Last Call

---

From: Mark Smith <[email-masked]>
Date: Thu, 29 Jul 2021 18:56:43 +1000

Hi Stewart,

> It is going to be really interesting to see whether SRv6 triumphs or crashes out because of the difficulty of providing the degree of traffic separation that is intrinsic to  MPLS.

It has seemed to me that what is really missing is a general purpose
local network limited protocol, "larger" than a link-layer protocol,
yet "smaller" than a global internetworking protocol.

IPv6 is really too "big" for SR. The IPv6 overhead is because of the
128 bit addresses, and they're that large because it is a global
internetworking protocol that has to be able to uniquely address every
node on the internetwork.

It makes sense to try to use IPv6 for SR, since IPv6 is a future
commodity protocol, however as it is "too large", there are then hacks
like EH insertion or the SID compression proposals to try to get
around the fundamental problem of using a protocol that isn't really a
good enough fit for a local network problem and a solution like SR.

MPLS is a local network protocol. Fine for use "inside the network"
and something like SR.

However I think it would be useful if we had a more general purpose
local network protocol that is also well suited for use by hosts, and
that, for example, transport layer protocols like UDP or TCP could be
placed directly inside.

I've idly wondered if we could repurpose IPv4 for that by giving it a
new version number. It's now too small to be a global internetworking
protocol, however would still be large enough to solve a local network
problem. It just needs to be distinguished from the legacy use of IPv4
as a global Internet protocol.

It would be preferable though for a local network protocol to have
addresses large enough to be so that there can be likely globally
unique subnets, so that merging networks doesn't require renumbering
or NAT. I wonder if 64 bit addresses, 32 bits Global ID (similar to
ULA 48 bit ID), 16 bits subnets and 16 bits host addresses would be
good enough.

Regards,
Mark.

> On Fri, 23 Jul 2021, 18:20 Giuseppe Fioccola, <[email-masked]> wrote:
>>
>> Hi Mike,
>>

---

From: Brian Carpenter <[email-masked]>
Date: Thu, 29 Jul 2021 22:32:10 +1200

I think IPv6 with smaller addresses would be a better approach, and there
have been various proposals that amount to that.

Regards,
    Brian Carpenter
    (via tiny screen & keyboard)

On Thu, 29 Jul 2021, 20:57 Mark Smith, <[email-masked]> wrote:

> > All of which is why MPLS or some evolution therefore is a better
> approach to providing a packet transport network (or other controlled
> domain). The operator of an MPLS network has complete control over the
> separation of the user traffic and their infrastructure traffic.
> >
> > It is going to be really interesting to see whether SRv6 triumphs or
> crashes out because of the difficulty of providing the degree of traffic
> separation that is intrinsic to  MPLS.
> >
>
> > Packets are encouraged to try to exit "controlled" domains attached to
> the Internet due to the domain's default route, and then can leave the
> > Packets getting to where they shouldn't would be one of the motivations
> of Postel's "Be conservative with what you send".
> >
> >
> > Regards,
> > Mark.
> >
> >
> >>
> >>
> >> Regards,
> >>
> >>
> >>
> >> Giuseppe
> >>
> >>
> >>
> >>
> >>
> >> Cc: Erik Kline <[email-masked]>; Yoshifumi Nishida <
> >> Cc: Stewart Bryant <[email-masked]>; Christopher Wood <
> (subject, of course, to all the middlebox interference any such packet
> would inevitably receive -- but that's a separate issue).
> >>
> >>
> >>
> >> Please note that I just submitted a new version of the draft. It has
> been thoroughly reviewed to address the comments received during the Last
> Call.
> >>

---

From: Haoyu Song <[email-masked]>
Date: Thu, 29 Jul 2021 16:27:20 +0000

Hi Mark,

Here's a proposal to use short address at edge network which is also interoperable with IPv4/v6 networks through a protocol translation gateway. I think this meet your requirements. Any comments are welcome! 
https://datatracker.ietf.org/doc/html/draft-song-ship-edge-01

Best regards,
Haoyu

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Mark Smith
Sent: Thursday, July 29, 2021 1:57 AM
To: Stewart Bryant <[email-masked]>
Cc: Yoshifumi Nishida <[email-masked]>; 6MAN <[email-masked]>; Christopher Wood <[email-masked]>; [email-masked]
Subject: Re: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt

Hi Stewart,

> It is going to be really interesting to see whether SRv6 triumphs or crashes out because of the difficulty of providing the degree of traffic separation that is intrinsic to  MPLS.

It has seemed to me that what is really missing is a general purpose local network limited protocol, "larger" than a link-layer protocol, yet "smaller" than a global internetworking protocol.

IPv6 is really too "big" for SR. The IPv6 overhead is because of the
128 bit addresses, and they're that large because it is a global internetworking protocol that has to be able to uniquely address every node on the internetwork.

It makes sense to try to use IPv6 for SR, since IPv6 is a future commodity protocol, however as it is "too large", there are then hacks like EH insertion or the SID compression proposals to try to get around the fundamental problem of using a protocol that isn't really a good enough fit for a local network problem and a solution like SR.

However I think it would be useful if we had a more general purpose local network protocol that is also well suited for use by hosts, and that, for example, transport layer protocols like UDP or TCP could be placed directly inside.

I've idly wondered if we could repurpose IPv4 for that by giving it a new version number. It's now too small to be a global internetworking protocol, however would still be large enough to solve a local network problem. It just needs to be distinguished from the legacy use of IPv4 as a global Internet protocol.

It would be preferable though for a local network protocol to have addresses large enough to be so that there can be likely globally unique subnets, so that merging networks doesn't require renumbering or NAT. I wonder if 64 bit addresses, 32 bits Global ID (similar to ULA 48 bit ID), 16 bits subnets and 16 bits host addresses would be good enough.

Regards,
Mark.

>> Cc: Erik Kline <[email-masked]>; Yoshifumi Nishida 
>> <[email-masked]>; [email-masked]; Christopher Wood 
>> Cc: Stewart Bryant <[email-masked]>; Christopher Wood 
>> <[email-masked]>; Yoshifumi Nishida <[email-masked]>; 
>> submitted a new version of the draft. It has been thoroughly reviewed to address the comments received during the Last Call.
>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat
>> atracker.ietf.org%2Fdoc%2Fdraft-ietf-6man-ipv6-alt-mark%2F&amp;data=0
>> 4%7C01%7Chaoyu.song%40futurewei.com%7C359e935f6d03494a32b208d9526eeba
>> 7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637631458627527659%7CU
>> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
>> aWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=oFwfz1crfbLfjdJW%2F8eH8pEIQqAbsef
>> eh4pdVqVUhTM%3D&amp;reserved=0
>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat
>> atracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-6man-ipv6-alt-mark-07&amp
>> ;data=04%7C01%7Chaoyu.song%40futurewei.com%7C359e935f6d03494a32b208d9
>> 526eeba7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637631458627527
>> 659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
>> iI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=ZqFVo2EbtVhpHeHn4jYn882Hw9
>> 9mK5OIPhmZrZyJBnA%3D&amp;reserved=0
>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-6man-ipv6-alt-mark-07&amp;dat
>> a=04%7C01%7Chaoyu.song%40futurewei.com%7C359e935f6d03494a32b208d9526e
>> eba7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637631458627527659%
>> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
>> k1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Z9imcT6yNLTU71wsg9jyRcdTLDN2yV
>> pgr1EkxYmS9ho%3D&amp;reserved=0
>>
>>
>> https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.i
>> etf.org%2Finternet-drafts%2F&amp;data=04%7C01%7Chaoyu.song%40futurewe
>> i.com%7C359e935f6d03494a32b208d9526eeba7%7C0fee8ff2a3b240189c753a1d55
>> 91fedc%7C1%7C1%7C637631458627527659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
>> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;
>> sdata=4ZrzQKJtrdx5ALmtINX5C490fxe7X9QLLTEuoKTPIns%3D&amp;reserved=0
>>
>>
>> Administrative Requests: 
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=04%7C01%7Chaoyu.song%4
>> 0futurewei.com%7C359e935f6d03494a32b208d9526eeba7%7C0fee8ff2a3b240189
>> c753a1d5591fedc%7C1%7C1%7C637631458627537616%7CUnknown%7CTWFpbGZsb3d8
>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
>> 3000&amp;sdata=cisGRoCFR8CYG%2FyxuusQJai1DLAllLr4XiRasMzNCuA%3D&amp;r
>> eserved=0
>> Administrative Requests: 
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=04%7C01%7Chaoyu.song%4
>> 0futurewei.com%7C359e935f6d03494a32b208d9526eeba7%7C0fee8ff2a3b240189
>> c753a1d5591fedc%7C1%7C1%7C637631458627537616%7CUnknown%7CTWFpbGZsb3d8
>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
>> 3000&amp;sdata=cisGRoCFR8CYG%2FyxuusQJai1DLAllLr4XiRasMzNCuA%3D&amp;r
>> eserved=0
>> Administrative Requests: 
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=04%7C01%7Chaoyu.song%4
>> 0futurewei.com%7C359e935f6d03494a32b208d9526eeba7%7C0fee8ff2a3b240189
>> c753a1d5591fedc%7C1%7C1%7C637631458627537616%7CUnknown%7CTWFpbGZsb3d8
>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
>> 3000&amp;sdata=cisGRoCFR8CYG%2FyxuusQJai1DLAllLr4XiRasMzNCuA%3D&amp;r
>> eserved=0
> Administrative Requests: 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=04%7C01%7Chaoyu.song%40f
> uturewei.com%7C359e935f6d03494a32b208d9526eeba7%7C0fee8ff2a3b240189c75
> 3a1d5591fedc%7C1%7C1%7C637631458627537616%7CUnknown%7CTWFpbGZsb3d8eyJW
> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&
> amp;sdata=cisGRoCFR8CYG%2FyxuusQJai1DLAllLr4XiRasMzNCuA%3D&amp;reserve
> d=0

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C359e935f6d03494a32b208d9526eeba7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637631458627537616%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=cisGRoCFR8CYG%2FyxuusQJai1DLAllLr4XiRasMzNCuA%3D&amp;reserved=0
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Jul 2021 07:44:30 +1200

Amplifying my comment now that I'm on a computer not a phone:

For example, https://www.ietf.org/archive/id/draft-li-native-short-addresses-01.html

Regards
   Brian
On 29-Jul-21 22:32, Brian Carpenter wrote:
> I think IPv6 with smaller addresses would be a better approach, and there have been various proposals that amount to that.
> 
> Regards,
>     Brian Carpenter
> On Thu, 29 Jul 2021, 20:57 Mark Smith, <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Stewart,
> 
>     On Sat, 24 Jul 2021 at 19:39, Stewart Bryant <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     > It is going to be really interesting to see whether SRv6 triumphs 
or crashes out because of the difficulty of providing the degree of traffic separation that is intrinsic to  MPLS.
>     > On 24 Jul 2021, at 00:00, Mark Smith <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     >
>     >
>     >> To avoid misunderstanding, the precondition of controlled domain 
may be kept as MUST. We can further specify that authentication MUST be used if, for specific scenarios, it is applied outside a controlled domain.
>     >
>     >
>     > Realise that a "MUST be limited to a controlled domain" in an RFC 
is nothing more than an aspiration. It's theory rather than reality.
>     > Authentication must be a MUST for anything that is designed for a 
controlled domain if the controlled domain may be attached to the Internet, which is a possibility for any of them if they use IPv6.
>     >> I tend to agree that the condition “MUST” can be 
changed to “SHOULD”. I can address your comments in the -08 version.
>     >> I think in S2.1 "MUST NOT" be used outside a "controlled domain" 
is perhaps a bit too strong.  Similarly in S6, "MUST be applied in...controlled domains" might be moderated down to "SHOULD only be applied...".
>     >> Please note that I just submitted a new version of the draft. It 
has been thoroughly reviewed to address the comments received during the Last Call.
>     >>         Title        
   : IPv6 Application of the Alternate Marking Method
>     >>         Pages        
   : 21
>     >>         Date        
    : 2021-06-22
>     >> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
<https://www.ietf.org/mailman/listinfo/ipv6>