Hi Tom,

> -----Original Message-----
> From: Tom Herbert [mailto:[email protected]]
> Sent: Monday, March 09, 2015 11:51 AM
> To: Lucy yong
> Cc: Templin, Fred L; Ronald Bonica; [email protected]
> Subject: Re: [Int-area] comment on draft-ietf-intarea-gre-ipv6
> 
> On Mon, Mar 9, 2015 at 10:55 AM, Lucy yong <[email protected]> wrote:
> > Hi Templin,
> >
> > -----Original Message-----
> > From: Templin, Fred L [mailto:[email protected]]
> > Sent: Monday, March 09, 2015 12:15 PM
> > To: Lucy yong; Ronald Bonica; [email protected]
> > 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
[email protected]

> Thanks,
> Tom
> 
> > Thanks,
> > Lucy
> >
> > Thanks - Fred
> > [email protected]
> >
> >> -----Original Message-----
> >> From: Int-area [mailto:[email protected]] On Behalf Of
> >> Templin, Fred L
> >> Sent: Monday, March 09, 2015 7:52 AM
> >> To: Lucy yong; Ronald Bonica; [email protected]
> >> Subject: Re: [Int-area] comment on draft-ietf-intarea-gre-ipv6
> >>
> >>
> >>
> >> > -----Original Message-----
> >> > From: Lucy yong [mailto:[email protected]]
> >> > Sent: Sunday, March 08, 2015 10:05 AM
> >> > To: Templin, Fred L; Ronald Bonica; [email protected]
> >> > Subject: RE: [Int-area] comment on draft-ietf-intarea-gre-ipv6
> >> >
> >> > Hi Templin,
> >> >
> >> >
> >> > > -----Original Message-----
> >> > > From: Int-area [mailto:[email protected]] On Behalf Of
> >> > > Lucy yong
> >> > > Sent: Thursday, March 05, 2015 12:09 PM
> >> > > To: Ronald Bonica; [email protected]
> >> > > 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
> >> [email protected]
> >>
> >> > Thanks,
> >> > Lucy
> >> >
> >> > Thanks - Fred
> >> > [email protected]
> >> >
> >> > > Thanks,
> >> > > Lucy
> >> > >
> >> > >
> >> > > -----Original Message-----
> >> > > From: Ronald Bonica [mailto:[email protected]]
> >> > > Sent: Thursday, March 05, 2015 11:57 AM
> >> > > To: [email protected]; 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 <[email protected]>
> >> > > > To: "[email protected]" <[email protected]>
> >> > > > 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
> >> > > [email protected]
> >> > > https://www.ietf.org/mailman/listinfo/int-area
> >>
> >> _______________________________________________
> >> Int-area mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/int-area
> >
> > _______________________________________________
> > Int-area mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to