Re: Death by extension header (was:RE: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt)

[Toerless Eckert <[e-mail]>]

Robert: i think this is the core question, and i don't think the answer
is simple or that we can have a generic one. I think we need to test possible text.

For my beloved simple example of router-alert, requirements i already mentioned
in a prior email here could be e.g.:

- A packet with router alert and a specific "value" field MUST be forwarded
  at "roughly" same performance as the same packet without the rouer alert IF
  the "value" function is not enabled/configured.  (roughly = 80% or better).

- Enabling a router-alert "value1" functionality MUST NOT impact the performance
  with which packets with a non-enabled "value2" router alert option are forwarded.

That looks like the most simple, first type of performance requirement to discuss,
if we ever would feel safe to write something like that into a new RFC for a new
router-alert like forwarding plane feature. If we are not, then IMHO we are
effectively aborting a solution like router-alert.
  
There are a lot more difficult questions to answer, but i think it would be highly
worthwhile to try. Relative performance requirements are always a good trick too...

Cheers
    Toerless

On Tue, Jul 14, 2020 at 09:39:45PM +0200, Robert Raszuk wrote:
> I am watching this thread and have one question ... how any draft can
> mandate to any implementation how it should process a packet ?
> 
> One implementation can use 100% programmable hardware, the other can not.
> Some process all packets in CPUs. Some may offload some processing to on
> line card CPU vs punting it to RE/RP.
> 
> Some may punt only first packet and then install forwarding state in the
> dataplane so any subsequent packets are fully hardware switched.
> 
> I am really not sure what is the value of this thread ....
> 
> Many thx,
> R.
> 
> 
> 
> 
> 
> 
> 
> 
> On Tue, Jul 14, 2020 at 9:24 PM Tom Herbert <[e-mail]> wrote:
> 
> > On Tue, Jul 14, 2020 at 12:03 PM Jakob Heitz (jheitz)
> > <jheitz=[e-mail]> wrote:
> > >
> > > BFD is a control function by definition, but is executed on the line
> > card.
> > > Is it in the data plane or the control plane?
> > > A label action that causes a second lookup may occur in one pass or
> > > may require to recirculate the packet for a second pass.
> > > To walk the list of extension headers to find the TCP ports to run an ACL
> > > may be done inline or require more passes.
> > > How slow is the slow path?
> > >
> >
> > There was a time when TCP SYNs were processed in the slow control
> > plane path, but then that gave rise to some very effective SYN attacks
> > and we quickly realized that they really need to be processed in the
> > fast path. Subsequently, we have seen this story line repeat itself
> > time and time again at several levels of the stack: "slow path" in the
> > data path == "DOS vector" in the data path. The answer is either to
> > change the implementation to be able to process more efficiently, or
> > to limit the processing it's willing to do which is okay if the
> > potential limits are commonly understood.
> >
> > Tom
> >
> > > Regards,
> > > Jakob.
> > >
> > > -----Original Message-----
> > > From: ipv6 <[e-mail]> On Behalf Of Toerless Eckert
> > > Sent: Tuesday, July 14, 2020 12:36 AM
> > > To: Gyan Mishra <[e-mail]>
> > > Cc: Ron Bonica <rbonica=[e-mail]>; [e-mail]
> > > Subject: Re: Death by extension header (was:RE: New Version Notification
> > for draft-li-6man-hbh-fwd-hdr-00.txt)
> > >
> > > Hi Gyan,
> > >
> > > On Tue, Jul 14, 2020 at 02:37:12AM -0400, Gyan Mishra wrote:
> > > > >From a historical perspective the slow path and fast path has some
> > vendor
> > > > connotations into it ???cxxxx???.
> > >
> > > I think its used pretty consistently throughout the industry.
> > > If you have an example of a router that has something other vendors
> > > would call slowpath but calls it differently, i would be interested to
> > > know such alternative terms.
> > >
> > > > I think any document within the IETF  should stay clear of anything
> > that is
> > > > a vendor terminology.
> > >
> > > Definitely agreed if something is really specific to a subset of vendors
> > > instead of the most widely used term. I think its the most widely used
> > term.
> > >
> > > > The concept of ???punt??? meanIng send to control plane also has vendor
> > > > connotation and should not be used.
> > >
> > > I think the same applies here as what i said above for slow/fast path.
> > >
> > > Btw: these are just comments about my best understanding about
> > terminology.
> > > Not an endorsement to base any upcoming work on those terms. I already
> > > sent emails as to the opposite.
> > >
> > > > I personally like control plane and data plane processing of extension
> > > > headers.
> > >
> > > Do you have a good definition for control-plane and data-plane
> > processing ?
> > > E.g.: inband-signaling, is that decidedly control-plane for data-plane
> > > to you ?
> > >
> > > Cheers
> > >    Toerless
> > >
> > > > Gyan
> > > >
> > > > On Mon, Jul 13, 2020 at 11:35 PM Pengshuping (Peng Shuping) <
> > > > [e-mail]> wrote:
> > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: ipv6 [mailto:[e-mail]] On Behalf Of Tom Herbert
> > > > > > Sent: Tuesday, July 14, 2020 3:31 AM
> > > > > > To: Toerless Eckert <[e-mail]>
> > > > > > Cc: Ron Bonica <rbonica=[e-mail]>;
> > [e-mail]
> > > > > > Subject: Re: Death by extension header (was:RE: New Version
> > Notification
> > > > > > for draft-li-6man-hbh-fwd-hdr-00.txt)
> > > > > >
> > > > > > On Mon, Jul 13, 2020 at 12:18 PM Toerless Eckert <[e-mail]>
> > wrote:
> > > > > > >
> > > > > > > And now find me any single IETF RFC that even uses the term
> > slow-path
> > > > > > > and fast-path to formalize requirements against them. We are
> > just not
> > > > > > > explicit enough about this. Hence my example of redooing
> > router-alert
> > > > > > > as the most simple example. Not that i think this would be most
> > > > > > > important, but just to make the community consider that we need
> > to be
> > > > > > > more diligent about protocol specs in this respect.
> > > > > > >
> > > > > >
> > > > > > Toerless,
> > > > > >
> > > > > > I wouldn't expect any IETF to use the term "slow path" and "fast
> > path".
> > > > > RFCs
> > > > > > tend to describe protocol behavior and generally themselves don't
> > care
> > > > > > whether they are processed in a slow path or fast path as long as
> > the
> > > > > > external behavior is conformant. If you want to make these terms
> > > > > explicit it
> > > > > > seems like we would need to quantify in exact terms what a slow
> > path is
> > > > > and
> > > > > > exactly what a fast path is-- that is, they need normative
> > definitions
> > > > > if we are
> > > > > > to set normative requirements around them.
> > > > >
> > > > > But do we still need to differentiate "control plane" and "forwarding
> > > > > plane"? The processing capability in bps and pps of the two planes
> > are
> > > > > different, so the corresponding terms are used as "slow path" and
> > "fast
> > > > > path", respectively.
> > > > >
> > > > > There are some HBH options such as RA* that carry the information
> > that
> > > > > need to be consumed by the "control plane", so they will be sent to
> > the
> > > > > "control plane" anyway. While other HBH options carry the
> > information that
> > > > > will not be consumed by the "control plane" but still sent to the
> > "control
> > > > > plane" / "slow path", which cause problems.
> > > > >
> > > > > *
> > > > >
> > https://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-values.xhtml#ipv6-routeralert-values-1
> > > > >
> > > > > Shuping
> > > > >
> > > > > >
> > > > > > Tom
> > > > > >
> > > > > > > Some maximum amount of fast-path extensions is already in specs
> > as an
> > > > > > > example, but it too is not comprehensive enough to feel more
> > confident
> > > > > > > about safe extensibility.
> > > > > > >
> > > > > > > And we need to break free of the rfc8200 constraints whenever we
> > > > > > > deploy the network protocol in controlled networks. rfc8200 is
> > such a
> > > > > > > career limiter when comparing IPv6 with MPLS for this type of
> > > > > > > use-cases. Not to speak of the unnecessary long addresses.
> > > > > > >
> > > > > > > Oh well...
> > > > > > >
> > > > > > > Cheers
> > > > > > >     Toerless
> > > > > > >
> > > > > > > On Fri, Jul 10, 2020 at 06:43:59PM +0000, Ron Bonica wrote:
> > > > > > > > Tom,
> > > > > > > >
> > > > > > > > Given that you parse the extension header chain on the fast
> > path, HBH
> > > > > > and destination options can be categorized as follows:
> > > > > > > >
> > > > > > > > 1) unrecognized (ACT 00, 01, 10, and 11)
> > > > > > > > 2) recognized and processed on the fast path
> > > > > > > > 3) recognized and processed on the slow path
> > > > > > > >
> > > > > > > > Types 1 and 2 cannot be used in a DoS attack, because they are
> > never
> > > > > > sent to the slow path. Type 3 is the dangerous one.
> > > > > > > >
> > > > > > > > I think that an implementation is safe if it only recognizes
> > options
> > > > > that it
> > > > > > can process on the fast path. It may also be safe if it severely
> > rate
> > > > > limits
> > > > > > packets as it sends them to the slow path.
> > > > > > > >
> > > > > > > >
> > > > > > > > Ron
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Juniper Business Use Only
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Tom Herbert <[e-mail]>
> > > > > > > > Sent: Friday, July 10, 2020 2:29 PM
> > > > > > > > To: Ron Bonica <[e-mail]>
> > > > > > > > Cc: Pengshuping (Peng Shuping) <[e-mail]>;
> > > > > > > > [e-mail]
> > > > > > > > Subject: Re: Death by extension header (was:RE: New Version
> > > > > > > > Notification for draft-li-6man-hbh-fwd-hdr-00.txt)
> > > > > > > >
> > > > > > > > [External Email. Be cautious of content]
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Jul 10, 2020 at 11:18 AM Ron Bonica <
> > [e-mail]>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Tom,
> > > > > > > > >
> > > > > > > > > I am forking a new thread since this is not directly related
> > to
> > > > > Shuping's
> > > > > > draft.
> > > > > > > > >
> > > > > > > > > Any variable length extension header can be used in a DoS
> > attack.
> > > > > So, if
> > > > > > a node encounters a packet that satisfies any of the following
> > criteria,
> > > > > it
> > > > > > should discard the packet and send an ICMP message as described in
> > > > > >
> > > > >
> > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-herbert-6ma
> > > > > > n-icmp-limits-03__;!!NEt6yMaO-gk!XnKPvkz9vBtVNlSCx0SqcojVpo2uBgeSDJ
> > > > > > zZEJa2fLd1NTKb53H0w3Ue2Xxv7iGB$ .
> > > > > > > > >
> > > > > > > > > - The extension header chain is longer than the node can
> > process
> > > > > > > > > - An individual extension header is longer than the node can
> > > > > > > > > process
> > > > > > > > > - The total number of options contained by all instances of
> > the
> > > > > HBH and
> > > > > > Destination Options header exceeds the number or options that the
> > node
> > > > > > can process.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Ron,
> > > > > > > >
> > > > > > > > Right, those are the ICMP errors for the allowance to drop or
> > ignore
> > > > > > extension headers in section 5.3 of RFC8504, there's also default
> > limits
> > > > > > suggested in that doc. Do you think this is sufficient in routers
> > to get
> > > > > past the
> > > > > > DOS concern?
> > > > > > > >
> > > > > > > > Tom
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Ron
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Juniper Business Use Only
> > > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Tom Herbert <[e-mail]>
> > > > > > > > > Sent: Friday, July 10, 2020 1:13 PM
> > > > > > > > > To: Ron Bonica <[e-mail]>
> > > > > > > > > Cc: Pengshuping (Peng Shuping) <[e-mail]>;
> > > > > > > > > [e-mail]
> > > > > > > > > Subject: Re: New Version Notification for
> > > > > > > > > draft-li-6man-hbh-fwd-hdr-00.txt
> > > > > > > > >
> > > > > > > > > [External Email. Be cautious of content]
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Jul 10, 2020 at 7:59 AM Ron Bonica
> > > > > > <rbonica=[e-mail]> wrote:
> > > > > > > > > >
> > > > > > > > > > Peng,
> > > > > > > > > >
> > > > > > > > > > While your solution may require refinement, I think that
> > you have
> > > > > > latched on to a problem that needs to be solved. HBH Options, as
> > they
> > > > > were
> > > > > > originally conceived in RFC 1883, are very useful.
> > > > > > > > > >
> > > > > > > > > > When IPv6 was first implemented on high-speed routers
> > (circa
> > > > > 2000),
> > > > > > HBH options were not yet well-understood and ASICs were not so
> > capable as
> > > > > > they are today. So, early IPv6 implementation dispatched all
> > packet that
> > > > > > contain HBH options to their slow path. In these implementations,
> > a large
> > > > > > flow of IPv6 packets could congest the slow path, causing other
> > critical
> > > > > > functions that are executed on the slow path to fail. These
> > critical
> > > > > functions
> > > > > > include routing and network management.
> > > > > > > > > >
> > > > > > > > > > To mitigate this DoS vulnerability, many operators deployed
> > > > > Access
> > > > > > Control Lists (ACLs) that discard all packets containing HBH
> > Options.
> > > > > This
> > > > > > introduced a circular problem:
> > > > > > > > > >
> > > > > > > > > > - An implementation problem caused HBH to become a DoS
> > vector
> > > > > > > > > > - Because HBH was a DoS vector, network operators deployed
> > ACLs
> > > > > > > > > > that discard packets containing HBH
> > > > > > > > > > - Because network operators deployed ACLs that discard
> > packets
> > > > > > > > > > containing HBH, network designers stopped defining new HBH
> > > > > > > > > > Options
> > > > > > > > > > - Because network designers stopped defining new HBH
> > Options,
> > > > > > > > > > the community was not motivated to fix the implementation
> > > > > > > > > > problem that cause HBH to become a DoS vector
> > > > > > > > > >
> > > > > > > > > > If we can fix the implementation problem that caused HBH to
> > > > > > become a DoS vector, we can break this cycle and start using HBH
> > Options.
> > > > > > > > > >
> > > > > > > > > Ron,
> > > > > > > > >
> > > > > > > > > I think there were "protocol problems" in the original
> > design of
> > > > > HBH.
> > > > > > > > > The requirement that _all_ routers in the path process
> > Hop-by-Hop
> > > > > > options was in retrospect too austere, and the possibility that an
> > > > > attacker
> > > > > > could stuff a packet with hundreds of bogus options, only limited
> > by MTU,
> > > > > > was, again in retrospect, a pretty obvious DOS vector.
> > > > > > > > > I believe these problems have been addressed in RFC8200 and
> > > > > > RFC8504.
> > > > > > > > > We certainly welcome the feedback from router vendors
> > whether these
> > > > > > mitigations are sufficient to make HBH options deployable.
> > > > > > > > >
> > > > > > > > > Tom
> > > > > > > > >
> > > > > > > > > > Let's continue to work on a solution.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > Ron
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Juniper Business Use Only
> > > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: ipv6 <[e-mail]> On Behalf Of
> > Pengshuping
> > > > > > > > > > (Peng
> > > > > > > > > > Shuping)
> > > > > > > > > > Sent: Thursday, July 2, 2020 12:07 PM
> > > > > > > > > > To: [e-mail]
> > > > > > > > > > Subject: FW: New Version Notification for
> > > > > > > > > > draft-li-6man-hbh-fwd-hdr-00.txt
> > > > > > > > > >
> > > > > > > > > > [External Email. Be cautious of content]
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Hi Folks,
> > > > > > > > > >
> > > > > > > > > > We have just uploaded a new draft aiming to analyze and
> > tackle
> > > > > the
> > > > > > issues faced by the Hop-by-Hop Options Header, which has been
> > sparsely
> > > > > > used without any form of large scale deployment.
> > > > > > > > > >
> > > > > > > > > > However, as IPv6 is being rapidly and widely deployed
> > worldwide,
> > > > > > more and more new services that requires hop-by-hop forwarding
> > process
> > > > > > behavior are emerging, and also the already defined over ten HBH
> > Options
> > > > > > are going to be used widely in practice.
> > > > > > > > > >
> > > > > > > > > > We look forward to hearing your feedback and comments, and
> > try to
> > > > > > release the benefits that could be provided by HBH Options header
> > > > > > altogether.
> > > > > > > > > >
> > > > > > > > > > Best regards,
> > > > > > > > > > Shuping
> > > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: [e-mail] [mailto:
> > [e-mail]]
> > > > > > > > > > Sent: Thursday, July 2, 2020 11:31 PM
> > > > > > > > > > To: Lizhenbin <[e-mail]>; Pengshuping (Peng
> > Shuping)
> > > > > > > > > > <[e-mail]>
> > > > > > > > > > Subject: New Version Notification for
> > > > > > > > > > draft-li-6man-hbh-fwd-hdr-00.txt
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > A new version of I-D, draft-li-6man-hbh-fwd-hdr-00.txt has
> > been
> > > > > > successfully submitted by Shuping Peng and posted to the IETF
> > repository.
> > > > > > > > > >
> > > > > > > > > > Name:           draft-li-6man-hbh-fwd-hdr
> > > > > > > > > > Revision:       00
> > > > > > > > > > Title:          Hop-by-Hop Forwarding Options Header
> > > > > > > > > > Document date:  2020-07-03
> > > > > > > > > > Group:          Individual Submission
> > > > > > > > > > Pages:          10
> > > > > > > > > > URL:
> > > > > >
> > > > >
> > https://urldefense.com/v3/__https://www.ietf.org/internet-drafts/draft-li-6
> > > > > > man-hbh-fwd-hdr-00.txt__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00d
> > > > > > bzuCmO7S4CG2fZYHGYeOXYwVmtNTFnzgB-bqLrg$
> > > > > > > > > > Status:
> > > > > >
> > > > >
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-li-6man-
> > > > > > hbh-fwd-hdr/__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S
> > > > > > 4CG2fZYHGYeOXYwVmtNTFnzgM5iPE22$
> > > > > > > > > > Htmlized:
> > > > > >
> > > > >
> > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-li-6man-hbh-f
> > > > > > wd-hdr-00__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S4C
> > > > > > G2fZYHGYeOXYwVmtNTFnzgPvsH43l$
> > > > > > > > > > Htmlized:
> > > > > >
> > > > >
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-li-
> > > > > > 6man-hbh-fwd-hdr__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuC
> > > > > > mO7S4CG2fZYHGYeOXYwVmtNTFnzgBQxbwZb$
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Abstract:
> > > > > > > > > >    RFC8200 specifies the HBH header that is assumed to be
> > > > > > processed by
> > > > > > > > > >    each hop in the delivery path of the packet.  However,
> > RFC8200
> > > > > > also
> > > > > > > > > >    expects that nodes processing the HBH header have been
> > > > > > explicitly
> > > > > > > > > >    configured to do so.  Therefore, it cannot be assumed
> > that a
> > > > > > HBH
> > > > > > > > > >    header present in the packet is processed.  It all
> > depends on
> > > > > the
> > > > > > > > > >    configuration of each node across the path.  Moreover,
> > in most
> > > > > > of
> > > > > > > > > >    networks today, the processing of the HBH header is
> > done in
> > > > > the
> > > > > > > > > >    control plane (slow processing path) which incurs
> > several
> > > > > > limitations
> > > > > > > > > >    among which resources consumption and security risk.
> > > > > > > > > >
> > > > > > > > > >    For these reasons, over time, the Hop-by-Hop Options
> > header
> > > > > > has been
> > > > > > > > > >    sparsely used without any form of large scale
> > deployment.
> > > > > Also,
> > > > > > most
> > > > > > > > > >    of already defined HBH options are forwarding options
> > which
> > > > > > contain
> > > > > > > > > >    forwarding plane information that needs not to be sent
> > to the
> > > > > > control
> > > > > > > > > >    plane.
> > > > > > > > > >
> > > > > > > > > >    This document proposes a new Hop-by-Hop Forwarding
> > Options
> > > > > > Header in
> > > > > > > > > >    order to carry Hop-by-Hop options that are solely
> > intended to
> > > > > > and
> > > > > > > > > >    processed by the forwarding plane.  This new HBH header
> > is
> > > > > > confined
> > > > > > > > > >    in and dedicated to the forwarding plane while the
> > current HBH
> > > > > > header
> > > > > > > > > >    can still be used for control plane options.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Please note that it may take a couple of minutes from the
> > time of
> > > > > > submission until the htmlized version and diff are available at
> > > > > tools.ietf.org.
> > > > > > > > > >
> > > > > > > > > > The IETF Secretariat
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > ----------------------------------------------------------------
> > > > > > > > > > ---- IETF IPv6 working group mailing list [e-mail]
> > > > > > > > > > Administrative
> > > > > > > > > > Requests:
> > > > > > > > > >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinf
> > > > > > > > > > o/ip
> > > > > > > > > > v6
> > > > > > > > > >
> > > > > > __;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S4CG2fZYHGYe
> > > > > > OXY
> > > > > > > > > > wVmt
> > > > > > > > > > NT
> > > > > > > > > > FnzgEBbFhyl$
> > > > > > > > > >
> > ----------------------------------------------------------------
> > > > > > > > > > ----
> > > > > > > > > >
> > > > > > > > > >
> > ----------------------------------------------------------------
> > > > > > > > > > ---- IETF IPv6 working group mailing list [e-mail]
> > > > > > > > > > Administrative
> > > > > > > > > > Requests:
> > > > > > > > > >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinf
> > > > > > > > > > o/ip
> > > > > > > > > > v6
> > > > > > > > > >
> > > > > > __;!!NEt6yMaO-gk!Qu9y9Ou2SvlYIZjMQa3hBXcu08HG3W4BBIcFoOHCfp41H
> > > > > > tk
> > > > > > > > > > dIYu
> > > > > > > > > > Ds
> > > > > > > > > > XM8uyxPWt9N$
> > > > > > > > > >
> > ----------------------------------------------------------------
> > > > > > > > > > ----
> > > > > > > >
> > --------------------------------------------------------------------
> > > > > > > > IETF IPv6 working group mailing list [e-mail]
> > Administrative
> > > > > > > > Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > > > > > >
> > --------------------------------------------------------------------
> > > > > > >
> > > > > > > --
> > > > > > > ---
> > > > > > > [e-mail]
> > > > > >
> > > > > >
> > --------------------------------------------------------------------
> > > > > > IETF IPv6 working group mailing list
> > > > > > [e-mail]
> > > > > > Administrative Requests:
> > https://www.ietf.org/mailman/listinfo/ipv6
> > > > > >
> > --------------------------------------------------------------------
> > > > >
> > > > > --------------------------------------------------------------------
> > > > > IETF IPv6 working group mailing list
> > > > > [e-mail]
> > > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > > > --------------------------------------------------------------------
> > > > >
> > > > --
> > > >
> > > > <http://www.verizon.com/>
> > > >
> > > > *Gyan Mishra*
> > > >
> > > > *Network Solutions A**rchitect *
> > > >
> > > >
> > > >
> > > > *M 301 502-134713101 Columbia Pike *Silver Spring, MD
> > >
> > > --
> > > ---
> > > [e-mail]
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > [e-mail]
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > [e-mail]
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


-- 
---
[e-mail]