Hi, Lucy, One approach is to add a 3.c) to the list that Ron shared. I think there is another potential approach to your initial comment: we could note that for a tunneling protocol (GRE), this is equivalent to the relaxation of the UDP checksum in RFC 6935, and keep the existing text.
Fred, RFC 2473 does not mention checksums. Thanks, Carlos. > On Mar 30, 2015, at 7:47 PM, Black, David <[email protected]> wrote: > > > Also, why would you object to 3b? The packet ends up at the right node, > > just via an unexpected route. > > That assertion is based on the assumption that the payload destination > address is worldwide unique. > > There are lots of counterexamples that void the assumption, e.g., 10.0.0.0/8. > > Thanks, > --David > > From: Lucy yong [mailto:[email protected] <mailto:[email protected]>] > Sent: Monday, March 30, 2015 6:31 PM > To: Ronald Bonica; Zuniga, Juan Carlos; [email protected] > <mailto:[email protected]>; [email protected] <mailto:[email protected]>; Black, David > Cc: [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6 > > Hi Ron, > > 3b) is the concern. GRE payload may be non-IP type. If a gre-in-ipv6 tunnel > is used for mux of different payload types, the outcome may be unknown and > can be unacceptable upon IP address and/or GRE header are corrupted. > > Lucy > > > > From: Ronald Bonica [mailto:[email protected] <mailto:[email protected]>] > Sent: Monday, March 30, 2015 5:14 PM > To: Lucy yong; Zuniga, Juan Carlos; [email protected] > <mailto:[email protected]>; [email protected] <mailto:[email protected]>; Black, David > Cc: [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6 > > Lucy, > > Why would you object to 3a? Dropping the packet is the preferred behavior? > > Also, why would you object to 3b? The packet ends up at the right node, just > via an unexpected route. Recall that the destination address in the payload > header is protected by the UDP/TCP checksum. > > Are you thinking that there might be a 3c)? > > Ron > > > From: Lucy yong [mailto:[email protected] <mailto:[email protected]>] > Sent: Monday, March 30, 2015 6:05 PM > To: Ronald Bonica; Zuniga, Juan Carlos; [email protected] > <mailto:[email protected]>; [email protected] <mailto:[email protected]>; Black, David > Cc: [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6 > > Hi Ron, > > 1) and 2 ) are fine. IMO: 3) works under certain conditions but not all. > > I add David Black (TSVWG chair) to the thread. He can provide the thorough > check. > > Regards, > Lucy > > From: Ronald Bonica [mailto:[email protected] <mailto:[email protected]>] > Sent: Monday, March 30, 2015 4:49 PM > To: Lucy yong; Zuniga, Juan Carlos; [email protected] > <mailto:[email protected]>; [email protected] <mailto:[email protected]> > Cc: [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6 > > Lucy, > > Would the following text work? > > OLD> > Because the IPv6 delivery header does not include a checksum of its > own, it is subject to corruption. However, even if the delivery > header is corrupted, to likelihood of that corruption resulting in > misdelivery of the payload is extremely low. > <OLD > > NEW> > Because the IPv6 delivery header does not include a checksum of its > own, the destination address in the delivery header is subject to > corruption. If the destination address in the deliver header is corrupted, > the following outcomes are possible: > > 1) The delivery packet is dropped because the new destination address is > unreachable > 2) The delivery packet is dropped because the new destination address is > reachable, but that node is not configured to process GRE delivery packets > from the ingress > 3) The delivery packet is processed by a GRE egress other than that > which was originally specified by the GRE ingress. Processing options are: > a. The payload packet is dropped because the payload destination is > unreachable from the node that processed the delivery packet > b. The payload packet is delivered to its intended destination because > the payload destination is reachable from the node that processed the > delivery packet > > All of these outcomes are acceptable. > > <NEW > > Ron > > From: Lucy yong [mailto:[email protected] <mailto:[email protected]>] > Sent: Monday, March 30, 2015 4:50 PM > To: Zuniga, Juan Carlos; [email protected] <mailto:[email protected]>; > [email protected] <mailto:[email protected]> > Cc: [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6 > > Thanks authors to add section 4.1. > > I am not sure if the statement of “However, even if the delivery header is > corrupted, to likelihood of that corruption resulting in misdelivery of the > payload is extremely low.” is proper. IPv6 requires the end point/upper layer > to deal with the header corruption. Could we state that this is the > difference from gre-in-ipv4 instead? > > Lucy > > > From: Int-area [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Zuniga, Juan Carlos > Sent: Monday, March 30, 2015 3:27 PM > To: [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > Cc: [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > Subject: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 > > Dear Int-Area and 6man WGs, > > At the Int-Area WG meeting in Dallas there were some comments on > draft-ietf-intarea-gre-ipv6. It was decided to submit the document for WG > Last Call to the Int-Area & 6man WGs as soon as the agreed changes were made. > > The document has now been updated accordingly, so this email starts an > Int-Area/6man WGs Last Call on: > > http://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-04 > <http://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-04> > > Please respond to this email to support the document and/or send comments by > 2015-04-06. > > In addition, to satisfy RFC 6702 "Promoting Compliance with Intellectual > Property Rights (IPR)": > Are you personally aware of any IPR that applies to > draft-ietf-intarea-gre-ipv6? > If so, has this IPR been disclosed in compliance with IETF IPR rules? > (See RFCs 3979, 4879, 3669, and 5378 for more details.) > > Best, > > Juan Carlos Zuniga > (as Int-Area WG co-chair) > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
