RE: Questions regarding the security mechanisms//RE: CRH and RH0
Ron Bonica <rbonica@juniper.net> Fri, 15 May 2020 20:08 UTC
Return-Path: <rbonica@juniper.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A0C3A08DD for <ipv6@ietfa.amsl.com>; Fri, 15 May 2020 13:08:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.272
X-Spam-Level:
X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=iFEA2HOI; dkim=pass (1024-bit key) header.d=juniper.net header.b=W9b3m/OO
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 5Od_McIBq3zG for <ipv6@ietfa.amsl.com>; Fri, 15 May 2020 13:08:54 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF74F3A08E2 for <6man@ietf.org>; Fri, 15 May 2020 13:08:54 -0700 (PDT)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 04FK3Mco014833; Fri, 15 May 2020 13:08:32 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=G1XJ+QXlNNoxVGW6yqtNGsSsKBU7KTODF3KatXXe6m0=; b=iFEA2HOIa0CMWKJfU3Ttr3RvyYw0fzpw9Z9MzViNAsXbmcWikks8AEAUCxpxamZEKmFs bVUHEYdivGbPZJNZcTU5lhHUCENCbel/LM3gwZOwvtcghiKe1SpQq7u8XI6mYFHCX0uh FJR5PELKr444QrLMLp+f7gxiSXrDP3W7njrXy6kw/7kRvTCP+ZPsvz9vRpUujhpdbSwF 1PGeNE0ClBaImjzRufivCunjEXWaVll85coG+SszAlPEYX5GkKmvD9UkbXCH4b27AiZ+ 0H/sWy9IhVzUC3q8dmUsMe7EN7tQrk1JY0W59rd0VZQVloRTP10Ni/fdJXnXUCYT0rBH iA==
Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2106.outbound.protection.outlook.com [104.47.55.106]) by mx0a-00273201.pphosted.com with ESMTP id 3100ygf377-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 May 2020 13:08:32 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EeJtwh46O2vVBArmQ8xpLTTquxx9H0yBRm7yo0VOiYkm1v5yICT8sVmkVRafJsLr4eLa88WYBT5R6OaPNh5/IpBnRYfgZLcgL8RN3JF6E2jZ866FoRwCZ5qc6rnjajKlU3EVF8UKxXl5mUVOT+9YkbX/oOOz43ysPoR8tB/ECYOZDL2Vx6aoFcbaeOp1MKpBhf70g4IpXxl6zylidFmrPZ2kKQCHpFjYL1JtZD4gBwt+h0ydZl11yYzYO31ud1fGQOm6T3eafeKLp9kzb3RtmI4dgFEV6iXRzEcOjV0faubMQT+T1uzyH6GpVpCPEmpCTigOkyeVlrQ1LeTd1807UQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G1XJ+QXlNNoxVGW6yqtNGsSsKBU7KTODF3KatXXe6m0=; b=M1qRXEsOL9o5ETjG+oQAhDbe8q1012amwg0QnA01qO/k+iAmeFHWbb/0CuaCxNR8V5r/HE6soGrasmI++8HyM+HCDw5ga+hCdMRGuoC9KI4fx0LFskcsDdG7CXtWlvqVunDu7WduX/IcO5UK/8c1TPY1dbc0jRZo3J7shAmVYWEkVYu8h5W6tp7AYNryL9iCnlOVRsjNJ+sxCU287VsvU+a0kdbpG9F7sQusHA0n7MqN1hHwQhc/rmAzosbKheIpFvK9Ouo1b8LfdmHBGHGVWx6ldAWeQq79ugr8H7NslFuH3c/IWdzoppRD/WKFUfON94a16HW6P+Lg8kWvTIhrGg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G1XJ+QXlNNoxVGW6yqtNGsSsKBU7KTODF3KatXXe6m0=; b=W9b3m/OOZVcfVIgR2GODpnhC8U9RlpXj8ubibVhprgGQc+v2YEXsTkUTD95cmmDCuE+/zc9W7rkt6SRnnns0B8783rVhs7vSvMVGN8fxNvw4n1/JKVcRgKSOgTml1MH30CTB7mY95DuQISXtGoD22eqmfqf0p+EIZ1gcHBJlFuA=
Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB3946.namprd05.prod.outlook.com (2603:10b6:5:8b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.11; Fri, 15 May 2020 20:08:29 +0000
Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3%4]) with mapi id 15.20.3021.010; Fri, 15 May 2020 20:08:29 +0000
From: Ron Bonica <rbonica@juniper.net>
To: qinfengwei <qinfengwei@chinamobile.com>, "'Xiejingrong (Jingrong)'" <xiejingrong@huawei.com>, 'Bob Hinden' <bob.hinden@gmail.com>, "'Darren Dukes (ddukes)'" <ddukes@cisco.com>
CC: '6man' <6man@ietf.org>
Subject: RE: Questions regarding the security mechanisms//RE: CRH and RH0
Thread-Topic: Questions regarding the security mechanisms//RE: CRH and RH0
Thread-Index: AdYqA0uTBELEk8r7RxOFOlq1QjWhwwAniBKgABOLx4A=
Date: Fri, 15 May 2020 20:08:29 +0000
Message-ID: <DM6PR05MB634863122645FD4981B97F71AEBD0@DM6PR05MB6348.namprd05.prod.outlook.com>
References: <23488ea0d4eb474c9d7155086f940dae@huawei.com> <006c01d62aa1$8c195520$a44bff60$@com>
In-Reply-To: <006c01d62aa1$8c195520$a44bff60$@com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-05-15T20:08:28Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=567d0bbb-619b-40df-95ec-60833ee66b02; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
dlp-product: dlpe-windows
dlp-version: 11.4.0.45
dlp-reaction: no-action
authentication-results: chinamobile.com; dkim=none (message not signed) header.d=none;chinamobile.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [108.28.233.91]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 0dfb7821-eef5-4b2f-af06-08d7f90bbc16
x-ms-traffictypediagnostic: DM6PR05MB3946:
x-microsoft-antispam-prvs: <DM6PR05MB394641D6DD8BF26ED2249EEFAEBD0@DM6PR05MB3946.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04041A2886
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Hpz9cBMi29nxNwNo3Yh7jXJLbd8osGMAvSQ0mXtt8czusC9kTwfLmqrap4vEGo/u9hY5dpWs/9b+md0HijqtkOVVcaR/Iee2O0dBbSNPnGZsfxDj/3m9SyBmW+tgpLXpyXhj4oW3R5DgHeo3LQ+JytXSEhU8HkudLwwccewIBqi2UwWsskk/6pa9lVAMP+dgOjCcS6I3mfMFdfmLUZYJ7gnKSci0S/0NGN4xm+5FZTTe0YvEwy+DA8t3ftvYyry/nQwo0WZLwqUXJ1qRr4WqYDmqZdgVq98234hhpx1uEO6qowWVtd+XYqAda7Ag9FA35gT6BlTWJYNJQ1lQQr+afXrC+lXMZ2uu88wXeEdnG5EzhhMRniHA/uycI9KE2J4Vu2Oei5vZdEV3bMIfMyVGUA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(136003)(376002)(366004)(396003)(316002)(53546011)(52536014)(8936002)(6506007)(2906002)(110136005)(966005)(8676002)(7696005)(86362001)(186003)(15650500001)(26005)(55016002)(66946007)(66574014)(5660300002)(9686003)(71200400001)(64756008)(66556008)(76116006)(33656002)(478600001)(4326008)(66446008)(66476007); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: A0x/TZZaX9SBFGOIYKbHBfFEPnt/mFs0IpE7YKhfxhzsDPWasWBysJqPw1tFkzT28i8eTAr5IPJ78SvJSOrHcfNbufCOWLUbb51Kz0j8IvZtRPOFtFODgYadqNslemcCdcFM+0wQkc/VCB0QvIac3oTEWXh+eVg5KCEvcmX3xzShz7x9nHbZoWEywnW3LEJfHYxAaTlz70lRi5U4bVexTX0O41rgW0jr33EKtAqSpZ1uAr5DEovLZBsBOBQLEkRZcm7dd7j743jsyJH/l82oT0n9A7xxGBbf/bVlN3TmEaBwpTUm6Ibx1ko4jrBI++/3avdXe7YfAY81CLmW27xRAGOnEuBvIRUeTw5MbpwJlMs2w7fdCEkFZuAXQYetyPAXNtczSpTSLmNk3U/auaf/JJuIbur6yRox8dHurB1fTK37h0YqwG/MAIzfF2b/pTh8cwn1wZaO5suIdroNfa0hMLjBBPl8ullFMXt7YC6Fj0wPX2eHOygsj3YiMtu0bqcF
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 0dfb7821-eef5-4b2f-af06-08d7f90bbc16
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2020 20:08:29.0225 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: g1uf53PGGaM95bSXk01NrPcEPW8I+FFO0Kb54RoFVT9KGGlA21pwDI/UH5ushjSNc89hFuPRVLpohMrRPrVmUA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB3946
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-15_07:2020-05-15, 2020-05-15 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 mlxscore=0 suspectscore=0 clxscore=1015 lowpriorityscore=0 mlxlogscore=999 priorityscore=1501 cotscore=-2147483648 impostorscore=0 bulkscore=0 adultscore=0 phishscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2005150166
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Nbc_7TON4J_-nvZsz6OT24zggg4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 May 2020 20:08:59 -0000
Fengwei, Jingrong, Your raise excellent questions, and I will try to address them. In 2007, security researchers demonstrated that Routing headers can be used attack vectors. See the following slide deck: - http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf Therefore, we conclude that if a network contains nodes that process the CRH, it MUST deploy ACLs at its edge. These ACLs: - MUST be sufficiently restrictive to filter harmful packets - SHOULD NOT be so restrictive that they filter harmless packets. Therefore, the network SHOULD filter packets that satisfy all of the following criteria: - The Destination Address field in the IPv6 header represents an interface that resides inside of the network. - The packet contains a CRH - The Segments Left field is greater than 0 We understand that many networks cannot filter on such a granular basis. Therefore, they MAY deploy ACLs that filter a superset of the packets described above. For example, they may: - Filter all packets where the Destination Address field in the IPv6 header represents an interface inside of the network. (Many network already do this). - Filter all packets that contain a CRH and where the Destination Address field in the IPv6 header represents an interface inside of the network. - Filter all packets that contain a CRH I hope that this helps. Ron Juniper Business Use Only -----Original Message----- From: qinfengwei <qinfengwei@chinamobile.com> Sent: Friday, May 15, 2020 6:14 AM To: 'Xiejingrong (Jingrong)' <xiejingrong@huawei.com>; Ron Bonica <rbonica@juniper.net>; 'Bob Hinden' <bob.hinden@gmail.com>; 'Darren Dukes (ddukes)' <ddukes@cisco.com> Cc: '6man' <6man@ietf.org> Subject: 答复: Questions regarding the security mechanisms//RE: CRH and RH0 [External Email. Be cautious of content] Hi Ron and authors, As a operator, Security is one of the most important factors in whether a solution could be implemented. It is hoped that the security aspects will be carefully considered. Thanks, Fengwei Qin -----邮件原件----- 发件人: ipv6 [mailto:ipv6-bounces@ietf.org] 代表 Xiejingrong (Jingrong) 发送时间: 2020年5月14日 23:19 收件人: Ron Bonica; Bob Hinden; Darren Dukes (ddukes) 抄送: 6man 主题: Questions regarding the security mechanisms//RE: CRH and RH0 Hi Ron and authors, I haven't found much change about the security mechanisms in the latest revision of this draft. So here are some questions I have so far on this aspect (based on the rev-18): 9. Security Considerations Networks that process the CRH MUST NOT accept packets containing the CRH from untrusted sources. Their border routers SHOULD discard packets that satisfy the following criteria: o The packet contains a CRH o The Segments Left field in the CRH has a value greater than 0 o The Destination Address field in the IPv6 header represents an interface that resides inside of the network. Many border routers cannot filter packets based upon the Segments Left value. These border routers MAY discard packets that satisfy the following criteria: o The packet contains a CRH o The Destination Address field in the IPv6 header represents an interface that resides inside of the network. [Q1] Do the words 'SHOULD' and 'MAY' mean the protection for boundary is optional? Or there is no "limited domain" boundary for the CRH ? If this is optional, Is it possible for a packet to be constructed and sent from internet such that it will oscillate between two CRH routers many times ? [Q2] Does the word 'MAY' mean a router cannot filter packets based upon the SL value, but may filter packets contains a CRH ? Judging a packets contains a CRH means judging a packet contains a RH and "Routing Type" field == 5/6; Judging a packet whether the SL is greater than 0 means judging a packet contains a RH and "SL" field !=0; I failed to see why a router could do the first one but couldn't do the second one. Besides, could the above two judgements be executed on a border router if there is a HBH before the RH ? [Q3] How to judge the "DA represents an interface that resides inside of the network"? suppose the following diagram: [Internet--------BorderRouter------CRHrouter1------intermediateRouters------ CRHrouter2] A packet (SA=internet, DA=CRHrouter1) (CRH SL=1, SID[0]=CRHrouter2, SID[1]=CRHrouter1) is received by BorderRouter. In this case, the DA = CRHrouter1 means "an interface that resides inside of the network" ? If there are 1000 routers say CRHrouter1/2/.../1000, will you consider to use an IPv6 address block (like 5.1 of RFC8754) for this judgement ? Best Regards Jingrong -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ron Bonica Sent: Thursday, May 14, 2020 2:28 AM To: Bob Hinden <bob.hinden@gmail.com>; Darren Dukes (ddukes) <ddukes=40cisco.com@dmarc.ietf.org> Cc: 6man <6man@ietf.org> Subject: RE: CRH and RH0 Bob, I just posted version 16: - tracker: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr/__;!!NEt6yMaO-gk!R-fnImTVyM67P-81jr0JY3of_Uz_pmd0wjQJ3k1_gpkWaCkOaUNjSjjhrgxsyuQh$ - diff: https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-bonica-6man-comp-rtg-hdr-16__;!!NEt6yMaO-gk!R-fnImTVyM67P-81jr0JY3of_Uz_pmd0wjQJ3k1_gpkWaCkOaUNjSjjhrvB84OMK$ It removes all references to RH0 and is more explicit about operating inside of a network domain for security reasons. I still see a use case for the 32-bit SID, so I left that in the draft. Ron Juniper Business Use Only -----Original Message----- From: Bob Hinden <bob.hinden@gmail.com> Sent: Wednesday, May 13, 2020 1:29 PM To: Darren Dukes (ddukes) <ddukes=40cisco.com@dmarc.ietf.org> Cc: Bob Hinden <bob.hinden@gmail.com>; Ron Bonica <rbonica@juniper.net>; 6man <6man@ietf.org> Subject: Re: CRH and RH0 Hi, > On May 13, 2020, at 10:16 AM, Darren Dukes (ddukes) <ddukes=40cisco.com@dmarc.ietf.org> wrote: > > Hi Ron, > > I'm still trying to figure out where you're going with this. > First it was SRm6, then an RH0 replacement, then not an RH0 > replacement (in the 6man meeting), then it sort of is... > > So I'm hoping you'll update the draft so I can understand a bit more: > - CRH has nothing to do with RH0. > - CRH operates only within a limited domain. I think these are reasonable suggestions. I also think only having one size would be helpful. Bob > > Anything else to clarify from others comments would help too. > > Thanks > Darren > >> On May 12, 2020, at 5:36 PM, Ron Bonica <rbonica@juniper.net> wrote: >> >> Ole, Darren, >> >> The CRH is a general purpose Routing header that operates inside of a network domain. In the sense that it is a general purpose routing header, it replaces RH0. In the sense that it is restricted to a network domain, it does not replace RH0. >> >> If adding these two sentences will cause you to support the draft, or >> at least not object to it, I will happily add them! >> >> Are these the only objections? >> >> Ron >> >> >> >> Juniper Business Use Only >> >> -----Original Message----- >> From: otroan@employees.org <otroan@employees.org> >> Sent: Tuesday, May 12, 2020 4:38 PM >> To: Ron Bonica <rbonica@juniper.net> >> Cc: Darren Dukes (ddukes) <ddukes@cisco.com>; 6man <6man@ietf.org> >> Subject: Re: CRH and RH0 >> >> [External Email. Be cautious of content] >> >> >> Hi Ron, >> >> >>> The answer to your question is a bit nuanced. My goals were to build >>> a general purpose routing header that overcomes the RH0's limitations. Those being: >>> >>> - Its size >>> - Its security issues >>> >>> Now, is that a replacement for RH0? In one way, yes. RH0 and CRH are both general purpose routing headers. In another sense, no. RH0 is meant to traverse network boundaries. But RFC 5095 taught us that letting routing header traverse network boundaries might not be a wonderful idea. So, CRH is restricted to a network domain. >> >> If CRH could be a RH0 replacement, you would have to show how the tag distribution mechanism would work across the Internet? >> RH0 was supported in every IPv6 node, given the requirement for a tag->IPv6 address (or is it forwarding method) mapping, I can't quite tag->see how that would be done in a general enough fashion for CRH? >> >> I don't think RFC5095 taught us that source routing cannot be done >> across the Internet. >> In fact I don't see how the CRH draft prevents the RFC5095 attack to happen inside of the CRH limited domain. >> Just send a packet with a list of tag#0, tag#1, tag#0, tag#1 and you >> have the same amplification attack. >> >>> And now I return to my original question. When engineering students >>> read the CRH RFC in 25 years, will they really care what my motivation was? Why should we burden them with this detail? >> >> To the contrary. Take the motivations and intentions behind IPv6. We >> have spent thousands of emails trying to decode what the original intensions with EHs and their limitations were, why the minimum MTU was 1280, recently I saw a thread about the reasons for why TTL/HL and protocol/next header was swapped between v4 and v6. If your protocol is successful, the original napkin it was designed on will become legend. ;-) >> >> Best regards, >> Ole > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6 > __;!!NEt6yMaO-gk!R-fnImTVyM67P-81jr0JY3of_Uz_pmd0wjQJ3k1_gpkWaCkOaUNjS > jjhrpNNsnwO$ > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!R-fnImTVyM67P-81jr0JY3of_Uz_pmd0wjQJ3k1_gpkWaCkOaUNjSjjhrpNNsnwO$ -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!R-fnImTVyM67P-81jr0JY3of_Uz_pmd0wjQJ3k1_gpkWaCkOaUNjSjjhrpNNsnwO$ --------------------------------------------------------------------
- Questions regarding the security mechanisms//RE: … Xiejingrong (Jingrong)
- 答复: Questions regarding the security mechanisms//… qinfengwei
- RE: Questions regarding the security mechanisms//… Ron Bonica
- Re: Questions regarding the security mechanisms//… Fernando Gont
- RE: Questions regarding the security mechanisms//… Ron Bonica
- Re: Questions regarding the security mechanisms//… Fernando Gont
- Re: Questions regarding the security mechanisms//… Tom Herbert
- RE: Questions regarding the security mechanisms//… Ron Bonica
- RE: Questions regarding the security mechanisms//… Xiejingrong (Jingrong)
- RE: Questions regarding the security mechanisms//… Xiejingrong (Jingrong)
- RE: Questions regarding the security mechanisms//… Xiejingrong (Jingrong)
- RE: Questions regarding the security mechanisms//… S Moonesamy
- RE: Questions regarding the security mechanisms//… Xiejingrong (Jingrong)
- Re: Questions regarding the security mechanisms//… Fernando Gont
- RE: Questions regarding the security mechanisms//… Ron Bonica
- Re: Questions regarding the security mechanisms//… Joel M. Halpern
- Re: Questions regarding the security mechanisms//… John Scudder
- Re: Questions regarding the security mechanisms//… Nick Hilliard
- Re: Questions regarding the security mechanisms//… Gyan Mishra
- RE: Questions regarding the security mechanisms//… Xiejingrong (Jingrong)
- RE: Questions regarding the security mechanisms//… Xiejingrong (Jingrong)
- RE: Questions regarding the security mechanisms//… Xiejingrong (Jingrong)
- Re: Questions regarding the security mechanisms//… John Scudder
- Re: Questions regarding the security mechanisms//… Robert Raszuk
- RE: Questions regarding the security mechanisms//… Xiejingrong (Jingrong)
- Re: Questions regarding the security mechanisms//… Nick Hilliard
- Re: Questions regarding the security mechanisms//… John Scudder
- Re: Questions regarding the security mechanisms//… John Scudder
- Re: Questions regarding the security mechanisms//… John Scudder
- Re: Questions regarding the security mechanisms//… Robert Raszuk
- Re: Questions regarding the security mechanisms//… Ole Troan
- Re: Questions regarding the security mechanisms//… John Scudder
- RE: Questions regarding the security mechanisms//… Ron Bonica
- RE: Questions regarding the security mechanisms//… Ron Bonica
- Re: Questions regarding the security mechanisms//… Joel M. Halpern
- RE: Questions regarding the security mechanisms//… Ron Bonica
- Re: Questions regarding the security mechanisms//… Ole Troan