Re: [ipwave] rereview of draft-ietf-ipwave-ipv6-over-80211ocb-45
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 28 May 2019 13:36 UTC
Return-Path: <pthubert@cisco.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2B41200B4 for <its@ietfa.amsl.com>; Tue, 28 May 2019 06:36:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DtqMWced; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=vUvUhNhq
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 reWnjRULLvKf for <its@ietfa.amsl.com>; Tue, 28 May 2019 06:35:58 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90A3120158 for <its@ietf.org>; Tue, 28 May 2019 06:35:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=231430; q=dns/txt; s=iport; t=1559050557; x=1560260157; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Oma3hqhZ29r6xFrs0cQuO2Z6SFKiBwtl1Ra/DnrGacM=; b=DtqMWcedKja+pFornZSKQaA2g/cRLFuo2rIzT1xjbeDaWEKsGIxsO1J1 X/ncc/Cm+jHaIqg7eU0PqPQrNVLz8md46fLtfeO4KUp9gEdtYd/2oDJ/T L8nEB6FwcJHXKSZcyQtj1IZUGptl9QxVph//orJw66mSyDgJ10I+MpnRm w=;
IronPort-PHdr: 9a23:+2RfpRI2aBkoGCOY19mcpTVXNCE6p7X5OBIU4ZM7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUgMdz8AfngguGsmAXFXnLOPgYjYmNM9DT1RiuXq8NBsdFQ==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AdAQBsOO1c/5hdJa1lHgEGBwaBUwcLAYEOLyknA2lVIAQLKIQTg0cDjnuCV36WLYEuFIEQA1QJAQEBDAEBJQgCAQGEQAIXgkwjNgcOAQMBAQQBAQIBBG0cDIVKAQEBAQIBEggJChMBAS4JAQQLAgEIEiYBCQICAjAXDgIEDg0TB4MBgR1NAw4PAQIMnXYCgTiIX3GBL4J5AQEFhHkYgg8DBoE0hGmGaheBQD+BEAFGgU5JNT6CYQEBAgGBIiQaDB8LglIygiaODIRjiCWNQwkCgg2GNIRIiDSWSZNwjAyCagIEAgQFAg4BAQWBVgsmgVdwFRqDDYIPDBeBAgECgkiFFIU/cgEBgSeNbQEB
X-IronPort-AV: E=Sophos;i="5.60,523,1549929600"; d="scan'208,217";a="279273762"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 May 2019 13:35:55 +0000
Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x4SDZtLW031990 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 May 2019 13:35:55 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 28 May 2019 08:35:54 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 28 May 2019 08:35:54 -0500
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 28 May 2019 09:35:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Oma3hqhZ29r6xFrs0cQuO2Z6SFKiBwtl1Ra/DnrGacM=; b=vUvUhNhqKsfphtOV3xjra+gH3ijXS6sEDAKvthYSEp1Lqv0QO0YMNQpsONL9cs4cYArQFbdw67C2ZL4GDSY3FRSt3N6SsZij0NECBo33pXwFJr5iTwSe+4v7r9xZZ4G4VvJYXMCv2apq9LDNOmexh5hm+dET/ESQKmR79OnANOw=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3965.namprd11.prod.outlook.com (10.255.180.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.18; Tue, 28 May 2019 13:35:51 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::7cc2:b440:8820:f0fc]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::7cc2:b440:8820:f0fc%7]) with mapi id 15.20.1922.021; Tue, 28 May 2019 13:35:51 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Nabil Benamar <benamar73@gmail.com>
CC: "its@ietf.org" <its@ietf.org>
Thread-Topic: [ipwave] rereview of draft-ietf-ipwave-ipv6-over-80211ocb-45
Thread-Index: AdUUe0SaHTyHh4gZRL6iyK8ToobGXQAGuVsAAACQNCAAAYSpAAAkrGaAAAiOZgAAADBKMA==
Date: Tue, 28 May 2019 13:35:22 +0000
Deferred-Delivery: Tue, 28 May 2019 13:34:53 +0000
Message-ID: <MN2PR11MB35658043AF0D0F24318F20F0D81E0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <MN2PR11MB3565835AA0C2813F6E093278D81D0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMugd_UDju8Psj6No1QA4fW91f7b2zXFiJ4phPSdxJEdRJjZGw@mail.gmail.com> <MN2PR11MB35656953BF97BBFF323FEB96D81D0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMugd_UAZf3SQtaOqb_X7b1ONiMuwatvGHmgsZ40_Zk0vjpJ9Q@mail.gmail.com> <MN2PR11MB3565CFFF49D3388864B66F38D81E0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMugd_WHuP0RFZNubKvhmC26r79edtw7we-v==bk+YngptbyqQ@mail.gmail.com>
In-Reply-To: <CAMugd_WHuP0RFZNubKvhmC26r79edtw7we-v==bk+YngptbyqQ@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2001:420:44f3:1300:d401:7243:9ae8:c5bf]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e68f3171-298e-4ec1-107f-08d6e37166cc
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB3965;
x-ms-traffictypediagnostic: MN2PR11MB3965:
x-ms-exchange-purlcount: 7
x-microsoft-antispam-prvs: <MN2PR11MB39655B136F9C5FD837B3AC4AD81E0@MN2PR11MB3965.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00514A2FE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(396003)(136003)(376002)(39860400002)(199004)(189003)(66476007)(66556008)(64756008)(66446008)(76116006)(66946007)(73956011)(6246003)(8936002)(7696005)(1411001)(25786009)(6916009)(14454004)(4326008)(71200400001)(76176011)(71190400001)(86362001)(7736002)(5070765005)(478600001)(2906002)(606006)(53936002)(81156014)(6306002)(102836004)(6506007)(8676002)(486006)(46003)(229853002)(16350225007)(186003)(52536014)(68736007)(14444005)(256004)(236005)(9686003)(81166006)(53946003)(55016002)(54896002)(6116002)(11346002)(476003)(6436002)(790700001)(446003)(30864003)(33656002)(5660300002)(99286004)(66574012)(74316002)(316002)(6666004)(559001)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3965; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Nj8LLCtw/hp+f/vstH23x/0VdhPXECoqL4bJba4ICped4Kt4tzIpOtB8hi6zwfqXN1Nt7sAEMvjk6TXpSYV8mhgcD2VUhMP3ddtd4MwDOLUkngDps3ep4Vot6lhIocGqvUzLAPFANbYd4cYJImRK69+1Uuh1fbe4OfNT22wiJLWRSuJ8s1zh1989ltSGwZW8+BOCMY/r1EWC1Z9ulrGat0+Q4K8jJbBRFd4wuU0OIn65ex4UEeuzx8g90stZijcqUyKmZohu0DpgLCx4eZESThZz+acTJm2YTK8POyr+GBrD57RdcDtPThYJwrfYCmUE41aqsa+pVzvfAjAfv+fvOw3L6BVkkGoLPt+nDQ4z57jo69l4qze6mCRTfrObHeZJOcVTuxWM3QmnFrKLNzHfqpC9zQcvNOqf0H78oV86m2Y=
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB35658043AF0D0F24318F20F0D81E0MN2PR11MB3565namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e68f3171-298e-4ec1-107f-08d6e37166cc
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2019 13:35:51.2624 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3965
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.25, xch-aln-015.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/29ISN0mM4exyQXLXedKyvEB1nBY>
Subject: Re: [ipwave] rereview of draft-ietf-ipwave-ipv6-over-80211ocb-45
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 May 2019 13:36:01 -0000
Hello Nabil OLD: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes how IPv6 (including addressing and basic ND) can be used to communicate among nodes in range of one another over IEEE 802.11-OCB. Optimizations and usage of IPv6 over more complex scenarios is not covered and is subject of future work. NEW: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document provides methods and settings, and describes limitations, for using IPv6 to communicate among nodes in range of one another over a single IEEE 802.11-OCB link with minimal change to existing stacks. Optimizations and usage of IPv6 over more complex scenarios is not covered and is subject of future work. * Excellent Introduction OLD: The IPv6 network layer operates on 802.11-OCB in the same manner as operating on Ethernet, but there are two kinds of exceptions: o Exceptions due to different operation of IPv6 network layer on 802.11 than on Ethernet. To satisfy these exceptions, this document describes an Ethernet Adaptation Layer between Ethernet headers and 802.11 headers. The Ethernet Adaptation Layer is described Section 4.2.1<https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#section-4.2.1>. The operation of IP on Ethernet is described in [RFC1042<https://tools.ietf.org/html/rfc1042>], [RFC2464<https://tools.ietf.org/html/rfc2464>] . NEW: The IPv6 network layer operates on 802.11-OCB in the same manner as operating on Ethernet, but there are two kinds of exceptions: o Exceptions due to different operation of IPv6 network layer on 802.11 than on Ethernet. The operation of IP on Ethernet is described in [RFC1042<https://tools.ietf.org/html/rfc1042>], [RFC2464<https://tools.ietf.org/html/rfc2464>] . * Works for me 3. Communication Scenarios where IEEE 802.11-OCB Links are Used OLD: The IEEE 802.11-OCB Networks are used for vehicular communications, as 'Wireless Access in Vehicular Environments'. The IP communication scenarios for these environments have been described in several documents; NEW: The IEEE 802.11-OCB Networks are used for vehicular communications, as 'Wireless Access in Vehicular Environments’. In particular, we refer the reader to [I-D.ietf-ipwave-vehicular-networking], that lists some scenarios and requirements for IP in Intelligent Transportation Systems. * Yes OLD: The link model is the following: STA --- 802.11-OCB --- STA. In vehicular networks, STAs can be IP-RSUs and/or IP-OBUs. While 802.11-OCB is clearly specified, and the use of IPv6 over such link is not radically new, the operating environment (vehicular networks) brings in new perspectives. NEW: The link model is the following: STA --- 802.11-OCB --- STA. In vehicular networks, STAs can be IP-RSUs and/or IP-OBUs. All links are assumed to be P2P and multiple links can be on one radio interface. While 802.11-OCB is clearly specified, and the use of IPv6 over such link is not radically new, the operating environment (vehicular networks) brings in new perspectives. * OK . I’d rather replace “the use of IPv6 over such link is not radically new” with “a legacy IPv6 stack can operate on such links” 4<https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#section-4>. IPv6 over 802.11-OCB OLD: The default MTU for IP packets on 802.11-OCB MUST be 1500 octets. It is the same value as IPv6 packets on Ethernet links, as specified in [RFC2464<https://tools.ietf.org/html/rfc2464>]. This value of the MTU respects the recommendation that every link on the Internet must have a minimum MTU of 1280 octets. NEW: The default MTU for IP packets on 802.11-OCB is inherited from RFC2464 and is 1500 octets. This value of the MTU respects the recommendation that every link on the Internet must have a minimum MTU of 1280 octets (stated in <xref target="RFC8200"/>, and the recommendations therein, especially with respect to fragmentation). > OK . 4.2. Frame Format OLD: IP packets MUST be transmitted over 802.11-OCB media as QoS Data frames whose format is specified in IEEE 802.11(TM) -2016 [IEEE-802.11-2016]. NEW: IP packets MUST be transmitted over 802.11-OCB media as QoS Data frames whose format is specified in IEEE 802.11 spec. Ø Leave the reference just use a dateless one, e.g.: Ø <reference anchor="IEEEstd80211"> <front> <title>IEEE Standard for Information technology -- Telecommunications and information exchange between systems Local and metropolitan area networks-- Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications </title> <author> <organization> IEEE standard for Information Technology </organization> </author> <date/> </front> </reference> OLD: The IPv6 packet transmitted on 802.11-OCB MUST be immediately preceded by a Logical Link Control (LLC) header and an 802.11 header. NEW: IPv6 packet transmitted on 802.11-OCB are immediately preceded by a Logical Link Control (LLC) header and an 802.11 header Ø Good OLD: In the 802.11 header, the value of the Subtype sub-field in the Frame Control field MUST be set to 8 (i.e. 'QoS Data'); the value of the Traffic Identifier (TID) sub-field of the QoS Control field of the 802.11 header MUST be set to binary 001 (i.e. User Priority 'Background', QoS Access Category 'AC_BK'). NEW: The mapping to the 802.11 data service MUST use a ‘priority’ value of 1, which specifies the use of QoS with a “Background” user priority. Ø I’ll trust you on that OLD: To simplify the Application Programming Interface (API) between the operating system and the 802.11-OCB media, device drivers MAY implement an Ethernet Adaptation Layer that translates Ethernet II frames to the 802.11 format and vice versa. An Ethernet Adaptation Layer is described in NEW: To simplify the Application Programming Interface (API) between the operating system and the 802.11-OCB media, device drivers MAY implement IPv6 over Ethernet per RFC 2464 and then a frame translation from 802.3 to 802.11 in order to minimize the code changes. Ø Perfect OLD: 4.4. Stateless Autoconfiguration There are several types of IPv6 addresses [RFC4291], [RFC4193], that MAY be assigned to an 802.11-OCB interface. This section describes the formation of Interface Identifiers for IPv6 addresses of type 'Global' or 'Unique Local'. For Interface Identifiers for IPv6 address of type 'Link-Local' see Section 4.3. NEW: The steps a host takes in deciding how to autoconfigure its interfaces in IP version 6 are described in <xref target='RFC4862'/>. This section describes the formation of Interface Identifiers for IPv6 addresses of type 'Global' or 'Unique Local'. For Interface Identifiers for IPv6 address of type 'Link-Local' see <xref target='ll'/>. Ø Works for me OLD: The Interface Identifier for an 802.11-OCB interface is formed using the same rules as the Interface Identifier for an Ethernet interface; NEW: The RECOMMENDED method for forming stable Interface Identifiers (IIDs) is described in <xref target='RFC8064'/>. The method of forming IIDs described in section 4 of <xref target='RFC2464'/> MAY be used during transition time, in particular for IPv6 link-local addresses. * Yes OLD: 4.5.1. Address Mapping -- Unicast The procedure for mapping IPv6 unicast addresses into Ethernet link- layer addresses is described in [RFC4861]. NEW: 4.5.1. Address Mapping -- Unicast This draft is scoped for AR and DAD per RFC 4861. * True OLD: 4.5.2. Address Mapping -- Multicast <Snap> These issues may be exacerbated in OCB mode. Solutions for these problems SHOULD consider the OCB mode of operation. NEW: These issues may be exacerbated in OCB mode. Future improvement to this specification SHOULD consider solutions for these problems. * Excellent OLD: The subnet structure on which the Neighbor Discovery protocol (ND) on OCB works ok is a single-link subnet; the status of ND operation on a subnet that covers multiple OCB links that repeat the signal at PHY layer, or the messages at MAC layer, is unknown. NEW: An IPv6 subnet on which Neighbor Discovery protocol (ND) can be used can be mapped on an OCB network iff all nodes share a single broadcast Domain, which is generally the case for P2P OCB links; the status of ND operation on a subnet that covers multiple OCB links That are not fully overlapping (NBMA) is not in scope. * Yes. Maybe: ” An IPv6 subnet on which Neighbor Discovery protocol (ND) can be used can be mapped on an OCB network iff all nodes share a single broadcast Domain, which is generally the case for P2P OCB links (OCB is usually reflexive) but not for multipoint (OCB is generally not transitive); the status of ND operation on a subnet that covers multiple OCB links That are not fully overlapping (NBMA) is not in scope. “ OLD: The baseline Neighbor Discovery protocol (ND) [RFC4861<https://tools.ietf.org/html/rfc4861>] MUST be used over 802.11-OCB links. NEW: The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST be supported over 802.11-OCB links. Ø Yes OLD: Transmitting ND packets may prove to have some performance issues. These issues may be exacerbated in OCB mode. Solutions for these problems SHOULD consider the OCB mode of operation. The best of current knowledge indicates the kinds of issues that may arise with ND in OCB mode; they are described in Appendix J. NEW: Transmitting ND packets may prove to have some performance issues. These issues may be exacerbated in OCB mode. Future solutions to OCB should consider solutions for avoiding broadcast. The best of current knowledge indicates the kinds of issues that may arise with ND in OCB mode; they are described in Appendix J. Ø Yes OLD: Within the IPsec Security Architecture [RFC4301], the IPsec AH and ESP headers [RFC4302] and [RFC4303] respectively, its multicast extensions [RFC5374], HTTPS [RFC2818] and SeND [RFC3971] protocols can be used to protect communications. Further, the assistance of proper Public Key Infrastructure (PKI) protocols [RFC4210] is necessary to establish credentials. $ NEW: Removed Ø OK All the best, Pascal
- [ipwave] rereview of draft-ietf-ipwave-ipv6-over-… Pascal Thubert (pthubert)
- Re: [ipwave] rereview of draft-ietf-ipwave-ipv6-o… Nabil Benamar
- Re: [ipwave] rereview of draft-ietf-ipwave-ipv6-o… Pascal Thubert (pthubert)
- Re: [ipwave] rereview of draft-ietf-ipwave-ipv6-o… Nabil Benamar
- Re: [ipwave] rereview of draft-ietf-ipwave-ipv6-o… Pascal Thubert (pthubert)
- Re: [ipwave] rereview of draft-ietf-ipwave-ipv6-o… Nabil Benamar
- Re: [ipwave] rereview of draft-ietf-ipwave-ipv6-o… Pascal Thubert (pthubert)
- Re: [ipwave] rereview of draft-ietf-ipwave-ipv6-o… Nabil Benamar
- Re: [ipwave] rereview of draft-ietf-ipwave-ipv6-o… Pascal Thubert (pthubert)