Re: [Int-area] comment on draft-ietf-intarea-gre-ipv6
"Templin, Fred L" <Fred.L.Templin@boeing.com> Mon, 09 March 2015 19:21 UTC
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035F31AC529 for <int-area@ietfa.amsl.com>; Mon, 9 Mar 2015 12:21:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 l_zc6x_Vw2p2 for <int-area@ietfa.amsl.com>; Mon, 9 Mar 2015 12:21:18 -0700 (PDT)
Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DF691AC414 for <int-area@ietf.org>; Mon, 9 Mar 2015 12:19:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t29JJPBI023522; Mon, 9 Mar 2015 14:19:25 -0500
Received: from XCH-PHX-411.sw.nos.boeing.com (xch-phx-411.sw.nos.boeing.com [10.57.37.42]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t29JJIB8023402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 9 Mar 2015 14:19:18 -0500
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.229]) by XCH-PHX-411.sw.nos.boeing.com ([169.254.11.48]) with mapi id 14.03.0210.002; Mon, 9 Mar 2015 12:19:17 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Tom Herbert <tom@herbertland.com>, Lucy yong <lucy.yong@huawei.com>
Thread-Topic: [Int-area] comment on draft-ietf-intarea-gre-ipv6
Thread-Index: AQHQWpn51u3rjZCDS1GBQOYYyX4bpJ0Uhayw
Date: Mon, 09 Mar 2015 19:19:16 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832E17C12@XCH-BLV-504.nw.nos.boeing.com>
References: <CO1PR05MB442AAF3B29AE72283B8B5C0AE1F0@CO1PR05MB442.namprd05.prod.outlook.com> <2691CE0099834E4A9C5044EEC662BB9D4545C68A@dfweml701-chm> <2134F8430051B64F815C691A62D9831832E13D92@XCH-BLV-504.nw.nos.boeing.com> <2691CE0099834E4A9C5044EEC662BB9D4545D18D@dfweml701-chm> <2134F8430051B64F815C691A62D9831832E15252@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E176E4@XCH-BLV-504.nw.nos.boeing.com> <2691CE0099834E4A9C5044EEC662BB9D4545D805@dfweml701-chm> <CALx6S34K7EHZijCOvGTh=TDqudEHLphV-iZ=RXkfN1poi0f1bQ@mail.gmail.com>
In-Reply-To: <CALx6S34K7EHZijCOvGTh=TDqudEHLphV-iZ=RXkfN1poi0f1bQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <http://mailarchive.ietf.org/arch/msg/int-area/UVEw8gL3nzpA7J4IWBrca_lbvoc>
Cc: Ronald Bonica <rbonica@juniper.net>, "int-area@ietf.org" <int-area@ietf.org>
Subject: Re: [Int-area] comment on draft-ietf-intarea-gre-ipv6
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 09 Mar 2015 19:21:21 -0000
Hi Tom, > -----Original Message----- > From: Tom Herbert [mailto:tom@herbertland.com] > Sent: Monday, March 09, 2015 11:51 AM > To: Lucy yong > Cc: Templin, Fred L; Ronald Bonica; int-area@ietf.org > Subject: Re: [Int-area] comment on draft-ietf-intarea-gre-ipv6 > > On Mon, Mar 9, 2015 at 10:55 AM, Lucy yong <lucy.yong@huawei.com> wrote: > > Hi Templin, > > > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: Monday, March 09, 2015 12:15 PM > > To: Lucy yong; Ronald Bonica; int-area@ietf.org > > Subject: RE: [Int-area] comment on draft-ietf-intarea-gre-ipv6 > > > > Hi Lucy, > > > > Also, you say: > > > >> [Lucy] RFC2473 is about IPv6 in IPv6, i.e., IPv6 as a delivery network for IPv6 traffic. > > > > but that is not correct. RFC2473 is about "Generic Packet Tunneling in IPv6", which could include encapsulation of IPv4, IPv6, or other > network protocols - and not just > > IPv6 within IPv6 encapsulation. > > [Lucy] You are right. It has that generalization although very focusing on IPv6. The misdelivery and corruption issues are concern > there too. The draft is very old (1998). IPv6 was barely deployed then. We should address or document these issues if we are working > on it now. > > > > We added this paragraph to the GRE-in_UDP draft to describe how the > keyid might be used as a weak authentication. This might be applicable > to gre-ipv6 also: > > An implementation MAY use the GRE keyid to authenticate the > encapsulator. In this model, a shared value is either configured or > negotiated between an encapsulator and decapsulator. When a GRE-in- > UDP packet is received with the keyid present, it is checked to see > if it is valid for the source to have set for the tunnel packet was > sent on. An implementation MAY enforce that a keyid be used for > source authentication on selected tunnels. When a decapsulator > determines a presented keyid is not valid for the source to send or > the keyid is absent and is considered required for authenticating > the encapsulator for a tunnel, the packet MUST be dropped. Sound reasonable. As I read this, I also realize that the draft in question ('draft-ietf-intarea-gre-ipv6') is nothing more than an operational mode for RFC2473, as RFC2473 allows the inclusion of a GRE header immediately following the IPv6 header. So, I'm not sure whether a new document is needed vs. a (bis) of RFC2473 vs. do nothing, since RFC2473 already covers GRE encapsulation over IPv6. Thanks - Fred fred.l.templin@boeing.com > Thanks, > Tom > > > Thanks, > > Lucy > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of > >> Templin, Fred L > >> Sent: Monday, March 09, 2015 7:52 AM > >> To: Lucy yong; Ronald Bonica; int-area@ietf.org > >> Subject: Re: [Int-area] comment on draft-ietf-intarea-gre-ipv6 > >> > >> > >> > >> > -----Original Message----- > >> > From: Lucy yong [mailto:lucy.yong@huawei.com] > >> > Sent: Sunday, March 08, 2015 10:05 AM > >> > To: Templin, Fred L; Ronald Bonica; int-area@ietf.org > >> > Subject: RE: [Int-area] comment on draft-ietf-intarea-gre-ipv6 > >> > > >> > Hi Templin, > >> > > >> > > >> > > -----Original Message----- > >> > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of > >> > > Lucy yong > >> > > Sent: Thursday, March 05, 2015 12:09 PM > >> > > To: Ronald Bonica; int-area@ietf.org > >> > > Subject: Re: [Int-area] comment on draft-ietf-intarea-gre-ipv6 > >> > > > >> > > Hi Ron, > >> > > > >> > > RFC2784 has this statement: See [RFC1122] for requirements relating to the > >> > > delivery of packets over IPv4 networks. > >> > > Does this apply to over IPv6 networks? > >> > > > >> > > Since IPv6 header does not have checksum, if a packet is > >> > > mis-delivered to GRE decapsulator, will that cause a concern? This is not a concern when IPv4 network is the delivery network. > >> > > >> > In terms of header integrity checks, they are very much in the same boat as RFC2473. > >> > But, somehow that got standardized. > >> > [Lucy] RFC2473 is about IPv6 in IPv6, i.e., IPv6 as a delivery > >> > network for IPv6 traffic. Since IPv6 packets and upper layer > >> > applications have to follow RFC2460, i.e., protect the misdelivery > >> > and corruption, so that is OK if there is only such kind of tunnel > >> > in IPv6. GRE-in- > >> > IPv6 is deferent. They can't be in the same boat. If there are > >> > various network protocols that are tunneled over a same IPv6 > >> > network, > >> it > >> > will have a problem due to packet misdelivery and corruption. IMO: the draft needs to document these. > >> > >> Oh, I thought you were concerned about lack of an integrity check for > >> the encapsulating > >> IPv6 header. Are you saying that (in the RFC2473 case at least) it is > >> OK to omit an integrity check for the encapsulating IPv6 header as > >> long as there is an integrity check for the encapsulated IP header? But, somehow that is not OK for draft-ietf-intarea-gre-ipv6? > >> > >> Thanks - Fred > >> fred.l.templin@boeing.com > >> > >> > Thanks, > >> > Lucy > >> > > >> > Thanks - Fred > >> > fred.l.templin@boeing.com > >> > > >> > > Thanks, > >> > > Lucy > >> > > > >> > > > >> > > -----Original Message----- > >> > > From: Ronald Bonica [mailto:rbonica@juniper.net] > >> > > Sent: Thursday, March 05, 2015 11:57 AM > >> > > To: int-area@ietf.org; Lucy yong > >> > > Subject: RE: [Int-area] comment on draft-ietf-intarea-gre-ipv6 > >> > > > >> > > Hi Lucy, > >> > > > >> > > The goal of this draft is *not* to prove the GRE behaves > >> > > identically with IPv6 as it does with IPv4. In fact, its goal is to point out the differences. > >> > > > >> > > Can you think of any differences between the two GRE environments that we have failed to point out? > >> > > > >> > > > >> > > Ron > >> > > > >> > > > >> > > > > >> > > > Message: 1 > >> > > > Date: Wed, 4 Mar 2015 15:25:54 +0000 > >> > > > From: Lucy yong <lucy.yong@huawei.com> > >> > > > To: "int-area@ietf.org" <int-area@ietf.org> > >> > > > Subject: [Int-area] comment on draft-ietf-intarea-gre-ipv6 > >> > > > Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4545BB21@dfweml701- > >> > > > chm> > >> > > > Content-Type: text/plain; charset="us-ascii" > >> > > > > >> > > > Hi, > >> > > > > >> > > > If this draft is to document the protocol of gre in IPv6 exact > >> > > > same as of gre in > >> > > > IPv4 and update rfc2784, IMHO, it should point out the gre > >> > > > application behavior differences in IPv4 network and IPv6 network. > >> > > > The exact same protocol does not mean the same behavior for an > >> > > > application since IPv4 and > >> > > > IPv6 networks have different behaviors such as header checksum. > >> > > > > >> > > > Thanks, > >> > > > Lucy > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > _______________________________________________ > >> > > Int-area mailing list > >> > > Int-area@ietf.org > >> > > https://www.ietf.org/mailman/listinfo/int-area > >> > >> _______________________________________________ > >> Int-area mailing list > >> Int-area@ietf.org > >> https://www.ietf.org/mailman/listinfo/int-area > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area
- [Int-area] comment on draft-ietf-intarea-gre-ipv6 Lucy yong
- Re: [Int-area] comment on draft-ietf-intarea-gre-… Ronald Bonica
- Re: [Int-area] comment on draft-ietf-intarea-gre-… Lucy yong
- Re: [Int-area] comment on draft-ietf-intarea-gre-… Templin, Fred L
- Re: [Int-area] comment on draft-ietf-intarea-gre-… Lucy yong
- Re: [Int-area] comment on draft-ietf-intarea-gre-… Templin, Fred L
- Re: [Int-area] comment on draft-ietf-intarea-gre-… Templin, Fred L
- Re: [Int-area] comment on draft-ietf-intarea-gre-… Lucy yong
- Re: [Int-area] comment on draft-ietf-intarea-gre-… Tom Herbert
- Re: [Int-area] comment on draft-ietf-intarea-gre-… Templin, Fred L
- Re: [Int-area] comment on draft-ietf-intarea-gre-… Templin, Fred L
- Re: [Int-area] comment on draft-ietf-intarea-gre-… Lucy yong
- Re: [Int-area] comment on draft-ietf-intarea-gre-… Templin, Fred L
- Re: [Int-area] comment on draft-ietf-intarea-gre-… Lucy yong
- Re: [Int-area] comment on draft-ietf-intarea-gre-… Templin, Fred L
- Re: [Int-area] comment on draft-ietf-intarea-gre-… Lucy yong