Re: [Int-area] comment on draft-ietf-intarea-gre-ipv6

Lucy yong <lucy.yong@huawei.com> Mon, 09 March 2015 21:22 UTC

Return-Path: <lucy.yong@huawei.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 C40CF1A8911 for <int-area@ietfa.amsl.com>; Mon, 9 Mar 2015 14:22:57 -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 4faGgmrJLbsy for <int-area@ietfa.amsl.com>; Mon, 9 Mar 2015 14:22:55 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 334721A886B for <int-area@ietf.org>; Mon, 9 Mar 2015 14:22:54 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTL39543; Mon, 09 Mar 2015 21:22:51 +0000 (GMT)
Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Mar 2015 21:22:50 +0000
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Mon, 9 Mar 2015 14:22:44 -0700
From: Lucy yong <lucy.yong@huawei.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, Ronald Bonica <rbonica@juniper.net>, "int-area@ietf.org" <int-area@ietf.org>
Thread-Topic: [Int-area] comment on draft-ietf-intarea-gre-ipv6
Thread-Index: AdBXbdfY1u3rjZCDS1GBQOYYyX4bpAAET6LQAD8AzmAAUTgpQAAuCK1AAAUFgYAAAVKdgAAC5NbwAAKZI2AAAK/+AAAA7iIA
Date: Mon, 09 Mar 2015 21:22:44 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4545DAE4@dfweml701-chm>
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> <2134F8430051B64F815C691A62D9831832E17BE7@XCH-BLV-504.nw.nos.boeing.com> <2691CE0099834E4A9C5044EEC662BB9D4545DA2D@dfweml701-chm> <2134F8430051B64F815C691A62D9831832E180FD@XCH-BLV-504.nw.nos.boeing.com>
In-Reply-To: <2134F8430051B64F815C691A62D9831832E180FD@XCH-BLV-504.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.155.252]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/int-area/8YnBml4Kqx8SiIassaeWyeVWGhw>
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 21:22:57 -0000

Hi Templin,
> 
> > 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.
> 
> RFC2460 is even older still - but, that does not necessarily mean we 
> should go back and add a checksum field to the IPv6 header. Like RFC2460, RFC2473 is a standard and has been for a long time. So, if we don't like it we would need to go back and deprecate it, right?
> [Lucy] I did not say that the time is a problem. It seems that there 
> is a concern on RFC2473 and nobody looked at this since 1998 when
> IPv6 was barely deployed, (I would be wrong, new to int-are), I agree 
> that we can correct/enhance a RFC if it is useful protocol and have a problem.

There was a lot of discussion on whether IPv6 should include a header checksum back in the very earliest days, and it turned out to be one of the fundamental design points of the protocol. That means that upper layer protocols need to include a pseudo header in their checksums that covers the IPv6 header.
[Lucy] Yes, this is a fundamental change in IPv6 from IPv4

However, when you have tunnels within tunnels, the outermost encapsulation may not be covered by a pseudo header checksum of the inner protocol. This can potentially be addressed by Tom's proposal of leveraging the GRE key field as a weak integrity check to protect against mis-delivery.
[Lucy] Agree.

You should see by now why I say that 'draft-ietf-intarea-gre-ipv6' and RFC2473 are in the same boat - the former is simply one operational mode of the latter.
[Lucy] Yap. But gre-ipv6 does not aim to address this issue yet. It just documents gre-in-ipv6 as of gre-in-ipv4. This was the reason I started this thread. If it just documents, it needs to point out the issue when using it; or it can enhance the protocol to make it work properly in IPv6.

Thanks,
Lucy

Thanks - Fred
fred.l.templin@boeing.com

> Regards,
> Lucy
> 
> Thanks - Fred
> fred.l.templin@boeing.com
> 
> > 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