Math Forum Discussions

Posts: 791
Registered: 9/1/10

Re: P=NP Proof Published at CERN
Posted: Jan 6, 2013 5:00 AM

Plain Text

On Thursday, September 10, 2009 8:20:00 PM UTC-7, marty....@gmail.com wrote:
> DO YOU NOT DARE TELL ME MY WORK IS NOT COMPLETE WHEN IT IS PERFECT WHO ARE YOU TO DEAL IN JUDGMENT/?
>
> if (creation && object of art && algorithm && one's own algorithm) {
> include * an algorist *
> } elseif (!creation || !object of art || !algorithm || !one's own algorithm) {
> exclude * not an algorist *
> }
>
>
>
> > On May 28, 4:
>
>
> 34 pm, Martin Michael Musatov
> > <marty.musa...@gmail.com>
> > wrote:
> > > Math Forum Discussions Discussions
> > + sci.math.symbolic | Google Groups > The polynomials
> > in y, P(n,y) := #i^n/n * B(n,
> > +...mathforum.org/...thread.jspa Math Forum
> > Discussions ... sci.math.* » sci.math.
> > Topic: P=NP Proof Published at CERN ...
> > Martin Musatov a écrit
> > :...http://mathforum.orgthrea.jspa more >
> > >
> > > An informal and highly experimental, unorthodox
> > proof P=NP has been
> > > published on CERN preprints.The Internet was
> > invented at CERN.
> > > Proof P=NP:
> > >
> > >
> > http://cdsweb.cern.ch/record/1164206/files/s1-ln575821
> > >
> > 0-9223534-1939656818Hwf-1468147288IdV-1521282711575821
> > 0PDF_HI0001.pdf
> > >
> > > It is mine, and it is not published anywhere
> > else.My purpose in posting
> > > it here is for feedback and suggestions on how to
> > strengthen it.
> >
> > If it needs strengthening, it is not a proof.
> >
> > > I would specifically, as was my intention with this
> > experiment,
> > > like feedback from anyone interested in the
> > methodology used and
> > > recognition of how I pursued and attained a broadly
> > accepted
> > > peer-reviewed published proof building on this
> > basic result.
> > >
> > > Thank you,
> > >
> > > Martin Musatov
> > > m e a m i[at]vzw[dot]blackberry[dot]net.
> >
> >
>
> draft-ietf-ipv6-deprecate-rh0 rfc5095.txt
>
> Network Working Group J. Abley Network Working Group J. Abley
> Internet-Draft Afilias Request for Comments: 5095 Afilias
> Updates: 2460, 4294 P. Savola Updates: 2460, 4294 P. Savola
> (if approved) CSC/FUNET Category: Standards Track CSC/FUNET
> Intended status: Standards Track G. Neville-Neil G. Neville-Neil
> Expires: December 28, 2007 Neville-Neil Consulting Neville-Neil Consulting
> June 26, 2007 December 2007
>
> Deprecation of Type 0 Routing Headers in IPv6 Deprecation of Type 0 Routing Headers in IPv6
> draft-ietf-ipv6-deprecate-rh0-01
>
> Status of this Memo Status of This Memo
>
> By submitting this Internet-Draft, each author represents that any
> applicable patent or other IPR claims of which he or she is aware
> have been or will be disclosed, and any of which he or she becomes
> aware will be disclosed, in accordance with Section 6 of BCP 79.
>
> Internet-Drafts are working documents of the Internet Engineering
> Task Force (IETF), its areas, and its working groups. Note that
> other groups may also distribute working documents as Internet-
> Drafts.
>
> Internet-Drafts are draft documents valid for a maximum of six months
> and may be updated, replaced, or obsoleted by other documents at any
> time. It is inappropriate to use Internet-Drafts as reference
> material or to cite them other than as "work in progress."
>
> The list of current Internet-Drafts can be accessed at
> http://www.ietf.org/ietf/1id-abstracts.txt.
>
> The list of Internet-Draft Shadow Directories can be accessed at
> http://www.ietf.org/shadow.html.
>
> This Internet-Draft will expire on December 28, 2007.
>
> Copyright Notice
>
> Copyright (C) The IETF Trust (2007). This document specifies an Internet standards track protocol for the
> Internet community, and requests discussion and suggestions for
> improvements. Please refer to the current edition of the "Internet
> Official Protocol Standards" (STD 1) for the standardization state
> and status of this protocol. Distribution of this memo is unlimited.
>
> Abstract Abstract
>
> The functionality provided by IPv6's Type 0 Routing Header can be The functionality provided by IPv6's Type 0 Routing Header can be
> exploited in order to achieve traffic amplification over a remote exploited in order to achieve traffic amplification over a remote
> path for the purposes of generating denial-of-service traffic. This path for the purposes of generating denial-of-service traffic. This
> document updates the IPv6 specification to deprecate the use of IPv6 document updates the IPv6 specification to deprecate the use of IPv6
> Type 0 Routing Headers, in light of this security concern. Type 0 Routing Headers, in light of this security concern.
>
> Table of Contents Table of Contents
>
> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
> 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
> 3. Deprecation of RH0 . . . . . . . . . . . . . . . . . . . . . . 4 3. Deprecation of RH0 . . . . . . . . . . . . . . . . . . . . . . 3
> 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 3
> 4.1. Ingress Filtering . . . . . . . . . . . . . . . . . . . . . 4 4.1. Ingress Filtering . . . . . . . . . . . . . . . . . . . . . 3
> 4.2. Firewall Policy . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Firewall Policy . . . . . . . . . . . . . . . . . . . . . . 3
> 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
> 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
> 7. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
> 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
> 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
> 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 5
> Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 6
> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
> Intellectual Property and Copyright Statements . . . . . . . . . . 9
>
> 1. Introduction 1. Introduction
>
> [RFC2460] defines an IPv6 extension header called "Routing Header", [RFC2460] defines an IPv6 extension header called "Routing Header",
> identified by a Next Header value of 43 in the immediately preceding identified by a Next Header value of 43 in the immediately preceding
> header. A particular Routing Header subtype denoted as "Type 0" is header. A particular Routing Header subtype denoted as "Type 0" is
> also defined. Type 0 Routing Headers are referred to as "RH0" in also defined. Type 0 Routing Headers are referred to as "RH0" in
> this document. this document.
>
> A single RH0 may contain multiple intermediate node addresses, and A single RH0 may contain multiple intermediate node addresses, and
> the same address may be included more than once in the same RH0. the same address may be included more than once in the same RH0.
> This allows a packet to be constructed such that it will oscillate This allows a packet to be constructed such that it will oscillate
> between two RH0-processing hosts or routers many times. This allows between two RH0-processing hosts or routers many times. This allows
> a stream of packets from an attacker to be amplified along the path a stream of packets from an attacker to be amplified along the path
> between two remote routers, which could be used to cause congestion between two remote routers, which could be used to cause congestion
> along arbitrary remote paths and hence act as a denial-of-service along arbitrary remote paths and hence act as a denial-of-service
> mechanism. 88-fold amplification has been demonstrated using this mechanism. An 88-fold amplification has been demonstrated using this
> technique [CanSecWest07]. technique [CanSecWest07].
>
> This attack is particularly serious in that it affects the entire This attack is particularly serious in that it affects the entire
> path between the two exploited nodes, not only the nodes themselves path between the two exploited nodes, not only the nodes themselves
> or their local networks. Analogous functionality may be found in the or their local networks. Analogous functionality may be found in the
> IPv4 source route option, but the opportunities for abuse are greater IPv4 source route option, but the opportunities for abuse are greater
> with RH0 due to the ability to specify many more intermediate node with RH0 due to the ability to specify many more intermediate node
> addresses in each packet. addresses in each packet.
>
> The severity of this threat is considered to be sufficient to warrant The severity of this threat is considered to be sufficient to warrant
> deprecation of RH0 entirely. A side-effect is that this also deprecation of RH0 entirely. A side effect is that this also
> eliminates benign RH0 use-cases; however, such applications may be eliminates benign RH0 use-cases; however, such applications may be
> facilitated by future Routing Header specifications. facilitated by future Routing Header specifications.
>
> Potential problems with RH0 were identified in 2001 Potential problems with RH0 were identified in 2001 [Security]. In
> [I-D.savola-ipv6-rh-ha-security]. In 2002 a proposal was made to 2002 a proposal was made to restrict Routing Header processing in
> restrict Routing Header processing in hosts hosts [Hosts]. These efforts resulted in the modification of the
> [I-D.savola-ipv6-rh-hosts]. These efforts resulted in the Mobile IPv6 specification to use the type 2 Routing Header instead of
> modification of the Mobile IPv6 specification to use the type 2 RH0 [RFC3775]. Vishwas Manral identified various risks associated
> Routing Header instead of RH0 [RFC3775]. Vishwas Manral identified with RH0 in 2006 including the amplification attack; several of these
> various risks associated with RH0 in 2006 including the amplification vulnerabilities (together with other issues) were later documented in
> attack; several of these vulnerabilities (together with other issues) [RFC4942].
> were later documented in [I-D.ietf-v6ops-security-overview].
>
> A treatment of the operational security implications of RH0 was A treatment of the operational security implications of RH0 was
> presented by Philippe Biondi and Arnaud Ebalard at the CanSecWest presented by Philippe Biondi and Arnaud Ebalard at the CanSecWest
> conference in Vancouver, 2007 [CanSecWest07]. This presentation conference in Vancouver, 2007 [CanSecWest07]. This presentation
> resulted in widespread publicity for the risks associated with RH0. resulted in widespread publicity for the risks associated with RH0.
>
> This document updates [RFC2460] and [RFC4294]. This document updates [RFC2460] and [RFC4294].
>
> 2. Definitions 2. Definitions
>
> RH0 in this document denotes the IPv6 Extension Header type 43 RH0 in this document denotes the IPv6 Extension Header type 43
> ("Routing Header") variant 0 ("Type 0 Routing Header"), as defined in ("Routing Header") variant 0 ("Type 0 Routing Header"), as defined in
> [RFC2460]. [RFC2460].
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
>
> 3. Deprecation of RH0 3. Deprecation of RH0
>
> IPv6 nodes MUST NOT process RH0 in packets whose destination address An IPv6 node that receives a packet with a destination address
> in the IPv6 header is an address assigned to them. Such packets MUST assigned to it and that contains an RH0 extension header MUST NOT
> be processed according to the behaviour specified in Section 4.4 of execute the algorithm specified in the latter part of Section 4.4 of
> [RFC2460] for a datagram which includes an unrecognised Routing Type [RFC2460] for RH0. Instead, such packets MUST be processed according
> value, namely: to the behaviour specified in Section 4.4 of [RFC2460] for a datagram
> that includes an unrecognised Routing Type value, namely:
>
> If Segments Left is zero, the node must ignore the Routing header If Segments Left is zero, the node must ignore the Routing header
> and proceed to process the next header in the packet, whose type and proceed to process the next header in the packet, whose type
> is identified by the Next Header field in the Routing header. is identified by the Next Header field in the Routing header.
>
> If Segments Left is non-zero, the node must discard the packet and If Segments Left is non-zero, the node must discard the packet and
> send an ICMP Parameter Problem, Code 0, message to the packet's send an ICMP Parameter Problem, Code 0, message to the packet's
> Source Address, pointing to the unrecognised Routing Type. Source Address, pointing to the unrecognized Routing Type.
>
> IPv6 implementations are no longer required to implement RH0 in any IPv6 implementations are no longer required to implement RH0 in any
> way. way.
>
> 4. Operations 4. Operations
>
> 4.1. Ingress Filtering 4.1. Ingress Filtering
>
> It is to be expected that it will take some time before all IPv6 It is to be expected that it will take some time before all IPv6
> nodes are updated to remove support for RH0. Some of the uses of RH0 nodes are updated to remove support for RH0. Some of the uses of RH0
> described in [CanSecWest07] can be mitigated using ingress filtering, described in [CanSecWest07] can be mitigated using ingress filtering,
> as recommended in [RFC2827] and [RFC3704]. as recommended in [RFC2827] and [RFC3704].
>
> A site security policy intended to protect against attacks using RH0 A site security policy intended to protect against attacks using RH0
> SHOULD include the implementation of ingress filtering at the site SHOULD include the implementation of ingress filtering at the site
> border. border.
>
> 4.2. Firewall Policy 4.2. Firewall Policy
>
> Blocking all IPv6 packets which carry Routing Headers (rather than Blocking all IPv6 packets that carry Routing Headers (rather than
> specifically blocking type 0, and permitting other types) has very specifically blocking Type 0 and permitting other types) has very
> serious implications for the future development of IPv6. If even a serious implications for the future development of IPv6. If even a
> small percentage of deployed firewalls block other types of routing small percentage of deployed firewalls block other types of Routing
> headers by default, it will become impossible in practice to extend Headers by default, it will become impossible in practice to extend
> IPv6 routing headers. For example, Mobile IPv6 [RFC3775] relies upon IPv6 Routing Headers. For example, Mobile IPv6 [RFC3775] relies upon
> a type-2 RH; wide-scale, indescriminate blocking of Routing Headers a Type 2 Routing Header; wide-scale, indiscriminate blocking of
> will make Mobile IPv6 undeployable. Routing Headers will make Mobile IPv6 undeployable.
>
> Firewall policy intended to protect against packets containing RH0 Firewall policy intended to protect against packets containing RH0
> MUST NOT simply filter all traffic with a routing header; it must be MUST NOT simply filter all traffic with a Routing Header; it must be
> possible to disable forwarding of type 0 traffic without blocking possible to disable forwarding of Type 0 traffic without blocking
> other types of routing headers. In addition, the default other types of Routing Headers. In addition, the default
> configuration MUST permit forwarding of traffic using a RH other than configuration MUST permit forwarding of traffic using a Routing
> 0. Header other than 0.
>
> 5. Security Considerations 5. Security Considerations
>
> The purpose of this document is to deprecate a feature of IPv6 which The purpose of this document is to deprecate a feature of IPv6 that
> has been shown to have undesirable security implications. Specific has been shown to have undesirable security implications. Specific
> examples of vulnerabilities which are facilitated by the availability examples of vulnerabilities that are facilitated by the availability
> of RH0 can be found in [CanSecWest07]. In particular, RH0 provides a of RH0 can be found in [CanSecWest07]. In particular, RH0 provides a
> mechanism for traffic amplification, which might be used as a denial- mechanism for traffic amplification, which might be used as a denial-
> of-service attack. A description of this functionality can be found of-service attack. A description of this functionality can be found
> in Section 1. in Section 1.
>
> 6. IANA Considerations 6. IANA Considerations
>
> The IANA registry "Internet Protocol Version 6 (IPv6) Parameters" The IANA registry "Internet Protocol Version 6 (IPv6) Parameters"
> should be updated to reflect that variant 0 of IPv6 header-type 43 should be updated to reflect that variant 0 of IPv6 header-type 43
> ("Routing Header") is deprecated. ("Routing Header") is deprecated.
>
> 7. Acknowlegements 7. Acknowledgements
>
> This document benefits from the contributions of many IPV6 and V6OPS This document benefits from the contributions of many IPV6 and V6OPS
> working group participants, including Jari Arkko, Arnaud Ebalard, Tim working group participants, including Jari Arkko, Arnaud Ebalard, Tim
> Enos, Brian Haberman, Jun-ichiro itojun HAGINO, Bob Hinden, Thomas Enos, Brian Haberman, Jun-ichiro itojun Hagino, Bob Hinden, Thomas
> Narten, JINMEI Tatuya, David Malone, Jeroen Massar, Dave Thaler and Narten, Jinmei Tatuya, David Malone, Jeroen Massar, Dave Thaler, and
> Guillaume Valadon. Guillaume Valadon.
>
> 8. References 8. References
>
> 8.1. Normative References 8.1. Normative References
>
> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
> Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
>
> [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol,
> (IPv6) Specification", RFC 2460, December 1998. Version 6 (IPv6) Specification", RFC 2460,
> December 1998.
>
> [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
> April 2006. April 2006.
>
> 8.2. Informative References 8.2. Informative References
>
> [CanSecWest07] [CanSecWest07] Biondi, P. and A. Ebalard, "IPv6 Routing Header
> BIONDI, P. and A. EBALARD, "IPv6 Routing Header Security", Security", CanSecWest Security Conference 2007,
> CanSecWest Security Conference 2007, April 2007. April 2007.
>
> http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf
>
> [I-D.ietf-v6ops-security-overview] [Hosts] Savola, P., "Note about Routing Header Processing on
> Davies, E., "IPv6 Transition/Co-existence Security IPv6 Hosts", Work in Progress, February 2002.
> Considerations", draft-ietf-v6ops-security-overview-06
> (work in progress), October 2006.
>
> [I-D.savola-ipv6-rh-ha-security]
> Savola, P., "Security of IPv6 Routing Header and Home
> Address Options", draft-savola-ipv6-rh-ha-security-02
> (work in progress), March 2002.
>
> [I-D.savola-ipv6-rh-hosts]
> Savola, P., "Note about Routing Header Processing on IPv6
> Hosts", draft-savola-ipv6-rh-hosts-00 (work in progress),
> February 2002.
>
> [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
> Defeating Denial of Service Attacks which employ IP Source
> Address Spoofing", BCP 38, RFC 2827, May 2000.
>
> [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
> Networks", BCP 84, RFC 3704, March 2004.
>
> [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
> in IPv6", RFC 3775, June 2004.
>
> Appendix A. Change History
>
> This section to be removed prior to publication.
>
> 00 Strawman, draft-jabley-ipv6-rh0-is-evil, circulated to provoke
> discussion.
>
> 01 Clarified Section 3; presented more options in Section 4; added
> Pekka and George as authors. This document version was not widely
> circulated.
>
> 00 Renamed, draft-ietf-ipv6-deprecate-rh0, a candidate working group [RFC2827] Ferguson, P. and D. Senie, "Network Ingress
> document. Filtering: Defeating Denial of Service Attacks which
> employ IP Source Address Spoofing", BCP 38, RFC 2827,
> May 2000.
>
> 01-candidate-00 Incorporated text summarising some of the unwelcome [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
> uses of RH0; added some clariying text describing deprecation; Multihomed Networks", BCP 84, RFC 3704, March 2004.
> modified some ambiguous text in Section 4.2; added "Updates:
> 4294".
>
> 01-candidate-01 Incorporated contributions from working group: [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
> substantially reduced Section 5; clarified wording in Section 3. Support in IPv6", RFC 3775, June 2004.
>
> 01-candidate-02 Moved description of traffic amplification to [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6
> Section 1, and inserted a corresponding cross-reference in Transition/Co-existence Security Considerations",
> Section 5. Strengthened the language in Section 4.2 along the RFC 4942, September 2007.
> lines suggested by Thomas Narten. Small typos corrected. Added a
> further sentence in Section 4.1 intended to act as further
> encouragement for operators to implement [RFC3704].
>
> 01 Minor wordsmithing; removed some subjective language; adopted [Security] Savola, P., "Security of IPv6 Routing Header and Home
> "intermediate node" nomenclature instead of "waypoint"; shifted Address Options", Work in Progress, March 2002.
> some history from Section 7 to Section 1.
>
> Authors' Addresses Authors' Addresses
>
> Joe Abley Joe Abley
> Afilias Canada Corp. Afilias Canada Corp.
> Suite 204, 4141 Yonge Street Suite 204, 4141 Yonge Street
> Toronto, ON M2P 2A8 Toronto, ON M2P 2A8
> Canada Canada
>
> Phone: +1 416 673 4176 Phone: +1 416 673 4176
> Email: jabley@ca.afilias.info EMail: jabley@ca.afilias.info
>
> Pekka Savola Pekka Savola
> CSC/FUNET CSC/FUNET
> Espoo, Espoo,
> Finland Finland
>
> Email: psavola@funet.fi EMail: psavola@funet.fi
>
> George Neville-Neil George Neville-Neil
> Neville-Neil Consulting Neville-Neil Consulting
> 2261 Market St. #239 2261 Market St. #239
> San Francisco, CA 94114 San Francisco, CA 94114
> USA USA
>
> Email: gnn@neville-neil.com EMail: gnn@neville-neil.com
>
> Full Copyright Statement Full Copyright Statement
>
> Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
>
> This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
> contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
> retain all their rights. retain all their rights.
>
> This document and the information contained herein are provided on an This document and the information contained herein are provided on an
>
> skipping to change at page 9, line 44 skipping to change at line 281
> attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
> such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
> specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
> http://www.ietf.org/ipr. http://www.ietf.org/ipr.
>
> The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
> copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
> rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
> this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
> ietf-ipr@ietf.org. ietf-ipr@ietf.org.
>
> Acknowledgment
>
> Funding for the RFC Editor function is provided by the IETF
> Administrative Support Activity (IASA).
>
> End of changes. 31 change blocks.
> 141 lines changed or deleted 80 lines changed or added
>
> This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
> |||||||||||||||||||||||||||||||||||||||||||||||\}}}}}}}}
> |||||||||||||||||||||||||||||||||||||||||||||\ \}}}}}}}}}}
> ||||||||||||||||||||||||||© 2009 Martin Musatov }}}}}}}}}}}}}}
> ||||||||||||||||||||||||||||AllRights Reserved.}}}}}}}}}}}}}}}}}
> |||||||||||||||||||||||||||||||||||http://MeAmI.org (tm)}}}}}}}}}}
> |||||||||||||||||||||||||||||||||||||||||||||||||||||||||}}}}}}}}}{/////////||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||mmmmm
> }}}}}}}}}}http://MeAmI.org (tm) ||||||||||||| NP
> |||||||||||||||||||||||||||||||||||||||||||||||||||||||||}}}}}}}}}© 2009 Martin Musatov All Rights Reserved.
> {P=NP}|||||||||||||||||||||||||||||||||||||||||||||||||NP+P|||||||||||||||||||||||||||||||||||||||||||||||||||||NP=P

On Thursday, September 10, 2009 8:20:00 PM UTC-7, marty....@gmail.com wrote:
> DO YOU NOT DARE TELL ME MY WORK IS NOT COMPLETE WHEN IT IS PERFECT WHO ARE YOU TO DEAL IN JUDGMENT/?
>
> if (creation && object of art && algorithm && one's own algorithm) {
> include * an algorist *
> } elseif (!creation || !object of art || !algorithm || !one's own algorithm) {
> exclude * not an algorist *
> }
>
>
>
> > On May 28, 4:
>
>
> 34 pm, Martin Michael Musatov
> > <marty.musa...@gmail.com>
> > wrote:
> > > Math Forum Discussions Discussions
> > + sci.math.symbolic | Google Groups > The polynomials
> > in y, P(n,y) := #i^n/n * B(n,
> > +...mathforum.org/...thread.jspa Math Forum
> > Discussions ... sci.math.* » sci.math.
> > Topic: P=NP Proof Published at CERN ...
> > Martin Musatov a écrit
> > :...http://mathforum.orgthrea.jspa more >
> > >
> > > An informal and highly experimental, unorthodox
> > proof P=NP has been
> > > published on CERN preprints.The Internet was
> > invented at CERN.
> > > Proof P=NP:
> > >
> > >
> > http://cdsweb.cern.ch/record/1164206/files/s1-ln575821
> > >
> > 0-9223534-1939656818Hwf-1468147288IdV-1521282711575821
> > 0PDF_HI0001.pdf
> > >
> > > It is mine, and it is not published anywhere
> > else.My purpose in posting
> > > it here is for feedback and suggestions on how to
> > strengthen it.
> >
> > If it needs strengthening, it is not a proof.
> >
> > > I would specifically, as was my intention with this
> > experiment,
> > > like feedback from anyone interested in the
> > methodology used and
> > > recognition of how I pursued and attained a broadly
> > accepted
> > > peer-reviewed published proof building on this
> > basic result.
> > >
> > > Thank you,
> > >
> > > Martin Musatov
> > > m e a m i[at]vzw[dot]blackberry[dot]net.
> >
> >
>
> draft-ietf-ipv6-deprecate-rh0 rfc5095.txt
>
> Network Working Group J. Abley Network Working Group J. Abley
> Internet-Draft Afilias Request for Comments: 5095 Afilias
> Updates: 2460, 4294 P. Savola Updates: 2460, 4294 P. Savola
> (if approved) CSC/FUNET Category: Standards Track CSC/FUNET
> Intended status: Standards Track G. Neville-Neil G. Neville-Neil
> Expires: December 28, 2007 Neville-Neil Consulting Neville-Neil Consulting
> June 26, 2007 December 2007
>
> Deprecation of Type 0 Routing Headers in IPv6 Deprecation of Type 0 Routing Headers in IPv6
> draft-ietf-ipv6-deprecate-rh0-01
>
> Status of this Memo Status of This Memo
>
> By submitting this Internet-Draft, each author represents that any
> applicable patent or other IPR claims of which he or she is aware
> have been or will be disclosed, and any of which he or she becomes
> aware will be disclosed, in accordance with Section 6 of BCP 79.
>
> Internet-Drafts are working documents of the Internet Engineering
> Task Force (IETF), its areas, and its working groups. Note that
> other groups may also distribute working documents as Internet-
> Drafts.
>
> Internet-Drafts are draft documents valid for a maximum of six months
> and may be updated, replaced, or obsoleted by other documents at any
> time. It is inappropriate to use Internet-Drafts as reference
> material or to cite them other than as "work in progress."
>
> The list of current Internet-Drafts can be accessed at
> http://www.ietf.org/ietf/1id-abstracts.txt.
>
> The list of Internet-Draft Shadow Directories can be accessed at
> http://www.ietf.org/shadow.html.
>
> This Internet-Draft will expire on December 28, 2007.
>
> Copyright Notice
>
> Copyright (C) The IETF Trust (2007). This document specifies an Internet standards track protocol for the
> Internet community, and requests discussion and suggestions for
> improvements. Please refer to the current edition of the "Internet
> Official Protocol Standards" (STD 1) for the standardization state
> and status of this protocol. Distribution of this memo is unlimited.
>
> Abstract Abstract
>
> The functionality provided by IPv6's Type 0 Routing Header can be The functionality provided by IPv6's Type 0 Routing Header can be
> exploited in order to achieve traffic amplification over a remote exploited in order to achieve traffic amplification over a remote
> path for the purposes of generating denial-of-service traffic. This path for the purposes of generating denial-of-service traffic. This
> document updates the IPv6 specification to deprecate the use of IPv6 document updates the IPv6 specification to deprecate the use of IPv6
> Type 0 Routing Headers, in light of this security concern. Type 0 Routing Headers, in light of this security concern.
>
> Table of Contents Table of Contents
>
> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
> 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
> 3. Deprecation of RH0 . . . . . . . . . . . . . . . . . . . . . . 4 3. Deprecation of RH0 . . . . . . . . . . . . . . . . . . . . . . 3
> 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 3
> 4.1. Ingress Filtering . . . . . . . . . . . . . . . . . . . . . 4 4.1. Ingress Filtering . . . . . . . . . . . . . . . . . . . . . 3
> 4.2. Firewall Policy . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Firewall Policy . . . . . . . . . . . . . . . . . . . . . . 3
> 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
> 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
> 7. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
> 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
> 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
> 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 5
> Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 6
> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
> Intellectual Property and Copyright Statements . . . . . . . . . . 9
>
> 1. Introduction 1. Introduction
>
> [RFC2460] defines an IPv6 extension header called "Routing Header", [RFC2460] defines an IPv6 extension header called "Routing Header",
> identified by a Next Header value of 43 in the immediately preceding identified by a Next Header value of 43 in the immediately preceding
> header. A particular Routing Header subtype denoted as "Type 0" is header. A particular Routing Header subtype denoted as "Type 0" is
> also defined. Type 0 Routing Headers are referred to as "RH0" in also defined. Type 0 Routing Headers are referred to as "RH0" in
> this document. this document.
>
> A single RH0 may contain multiple intermediate node addresses, and A single RH0 may contain multiple intermediate node addresses, and
> the same address may be included more than once in the same RH0. the same address may be included more than once in the same RH0.
> This allows a packet to be constructed such that it will oscillate This allows a packet to be constructed such that it will oscillate
> between two RH0-processing hosts or routers many times. This allows between two RH0-processing hosts or routers many times. This allows
> a stream of packets from an attacker to be amplified along the path a stream of packets from an attacker to be amplified along the path
> between two remote routers, which could be used to cause congestion between two remote routers, which could be used to cause congestion
> along arbitrary remote paths and hence act as a denial-of-service along arbitrary remote paths and hence act as a denial-of-service
> mechanism. 88-fold amplification has been demonstrated using this mechanism. An 88-fold amplification has been demonstrated using this
> technique [CanSecWest07]. technique [CanSecWest07].
>
> This attack is particularly serious in that it affects the entire This attack is particularly serious in that it affects the entire
> path between the two exploited nodes, not only the nodes themselves path between the two exploited nodes, not only the nodes themselves
> or their local networks. Analogous functionality may be found in the or their local networks. Analogous functionality may be found in the
> IPv4 source route option, but the opportunities for abuse are greater IPv4 source route option, but the opportunities for abuse are greater
> with RH0 due to the ability to specify many more intermediate node with RH0 due to the ability to specify many more intermediate node
> addresses in each packet. addresses in each packet.
>
> The severity of this threat is considered to be sufficient to warrant The severity of this threat is considered to be sufficient to warrant
> deprecation of RH0 entirely. A side-effect is that this also deprecation of RH0 entirely. A side effect is that this also
> eliminates benign RH0 use-cases; however, such applications may be eliminates benign RH0 use-cases; however, such applications may be
> facilitated by future Routing Header specifications. facilitated by future Routing Header specifications.
>
> Potential problems with RH0 were identified in 2001 Potential problems with RH0 were identified in 2001 [Security]. In
> [I-D.savola-ipv6-rh-ha-security]. In 2002 a proposal was made to 2002 a proposal was made to restrict Routing Header processing in
> restrict Routing Header processing in hosts hosts [Hosts]. These efforts resulted in the modification of the
> [I-D.savola-ipv6-rh-hosts]. These efforts resulted in the Mobile IPv6 specification to use the type 2 Routing Header instead of
> modification of the Mobile IPv6 specification to use the type 2 RH0 [RFC3775]. Vishwas Manral identified various risks associated
> Routing Header instead of RH0 [RFC3775]. Vishwas Manral identified with RH0 in 2006 including the amplification attack; several of these
> various risks associated with RH0 in 2006 including the amplification vulnerabilities (together with other issues) were later documented in
> attack; several of these vulnerabilities (together with other issues) [RFC4942].
> were later documented in [I-D.ietf-v6ops-security-overview].
>
> A treatment of the operational security implications of RH0 was A treatment of the operational security implications of RH0 was
> presented by Philippe Biondi and Arnaud Ebalard at the CanSecWest presented by Philippe Biondi and Arnaud Ebalard at the CanSecWest
> conference in Vancouver, 2007 [CanSecWest07]. This presentation conference in Vancouver, 2007 [CanSecWest07]. This presentation
> resulted in widespread publicity for the risks associated with RH0. resulted in widespread publicity for the risks associated with RH0.
>
> This document updates [RFC2460] and [RFC4294]. This document updates [RFC2460] and [RFC4294].
>
> 2. Definitions 2. Definitions
>
> RH0 in this document denotes the IPv6 Extension Header type 43 RH0 in this document denotes the IPv6 Extension Header type 43
> ("Routing Header") variant 0 ("Type 0 Routing Header"), as defined in ("Routing Header") variant 0 ("Type 0 Routing Header"), as defined in
> [RFC2460]. [RFC2460].
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
>
> 3. Deprecation of RH0 3. Deprecation of RH0
>
> IPv6 nodes MUST NOT process RH0 in packets whose destination address An IPv6 node that receives a packet with a destination address
> in the IPv6 header is an address assigned to them. Such packets MUST assigned to it and that contains an RH0 extension header MUST NOT
> be processed according to the behaviour specified in Section 4.4 of execute the algorithm specified in the latter part of Section 4.4 of
> [RFC2460] for a datagram which includes an unrecognised Routing Type [RFC2460] for RH0. Instead, such packets MUST be processed according
> value, namely: to the behaviour specified in Section 4.4 of [RFC2460] for a datagram
> that includes an unrecognised Routing Type value, namely:
>
> If Segments Left is zero, the node must ignore the Routing header If Segments Left is zero, the node must ignore the Routing header
> and proceed to process the next header in the packet, whose type and proceed to process the next header in the packet, whose type
> is identified by the Next Header field in the Routing header. is identified by the Next Header field in the Routing header.
>
> If Segments Left is non-zero, the node must discard the packet and If Segments Left is non-zero, the node must discard the packet and
> send an ICMP Parameter Problem, Code 0, message to the packet's send an ICMP Parameter Problem, Code 0, message to the packet's
> Source Address, pointing to the unrecognised Routing Type. Source Address, pointing to the unrecognized Routing Type.
>
> IPv6 implementations are no longer required to implement RH0 in any IPv6 implementations are no longer required to implement RH0 in any
> way. way.
>
> 4. Operations 4. Operations
>
> 4.1. Ingress Filtering 4.1. Ingress Filtering
>
> It is to be expected that it will take some time before all IPv6 It is to be expected that it will take some time before all IPv6
> nodes are updated to remove support for RH0. Some of the uses of RH0 nodes are updated to remove support for RH0. Some of the uses of RH0
> described in [CanSecWest07] can be mitigated using ingress filtering, described in [CanSecWest07] can be mitigated using ingress filtering,
> as recommended in [RFC2827] and [RFC3704]. as recommended in [RFC2827] and [RFC3704].
>
> A site security policy intended to protect against attacks using RH0 A site security policy intended to protect against attacks using RH0
> SHOULD include the implementation of ingress filtering at the site SHOULD include the implementation of ingress filtering at the site
> border. border.
>
> 4.2. Firewall Policy 4.2. Firewall Policy
>
> Blocking all IPv6 packets which carry Routing Headers (rather than Blocking all IPv6 packets that carry Routing Headers (rather than
> specifically blocking type 0, and permitting other types) has very specifically blocking Type 0 and permitting other types) has very
> serious implications for the future development of IPv6. If even a serious implications for the future development of IPv6. If even a
> small percentage of deployed firewalls block other types of routing small percentage of deployed firewalls block other types of Routing
> headers by default, it will become impossible in practice to extend Headers by default, it will become impossible in practice to extend
> IPv6 routing headers. For example, Mobile IPv6 [RFC3775] relies upon IPv6 Routing Headers. For example, Mobile IPv6 [RFC3775] relies upon
> a type-2 RH; wide-scale, indescriminate blocking of Routing Headers a Type 2 Routing Header; wide-scale, indiscriminate blocking of
> will make Mobile IPv6 undeployable. Routing Headers will make Mobile IPv6 undeployable.
>
> Firewall policy intended to protect against packets containing RH0 Firewall policy intended to protect against packets containing RH0
> MUST NOT simply filter all traffic with a routing header; it must be MUST NOT simply filter all traffic with a Routing Header; it must be
> possible to disable forwarding of type 0 traffic without blocking possible to disable forwarding of Type 0 traffic without blocking
> other types of routing headers. In addition, the default other types of Routing Headers. In addition, the default
> configuration MUST permit forwarding of traffic using a RH other than configuration MUST permit forwarding of traffic using a Routing
> 0. Header other than 0.
>
> 5. Security Considerations 5. Security Considerations
>
> The purpose of this document is to deprecate a feature of IPv6 which The purpose of this document is to deprecate a feature of IPv6 that
> has been shown to have undesirable security implications. Specific has been shown to have undesirable security implications. Specific
> examples of vulnerabilities which are facilitated by the availability examples of vulnerabilities that are facilitated by the availability
> of RH0 can be found in [CanSecWest07]. In particular, RH0 provides a of RH0 can be found in [CanSecWest07]. In particular, RH0 provides a
> mechanism for traffic amplification, which might be used as a denial- mechanism for traffic amplification, which might be used as a denial-
> of-service attack. A description of this functionality can be found of-service attack. A description of this functionality can be found
> in Section 1. in Section 1.
>
> 6. IANA Considerations 6. IANA Considerations
>
> The IANA registry "Internet Protocol Version 6 (IPv6) Parameters" The IANA registry "Internet Protocol Version 6 (IPv6) Parameters"
> should be updated to reflect that variant 0 of IPv6 header-type 43 should be updated to reflect that variant 0 of IPv6 header-type 43
> ("Routing Header") is deprecated. ("Routing Header") is deprecated.
>
> 7. Acknowlegements 7. Acknowledgements
>
> This document benefits from the contributions of many IPV6 and V6OPS This document benefits from the contributions of many IPV6 and V6OPS
> working group participants, including Jari Arkko, Arnaud Ebalard, Tim working group participants, including Jari Arkko, Arnaud Ebalard, Tim
> Enos, Brian Haberman, Jun-ichiro itojun HAGINO, Bob Hinden, Thomas Enos, Brian Haberman, Jun-ichiro itojun Hagino, Bob Hinden, Thomas
> Narten, JINMEI Tatuya, David Malone, Jeroen Massar, Dave Thaler and Narten, Jinmei Tatuya, David Malone, Jeroen Massar, Dave Thaler, and
> Guillaume Valadon. Guillaume Valadon.
>
> 8. References 8. References
>
> 8.1. Normative References 8.1. Normative References
>
> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
> Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
>
> [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol,
> (IPv6) Specification", RFC 2460, December 1998. Version 6 (IPv6) Specification", RFC 2460,
> December 1998.
>
> [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
> April 2006. April 2006.
>
> 8.2. Informative References 8.2. Informative References
>
> [CanSecWest07] [CanSecWest07] Biondi, P. and A. Ebalard, "IPv6 Routing Header
> BIONDI, P. and A. EBALARD, "IPv6 Routing Header Security", Security", CanSecWest Security Conference 2007,
> CanSecWest Security Conference 2007, April 2007. April 2007.
>
> http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf
>
> [I-D.ietf-v6ops-security-overview] [Hosts] Savola, P., "Note about Routing Header Processing on
> Davies, E., "IPv6 Transition/Co-existence Security IPv6 Hosts", Work in Progress, February 2002.
> Considerations", draft-ietf-v6ops-security-overview-06
> (work in progress), October 2006.
>
> [I-D.savola-ipv6-rh-ha-security]
> Savola, P., "Security of IPv6 Routing Header and Home
> Address Options", draft-savola-ipv6-rh-ha-security-02
> (work in progress), March 2002.
>
> [I-D.savola-ipv6-rh-hosts]
> Savola, P., "Note about Routing Header Processing on IPv6
> Hosts", draft-savola-ipv6-rh-hosts-00 (work in progress),
> February 2002.
>
> [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
> Defeating Denial of Service Attacks which employ IP Source
> Address Spoofing", BCP 38, RFC 2827, May 2000.
>
> [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
> Networks", BCP 84, RFC 3704, March 2004.
>
> [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
> in IPv6", RFC 3775, June 2004.
>
> Appendix A. Change History
>
> This section to be removed prior to publication.
>
> 00 Strawman, draft-jabley-ipv6-rh0-is-evil, circulated to provoke
> discussion.
>
> 01 Clarified Section 3; presented more options in Section 4; added
> Pekka and George as authors. This document version was not widely
> circulated.
>
> 00 Renamed, draft-ietf-ipv6-deprecate-rh0, a candidate working group [RFC2827] Ferguson, P. and D. Senie, "Network Ingress
> document. Filtering: Defeating Denial of Service Attacks which
> employ IP Source Address Spoofing", BCP 38, RFC 2827,
> May 2000.
>
> 01-candidate-00 Incorporated text summarising some of the unwelcome [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
> uses of RH0; added some clariying text describing deprecation; Multihomed Networks", BCP 84, RFC 3704, March 2004.
> modified some ambiguous text in Section 4.2; added "Updates:
> 4294".
>
> 01-candidate-01 Incorporated contributions from working group: [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
> substantially reduced Section 5; clarified wording in Section 3. Support in IPv6", RFC 3775, June 2004.
>
> 01-candidate-02 Moved description of traffic amplification to [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6
> Section 1, and inserted a corresponding cross-reference in Transition/Co-existence Security Considerations",
> Section 5. Strengthened the language in Section 4.2 along the RFC 4942, September 2007.
> lines suggested by Thomas Narten. Small typos corrected. Added a
> further sentence in Section 4.1 intended to act as further
> encouragement for operators to implement [RFC3704].
>
> 01 Minor wordsmithing; removed some subjective language; adopted [Security] Savola, P., "Security of IPv6 Routing Header and Home
> "intermediate node" nomenclature instead of "waypoint"; shifted Address Options", Work in Progress, March 2002.
> some history from Section 7 to Section 1.
>
> Authors' Addresses Authors' Addresses
>
> Joe Abley Joe Abley
> Afilias Canada Corp. Afilias Canada Corp.
> Suite 204, 4141 Yonge Street Suite 204, 4141 Yonge Street
> Toronto, ON M2P 2A8 Toronto, ON M2P 2A8
> Canada Canada
>
> Phone: +1 416 673 4176 Phone: +1 416 673 4176
> Email: jabley@ca.afilias.info EMail: jabley@ca.afilias.info
>
> Pekka Savola Pekka Savola
> CSC/FUNET CSC/FUNET
> Espoo, Espoo,
> Finland Finland
>
> Email: psavola@funet.fi EMail: psavola@funet.fi
>
> George Neville-Neil George Neville-Neil
> Neville-Neil Consulting Neville-Neil Consulting
> 2261 Market St. #239 2261 Market St. #239
> San Francisco, CA 94114 San Francisco, CA 94114
> USA USA
>
> Email: gnn@neville-neil.com EMail: gnn@neville-neil.com
>
> Full Copyright Statement Full Copyright Statement
>
> Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
>
> This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
> contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
> retain all their rights. retain all their rights.
>
> This document and the information contained herein are provided on an This document and the information contained herein are provided on an
>
> skipping to change at page 9, line 44 skipping to change at line 281
> attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
> such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
> specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
> http://www.ietf.org/ipr. http://www.ietf.org/ipr.
>
> The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
> copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
> rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
> this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
> ietf-ipr@ietf.org. ietf-ipr@ietf.org.
>
> Acknowledgment
>
> Funding for the RFC Editor function is provided by the IETF
> Administrative Support Activity (IASA).
>
> End of changes. 31 change blocks.
> 141 lines changed or deleted 80 lines changed or added
>
> This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
> |||||||||||||||||||||||||||||||||||||||||||||||\}}}}}}}}
> |||||||||||||||||||||||||||||||||||||||||||||\ \}}}}}}}}}}
> ||||||||||||||||||||||||||© 2009 Martin Musatov }}}}}}}}}}}}}}
> ||||||||||||||||||||||||||||AllRights Reserved.}}}}}}}}}}}}}}}}}
> |||||||||||||||||||||||||||||||||||http://MeAmI.org (tm)}}}}}}}}}}
> |||||||||||||||||||||||||||||||||||||||||||||||||||||||||}}}}}}}}}{/////////||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||mmmmm
> }}}}}}}}}}http://MeAmI.org (tm) ||||||||||||| NP
> |||||||||||||||||||||||||||||||||||||||||||||||||||||||||}}}}}}}}}© 2009 Martin Musatov All Rights Reserved.
> {P=NP}|||||||||||||||||||||||||||||||||||||||||||||||||NP+P|||||||||||||||||||||||||||||||||||||||||||||||||||||NP=P