Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

Andrew Alston <Andrew.Alston@liquidtelecom.com> Sun, 01 March 2020 02:27 UTC

Return-Path: <andrew.alston@liquidtelecom.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240AF3A1803 for <int-area@ietfa.amsl.com>; Sat, 29 Feb 2020 18:27:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kz5Yl8u3C52N for <int-area@ietfa.amsl.com>; Sat, 29 Feb 2020 18:27:10 -0800 (PST)
Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [146.101.78.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC503A1801 for <int-area@ietf.org>; Sat, 29 Feb 2020 18:27:09 -0800 (PST)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03lp2057.outbound.protection.outlook.com [104.47.9.57]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-81--912_hvBOWeHGr7MzdDRXA-1; Sun, 01 Mar 2020 02:27:04 +0000
X-MC-Unique: -912_hvBOWeHGr7MzdDRXA-1
Received: from DBBPR03MB5415.eurprd03.prod.outlook.com (20.179.47.79) by DBBPR03MB5160.eurprd03.prod.outlook.com (10.255.78.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Sun, 1 Mar 2020 02:27:02 +0000
Received: from DBBPR03MB5415.eurprd03.prod.outlook.com ([fe80::31cd:8171:1d1f:2fa9]) by DBBPR03MB5415.eurprd03.prod.outlook.com ([fe80::31cd:8171:1d1f:2fa9%5]) with mapi id 15.20.2772.018; Sun, 1 Mar 2020 02:27:02 +0000
From: Andrew Alston <Andrew.Alston@liquidtelecom.com>
To: Joseph Touch <touch@strayalpha.com>, Fernando Gont <fernando@gont.com.ar>
CC: "architecture-discuss@iab.org" <architecture-discuss@iab.org>, Internet Architecture Board <iab@iab.org>, Internet Area <int-area@ietf.org>, IETF <ietf@ietf.org>
Thread-Topic: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
Thread-Index: AQHV7bcNl1ULGT9qmUy3IjCyJijihKgvmTCAgAAMjICAAAP9AIAABAWAgAAEWoCAAAYBgIAATQ2AgAA+1wCAASdAAIABj6mAgAAJd4CAADRFAA==
Date: Sun, 01 Mar 2020 02:27:02 +0000
Message-ID: <A2A1EA35-53F8-4D21-B311-D94E515D5226@liquidtelecom.com>
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com> <CALx6S36wN7VEi_rxLC1ETcTvkGaPhs20KhQrGWAGGTrCL5OT+g@mail.gmail.com> <d41a94f5ede994b9e14605871f9f7140@strayalpha.com> <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com> <3c307da7e8f52b7a29037a1084daf254@strayalpha.com> <a24a3621-99f6-755d-c679-2061b9a67adf@si6networks.com> <CAOj+MMGJ11CBCov=-jfZUtROJPwhQB3A=+0gMBhzZgxoF_9N1A@mail.gmail.com> <A83D4788-AD7B-490C-B74E-2548A1345C47@strayalpha.com> <CAOj+MMHfKMGa7w9pkqg=2RC4XeuYk7+iHt949B3kUtc+vCeB1Q@mail.gmail.com> <E85CB286-E396-45AF-A7E3-5600B66297CD@strayalpha.com> <040673a8-0e63-6603-9fae-5fea164f4379@gont.com.ar> <9E2F7BA4-9439-4207-BA49-60E51634A4A7@strayalpha.com>
In-Reply-To: <9E2F7BA4-9439-4207-BA49-60E51634A4A7@strayalpha.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.21.0.200113
x-originating-ip: [2c0f:fe40:3:3:808d:eb0:4250:7e10]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 60f7a6e0-62c1-4372-dcd6-08d7bd8806ac
x-ms-traffictypediagnostic: DBBPR03MB5160:
x-microsoft-antispam-prvs: <DBBPR03MB516036000E197F319E8EFACCEEE60@DBBPR03MB5160.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0329B15C8A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(376002)(366004)(39850400004)(136003)(346002)(189003)(199004)(6512007)(2906002)(2616005)(54906003)(6506007)(81156014)(81166006)(110136005)(8936002)(186003)(53546011)(6486002)(33656002)(5660300002)(71200400001)(4326008)(8676002)(66946007)(66476007)(66556008)(64756008)(478600001)(86362001)(316002)(66446008)(66574012)(91956017)(36756003)(76116006); DIR:OUT; SFP:1102; SCL:1; SRVR:DBBPR03MB5160; H:DBBPR03MB5415.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: EX6ecBA2v3OAyC7d35hELspdZJ0MOgTWrUEBUggd8Yz7E2RywofuZe4kXmK42catjNki78HMWi9yE7TEErPwVAloeZ/4YDbO65BK/t0B8DK682e9SQG+bGmB/IkJvKxqTL8DUqDtcPKS6w76c409HZMeQEdjhwo8boZtdvIIWosjF3mHHeCz3tNjOLNddlHmR/E00pQQHsFqRyMEYUAfH00+EWbPhALQhv6mi8ixHLyk2yzDnUt/MrKyBVU9CARFnGRzQiFGm+bF2Ap9PKwD2GivorqQjtK1VvQx7pCwyB1+FQON5rCBPhdZOgm5EO8qw+9at7Goww09/Xioqlf2RdiL0W1VhNDpW6aX4l5SIh9TavoyebuPqWQI73X2pl9CRwYODbZ8DEMltA4z4AM63vyGD2gbDUCFBWg6lXZrWh/pLzvv3gyhkGgZPdAsa6b/
x-ms-exchange-antispam-messagedata: 2KoMfjw4nIcXJ781t6wpZ1RjEDPWT1UAJIaKc0R+RN6ASs4m/KfC3LO+s9e5W+WJjpNXGSffVBDJiVf7GCD8YR/IgSyT1ks53K507UFbB3CUeMkK1vmmy1b9OJK2TbF0cPAw0y6GyZE0DiPV6rDjzGHZBaQp31hMk93pi2lj7iJ33PYhWQdq62uAUjyG3iYAyDkTcuuX0A0NwOna1wD2Iw==
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: liquidtelecom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 60f7a6e0-62c1-4372-dcd6-08d7bd8806ac
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2020 02:27:02.0359 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: gD6+xFaKv4Nd9BfsYS62p4ptzOGydANKRCypw0gpYXMX/gjBiH2mcbmusIyYXrFZalAN4JgufgS7maCbdWPt0cg99HnaLMbRolCO9hfiPUk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB5160
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: liquidtelecom.com
Content-Type: multipart/alternative; boundary="_000_A2A1EA3553F84D21B311D94E515D5226liquidtelecomcom_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/3C7U3PnfDcEYzWyyc0dP2aC8n0k>
Subject: Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Mar 2020 02:27:15 -0000

I raised the issue of the limitations imposed by RFC 7112 during the course of this saga – it’s on the list of things that were bluntly and shamelessly ignored without a single comment before this document mysteriously was declared to be moving forward out of last call on the basis of some +1’s.

Thanks

Andrew


From: ietf <ietf-bounces@ietf.org> on behalf of Joseph Touch <touch@strayalpha.com>
Date: Sunday, 1 March 2020 at 05:21
To: Fernando Gont <fernando@gont.com.ar>
Cc: "architecture-discuss@iab.org" <architecture-discuss@iab.org>, Internet Architecture Board <iab@iab.org>, Internet Area <int-area@ietf.org>, IETF <ietf@ietf.org>
Subject: Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)




On Feb 29, 2020, at 5:46 PM, Fernando Gont <fernando@gont.com.ar<mailto:fernando@gont.com.ar>> wrote:

I did look at the protocols involved here; the ingress does add headers but doesn’t appear to handle fragmentation.
That’s a non-starter if you want your packets to traverse a network because people WILL hand you 1280-byte packets, so what will you do?

FWIW, we have been insisting on this point (and others) since they first tried to push EH insertion in draft-ietf-6man-segment-routing-header.

THey removed it from *that* document, but they keep trying to push similar ideas in other documents.

Well its seems simple to me - they need a plan for fragmentation or it’s simply a nonstarter because they can’t support 1280-B packets traversing the network.

No amount of “but this is what the user wants” translates to “they want their packets dropped silently”.

Joe