Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed

["Templin, Fred L" <[e-mail]>]

Following up on my own:

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Templin, Fred L
> Sent: Tuesday, February 05, 2013 8:36 AM
> To: Nalini Elkins; Ackermann, Michael; IETF v6ops list
> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed
> 
> Hi Nalini,
> 
> > -----Original Message-----
> > From: Nalini Elkins [mailto:[e-mail]]
> > Sent: Monday, February 04, 2013 8:21 PM
> > To: Templin, Fred L; Ackermann, Michael; IETF v6ops list
> > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed
> >
> > Fred,
> >
> > Thanks so much for your comments.  I have not yet finished completely
> > analyzing your RFC but I have some questions for you:
> >
> > In your SEAL RFC, would an IPID would only exist in the tunneled header
> > used to traverse the MPLS backbone network?
> 
> SEAL deals with IP-in-IP encapsulation. With SEAL, there is an
> outer IP header, a mid-layer SEAL header and an inner IP header.
> The outer IP header and SEAL header are only present over the
> portion of the path that traverses the region of encapsulation
> (aka the "tunnel"). The inner IP header is present over the full
> end-to-end path.

SEAL is also compatible with a transport mode of operation in which
the end systems would need to negotiate the use of a SEAL header that
travels end-to end. Sort of how IPsec supports both tunnel- and
transport modes of operation.

Thanks - Fred
[e-mail]

> > Would every IPv6 packet then need this header?
> 
> Only those IPv6 packets that are taken in for encapsulation.
> 
> Note that if you wanted to require all IPv6 packets to include a
> fragment header, there is a draft that talks about "atomic IPv6
> fragments":
> 
> https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments/
> 
> 
> Thanks - Fred
> [e-mail]
> 
> > Thanks,
> >
> >
> > Nalini Elkins
> > Inside Products, Inc.
> > [phone]
> > www.insidethestack.com
> >
> >
> >
> > ----- Original Message -----
> > From: "Templin, Fred L" <[e-mail]>
> > To: "Ackermann, Michael" <[e-mail]>; IETF v6ops list
> > <[e-mail]>
> > Cc:
> > Sent: Monday, February 4, 2013 10:17 AM
> > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed
> >
> > Hi Michael,
> >
> > Forgot to mention that here is another one you would want to cite:
> >
> > http://datatracker.ietf.org/doc/rfc4963/
> >
> > Thanks - Fred
> >
> > > -----Original Message-----
> > > From: Ackermann, Michael [mailto:[e-mail]]
> > > Sent: Monday, February 04, 2013 9:53 AM
> > > To: Templin, Fred L; IETF v6ops list
> > > Subject: RE: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed
> > >
> > > Thanks for your comments Fred!
> > >
> > > The first draft you reference seems to highlight the need for an IPID
> > > field larger than 16 bits (v4) or 32 bits (v6), due to the much faster
> > > networks we have today.   We agree and that is very lightly referenced
> > in
> > > our RFC.   The reason for only lightly, is that we chose to focus on
> the
> > > need for IPID at all, since many at the IETF did not agree this was an
> > > issue when we first introduced it.   Our original proposal suggested
> > going
> > > to 64 bits as part of the solution, but for now we have backed off on
> > > solutions and are focused on convincing the IETF that the elimination
> of
> > > IPID as a diagnostic facility, would be bad for end user
> organizations.
> > >
> > > The second draft you referenced is one I was not aware of but is very
> > > impressive and well written!   I know it was focused on tunnels and
> > > encapsulation, but among many other things it seems to promote the
> value
> > > of uniquely identifying packets, in particular ones that could be
> > > duplicate, improper or even malicious.    If I am interpreting
> properly,
> > > then we are in full agreement.
> > >
> > > Our main issue is that information such as provided by IPID can be
> > > critical to reliably running sophisticated networks today.
> > >
> > > Thanks again!
> > >
> > > Mike
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On Behalf
> > Of
> > > Templin, Fred L
> > > Sent: Monday, February 04, 2013 11:51 AM
> > > To: IETF v6ops list
> > > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed
> > >
> > > Hi,
> > >
> > > Two drafts the authors should be aware of are "Updated Specification
> of
> > > the IPv4 ID Field":
> > >
> > > https://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update/
> > >
> > > and "The Subnetwork Encapsulation and Adapation Layer (SEAL)":
> > >
> > > https://datatracker.ietf.org/doc/draft-templin-intarea-seal/
> > >
> > > The former is a revised specification of the use of the IPv4 ID field
> > and
> > > defines the cases in which the ID field does and does not contain
> useful
> > > information. The latter is a means for adding a 32-bit ID field during
> > > encapsulation, where the ID appears in an extension header similar to
> > the
> > > way the IPv6 fragment header currently appears.
> > >
> > > Point being that the IPv4 ID was never intended for purposes such as
> > > ensuring uniqueness other than for the fragmentation and reassembly
> > > process. And, for IPv6, there are already ways to add an ID to a
> packet
> > if
> > > one is needed.
> > >
> > > Thanks - Fred
> > > [e-mail]
> > > _______________________________________________
> > > v6ops mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/v6ops
> > >
> > >
> > > The information contained in this communication is highly confidential
> > and
> > > is intended solely for the use of the individual(s) to whom this
> > > communication is directed. If you are not the intended recipient, you
> > are
> > > hereby notified that any viewing, copying, disclosure or distribution
> of
> > > this information is prohibited. Please notify the sender, by
> electronic
> > > mail or telephone, of any unintended receipt and delete the original
> > > message without making any copies.
> > >
> > >  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan
> > are
> > > nonprofit corporations and independent licensees of the Blue Cross and
> > > Blue Shield Association.
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops