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

Lucy yong <lucy.yong@huawei.com> Mon, 09 March 2015 21:42 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 0E8951A901F for <int-area@ietfa.amsl.com>; Mon, 9 Mar 2015 14:42:35 -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 mGs4VMlT-OU2 for <int-area@ietfa.amsl.com>; Mon, 9 Mar 2015 14:42:32 -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 D7B2B1ABD3D for <int-area@ietf.org>; Mon, 9 Mar 2015 14:42:20 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTL40528; Mon, 09 Mar 2015 21:42:19 +0000 (GMT)
Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Mar 2015 21:42:19 +0000
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Mon, 9 Mar 2015 14:42:12 -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/+AAAA7iIAAACxW8AAADQ48A==
Date: Mon, 09 Mar 2015 21:42:12 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4545DB39@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> <2691CE0099834E4A9C5044EEC662BB9D4545DAE4@dfweml701-chm> <2134F8430051B64F815C691A62D9831832E182E1@XCH-BLV-504.nw.nos.boeing.com>
In-Reply-To: <2134F8430051B64F815C691A62D9831832E182E1@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/EKS0rRhmd1uKTnHEdeNpY23Vkws>
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:42:35 -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.

I won't disagree with that. But, if there is to be a 'draft-ietf-intarea-gre-ipv6', it needs to say "updates/obsoletes RFC2473". Either that, or perhaps more appropriately an RFC2473(bis).
[Lucy] it makes a sense.

Thanks,
Lucy

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

> 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