2460

RFC 8200 – IPv6 has been standardized

By Aftab Siddiqui

On 14/07/2017, the IETF with the publication of RFC8200 announced that the Internet Protocol Version 6 (IPv6) had become the latest Internet Standard. Great news for IPv6, but if you’re surprised and confused by this, then you’re probably not only one!

The IPv6 specification that we’ve been studying and religiously following for more than 18 years was defined in RFC2460 along with several other RFCs [RFC 5095, RFC 5722, RFC 5871, RFC 6437, RFC 6564, RFC 6935, RFC 6946, RFC 7045, RFC 7112] . However, RFC 2460 was only ever a Draft Standard, and only now moves to being a full Internet Standard.

The IETF decided to make this change as there are various RFCs defining the IPv6 specification, and it’s good to combine these along with the Errata into a single RFC. To further understand this issue, it’s necessary to first review the IETF Standardisation process.

As per RFC 2026, all work started with an Internet Draft (I-D) which were and still are intended to be rough sketches of ideas, contributed as raw inputs to the IETF process and having a lifetime of no longer than 6 months although they may be updated several times. And I-D may also be adopted by a Working Group and further refined, progressing through a number of iterations until (and only if) consensus is reached, when the specification goes through a review phase before being published as a Request for Comment (RFC).

Again with reference to RFC 2026, specifications that were intended to become Internet Standards evolved through a set of maturity levels known as the “Standards Track”, which itself has three classifications:

Proposed Standard – This generally means a specification is stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Neither implementation nor operational experience is usually required prior to the designation of a specification as a Proposed Standard.

Draft Standard – A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the “Draft Standard” level. A Draft Standard must be well-understood and known to be quite stable, both in its semantics and as a basis for developing an implementation.

Internet Standard – A specification for which significant implementation and successful operational experience has been obtained may be elevated to the Internet Standard level. An Internet Standard (or just Standard) is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community. A specification that reaches the status of Standard is assigned a number in the STD series while retaining its RFC number.

In 2011, RFC 6410 was published as an update to RFC 2026 that replaced the three-tier ladder with a two-tier ladder. In this update, specifications become Internet Standards through a set of two maturity levels known as “Proposed Standard” and “Internet Standard” and hence the former “Draft Standard” level was abandoned with criteria provided for reclassifying these RFCs.

Any protocol or service that is currently at the abandoned Draft Standard maturity level will retain that classification, absent explicit actions as follows:

  1. A Draft Standard may be reclassified as an Internet Standard provided there are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones.
  2. The IESG may choose to reclassify any Draft Standard document as a Proposed Standard.

As of 1 June 2017 there were 81 RFCs with “Draft Standard” under the “Standard Track” and RFC 2460 – Internet Protocol, Version 6 (IPv6) Specification was one of these

The IPv6 Maintenance (6MAN) Working Group which is responsible for the maintenance, upkeep and advancement of the IPv6 protocol specifications and addressing architecture, started working on advancing the IPv6 core specifications towards an Internet Standard at IETF 93 in July 2015. The working group identified multiple RFCs to update, including RFC 2460, and decided to revise and re-classify it by incorporating updates from other 9 RFCs and 2 Errata.

The first draft was published in August 2015 as “draft-ietf-6man-rfc2460bis” and after several further changes, the final version was submitted for review in May 2017 as “draft-ietf-6man-rfc2460bis-13“. All of the changes from RFC2460 are summarized in Appendix B [Page 36] and are ordered by the Internet Draft that initiated the change. The document has gone through extensive scrutiny in the 6MAN working group and there is broad support for this version to be published as an Internet Standard.

So really nothing changes, as RFC 8200 is a combined version of RFC 2460 along with other relevant RFCs and Errata.

Read more here:: www.internetsociety.org/deploy360/blog/feed/

RFC 8200 – IPv6 has been standardized

By News Aggregator

By Aftab Siddiqui

On 14/07/2017, the IETF with the publication of RFC8200 announced that the Internet Protocol Version 6 (IPv6) had become the latest Internet Standard. Great news for IPv6, but if you’re surprised and confused by this, then you’re probably not only one!

The IPv6 specification that we’ve been studying and religiously following for more than 18 years was defined in RFC2460 along with several other RFCs [RFC 5095, RFC 5722, RFC 5871, RFC 6437, RFC 6564, RFC 6935, RFC 6946, RFC 7045, RFC 7112] . However, RFC 2460 was only ever a Draft Standard, and only now moves to being a full Internet Standard.

The IETF decided to make this change as there are various RFCs defining the IPv6 specification, and it’s good to combine these along with the Errata into a single RFC. To further understand this issue, it’s necessary to first review the IETF Standardisation process.

As per RFC 2026, all work started with an Internet Draft (I-D) which were and still are intended to be rough sketches of ideas, contributed as raw inputs to the IETF process and having a lifetime of no longer than 6 months although they may be updated several times. And I-D may also be adopted by a Working Group and further refined, progressing through a number of iterations until (and only if) consensus is reached, when the specification goes through a review phase before being published as a Request for Comment (RFC).

Again with reference to RFC 2026, specifications that were intended to become Internet Standards evolved through a set of maturity levels known as the “Standards Track”, which itself has three classifications:

Proposed Standard – This generally means a specification is stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Neither implementation nor operational experience is usually required prior to the designation of a specification as a Proposed Standard.

Draft Standard – A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the “Draft Standard” level. A Draft Standard must be well-understood and known to be quite stable, both in its semantics and as a basis for developing an implementation.

Internet Standard – A specification for which significant implementation and successful operational experience has been obtained may be elevated to the Internet Standard level. An Internet Standard (or just Standard) is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community. A specification that reaches the status of Standard is assigned a number in the STD series while retaining its RFC number.

In 2011, RFC 6410 was published as an update to RFC 2026 that replaced the three-tier ladder with a two-tier ladder. In this update, specifications become Internet Standards through a set of two maturity levels known as “Proposed Standard” and “Internet Standard” and hence the former “Draft Standard” level was abandoned with criteria provided for reclassifying these RFCs.

Any protocol or service that is currently at the abandoned Draft Standard maturity level will retain that classification, absent explicit actions as follows:

  1. A Draft Standard may be reclassified as an Internet Standard provided there are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones.
  2. The IESG may choose to reclassify any Draft Standard document as a Proposed Standard.

As of 1 June 2017 there were 81 RFCs with “Draft Standard” under the “Standard Track” and RFC 2460 – Internet Protocol, Version 6 (IPv6) Specification was one of these

The IPv6 Maintenance (6MAN) Working Group which is responsible for the maintenance, upkeep and advancement of the IPv6 protocol specifications and addressing architecture, started working on advancing the IPv6 core specifications towards an Internet Standard at IETF 93 in July 2015. The working group identified multiple RFCs to update, including RFC 2460, and decided to revise and re-classify it by incorporating updates from other 9 RFCs and 2 Errata.

The first draft was published in August 2015 as “draft-ietf-6man-rfc2460bis” and after several further changes, the final version was submitted for review in May 2017 as “draft-ietf-6man-rfc2460bis-13“. All of the changes from RFC2460 are summarized in Appendix B [Page 36] and are ordered by the Internet Draft that initiated the change. The document has gone through extensive scrutiny in the 6MAN working group and there is broad support for this version to be published as an Internet Standard.

So really nothing changes, as RFC 8200 is a combined version of RFC 2460 along with other relevant RFCs and Errata.

Read more here:: www.internetsociety.org/deploy360/blog/feed/

The post RFC 8200 – IPv6 has been standardized appeared on IPv6.net.

Read more here:: IPv6 News Aggregator

Deploy360@IETF98, Day 4: IPv6, IoT & ACME

By Kevin Meynell

Thursday at week IETF 98 in Chicago is another mix of IPv6, the Internet-of-Things and TLS-related working groups. Each day we’re bringing you blog posts pointing out what Deploy360 will be focusing on.

The first session of the day is 6MAN which has a last call on updates to the IPv6 specification as currently defined in RFC 2460, RFC 4291, and RFC 1981. There are also two new drafts under discussion related to recommendations on IPv6 address usage and temporary IPv6 interface identifiers, plus a draft describing how a Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) client can send a message over a congested network by tagging outgoing IPv6 packets in order to reach a DOTS server.

Three current drafts include a description of common functionality that should be required on all IPv6 hosts and routers that has been collected from other published IETF Standards Track documents, definition of a new control bit in an IPv6 router advertisement indicating that a receiving node is the exclusive receiver of all traffic destined to any address with that prefix, and providing a backward-compatible extension to the Redirect function in the IPv6 Neighbour Discovery protocol to allow routers to include information that a recipient can associate with the next hop.


NOTE: If you are unable to attend IETF 98 in person, there are multiple ways to participate remotely.


The afternoon sees ACME which has been developing a standards-based REST API allowing agent software to authenticate that a server controls a domain, request a certificate, and then install it on a server without human intervention. This session is discussing some changes to the ACME specification, as well as the next steps for the group with a view to re-chartering.

Finally, there are two working groups of interest during the evening session. DHC has three DHCPv6 related drafts on the agenda, whilst ROLL continues development of several routing protocols for resource constrained nodes.

For more background, please read the Rough Guide to IETF 98 from Olaf, Dan, Andrei, Mat, Karen and myself.

Relevant Working Groups

Read more here:: www.internetsociety.org/deploy360/blog/feed/

Deploy360@IETF98, Day 4: IPv6, IoT & ACME

By News Aggregator

By Kevin Meynell

Thursday at week IETF 98 in Chicago is another mix of IPv6, the Internet-of-Things and TLS-related working groups. Each day we’re bringing you blog posts pointing out what Deploy360 will be focusing on.

The first session of the day is 6MAN which has a last call on updates to the IPv6 specification as currently defined in RFC 2460, RFC 4291, and RFC 1981. There are also two new drafts under discussion related to recommendations on IPv6 address usage and temporary IPv6 interface identifiers, plus a draft describing how a Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) client can send a message over a congested network by tagging outgoing IPv6 packets in order to reach a DOTS server.

Three current drafts include a description of common functionality that should be required on all IPv6 hosts and routers that has been collected from other published IETF Standards Track documents, definition of a new control bit in an IPv6 router advertisement indicating that a receiving node is the exclusive receiver of all traffic destined to any address with that prefix, and providing a backward-compatible extension to the Redirect function in the IPv6 Neighbour Discovery protocol to allow routers to include information that a recipient can associate with the next hop.


NOTE: If you are unable to attend IETF 98 in person, there are multiple ways to participate remotely.


The afternoon sees ACME which has been developing a standards-based REST API allowing agent software to authenticate that a server controls a domain, request a certificate, and then install it on a server without human intervention. This session is discussing some changes to the ACME specification, as well as the next steps for the group with a view to re-chartering.

Finally, there are two working groups of interest during the evening session. DHC has three DHCPv6 related drafts on the agenda, whilst ROLL continues development of several routing protocols for resource constrained nodes.

For more background, please read the Rough Guide to IETF 98 from Olaf, Dan, Andrei, Mat, Karen and myself.

Relevant Working Groups

Read more here:: www.internetsociety.org/deploy360/blog/feed/

The post Deploy360@IETF98, Day 4: IPv6, IoT & ACME appeared on IPv6.net.

Read more here:: IPv6 News Aggregator

Deploy360@IETF97, Day 2: DNS, TLS & More IPv6

By Kevin Meynell

Seoul Skyline

Tuesday at IETF 97 in Seoul represents something of a mixed bag, with sessions on IPv6 DNS and TLS. Each day we’re bringing you blog posts pointing out what Deploy360 will be focusing on.

First up is 6MAN on Tuesday morning at 09.30 KST (UTC+9). On the agenda are several updates to the IPv6 specification as currently defined in RFC 2460, RFC 4291 and RFC 1981. Other drafts being discussed outline an optional mechanism for IPv6 Neighbour Discovery whereby hosts are instructed by routers to use router solicitations rather than multicast advertisements where it’s not desirable for all hosts to be continually woken-up; define a new control bit in IPv6 RA PIO flags to indicate that the receiving node is the exclusive receiver of traffic destined to any address within a prefix; specify requirements for IPv6 nodes; and specify a packet format for transporting IPv6 payloads to multiple IPv6 destinations using Bit Index Explicit Replication.


NOTE: If you are unable to attend IETF 97 in person, there are multiple ways to participate remotely.


There’s a clash between the Domain Name System Operations (dnsop) and Privacy Enhanced RTP Conferencing (perc) Working Groups on Tuesday afternoon at 13.30 KST (UTC+9). So we’ll be having to split our efforts between those, before heading to the Transport Layer Security (tls) Working Group for the evening session starting at 15.50 KST (UTC+9).

DNSOP is currently discussing several DNSSEC-related drafts. One recently submitted draft suggests an approach to managing Reverse DNS in IPv6 for Internet Service Providers, as the common practice of providing in.addr.arpa information using one PTR record for every IPv4 address does not scale with IPv6. There’s also a trance of other updates, including Signaling Trust Anchor Knowledge in DNSSEC which specifies two different ways validating resolvers to signal which keys are being used in their chain-of-trust; Managing DS records from parent via CDS/CDNSKEY which describe policies for signalling changes when undertaking key rollovers, and on Aggressive use of NSEC/NSEC3 resource records to allow DNSSEC validating resolvers to generate negative answers within a particular range as well as positive answers
from wildcards.

PERC will be discussing just a couple of Deploy360 relevant drafts. The first defines a DTLS tunneling protocol that enables a Media Distribution Device (MDD) to facilitate key exchange between an endpoint and a Key Management Function (KMF); whilst SRTP Double Encryption Procedures defines procedures to allow an intermediary node to manipulate RTP parameters while still providing strong end-to-end security.

That just leaves the first session of TLS which has several issues on the agenda. One is whether to rebrand the forthcoming TLS 1.3 to TLS 2.0 given the significant changes in the specification. Another is the ongoing draft defining a new TLS extension to allow clients to perform DANE authentication of a TLS server certificate without needing to perform additional DNS record lookups. Finally, Delegated Credentials for TLS describes a mechanism to allow TLS servers to make delegated changes to certificates or cryptographic algorithms without breaking compatibility with clients.

For more background, please read the Rough Guide to IETF 97 from Olaf, Dan, Andrei, Mat, Karen and myself.

Relevant Working Groups:

Read more here:: www.internetsociety.org/deploy360/blog/feed/

Deploy360@IETF97, Day 2: DNS, TLS & More IPv6

By News Aggregator

Seoul Skyline

By Kevin Meynell

Tuesday at IETF 97 in Seoul represents something of a mixed bag, with sessions on IPv6 DNS and TLS. Each day we’re bringing you blog posts pointing out what Deploy360 will be focusing on.

First up is 6MAN on Tuesday morning at 09.30 KST (UTC+9). On the agenda are several updates to the IPv6 specification as currently defined in RFC 2460, RFC 4291 and RFC 1981. Other drafts being discussed outline an optional mechanism for IPv6 Neighbour Discovery whereby hosts are instructed by routers to use router solicitations rather than multicast advertisements where it’s not desirable for all hosts to be continually woken-up; define a new control bit in IPv6 RA PIO flags to indicate that the receiving node is the exclusive receiver of traffic destined to any address within a prefix; specify requirements for IPv6 nodes; and specify a packet format for transporting IPv6 payloads to multiple IPv6 destinations using Bit Index Explicit Replication.


NOTE: If you are unable to attend IETF 97 in person, there are multiple ways to participate remotely.


There’s a clash between the Domain Name System Operations (dnsop) and Privacy Enhanced RTP Conferencing (perc) Working Groups on Tuesday afternoon at 13.30 KST (UTC+9). So we’ll be having to split our efforts between those, before heading to the Transport Layer Security (tls) Working Group for the evening session starting at 15.50 KST (UTC+9).

DNSOP is currently discussing several DNSSEC-related drafts. One recently submitted draft suggests an approach to managing Reverse DNS in IPv6 for Internet Service Providers, as the common practice of providing in.addr.arpa information using one PTR record for every IPv4 address does not scale with IPv6. There’s also a trance of other updates, including Signaling Trust Anchor Knowledge in DNSSEC which specifies two different ways validating resolvers to signal which keys are being used in their chain-of-trust; Managing DS records from parent via CDS/CDNSKEY which describe policies for signalling changes when undertaking key rollovers, and on Aggressive use of NSEC/NSEC3 resource records to allow DNSSEC validating resolvers to generate negative answers within a particular range as well as positive answers
from wildcards.

PERC will be discussing just a couple of Deploy360 relevant drafts. The first defines a DTLS tunneling protocol that enables a Media Distribution Device (MDD) to facilitate key exchange between an endpoint and a Key Management Function (KMF); whilst SRTP Double Encryption Procedures defines procedures to allow an intermediary node to manipulate RTP parameters while still providing strong end-to-end security.

That just leaves the first session of TLS which has several issues on the agenda. One is whether to rebrand the forthcoming TLS 1.3 to TLS 2.0 given the significant changes in the specification. Another is the ongoing draft defining a new TLS extension to allow clients to perform DANE authentication of a TLS server certificate without needing to perform additional DNS record lookups. Finally, Delegated Credentials for TLS describes a mechanism to allow TLS servers to make delegated changes to certificates or cryptographic algorithms without breaking compatibility with clients.

For more background, please read the Rough Guide to IETF 97 from Olaf, Dan, Andrei, Mat, Karen and myself.

Relevant Working Groups:

Read more here:: www.internetsociety.org/deploy360/blog/feed/

The post Deploy360@IETF97, Day 2: DNS, TLS & More IPv6 appeared on IPv6.net.

Read more here:: IPv6 News Aggregator

Deploy360@IETF96, Day 2: IPv6 & TLS

By Kevin Meynell

berlin

After a busy first day for the Deploy360 team at IETF 96 in Berlin, Tuesday is primarily devoted to IPv6 and TLS. Throughout this week at IETF 96 we’ll be bringing you these daily blog posts that point out what we are focused on during that day.

There’s a clash between IPv6 Maintenance (6man) and Transport Layer Security (tls) Working Groups on Tuesday morning at 10.00 CEST (UTC+), so we’ll be splitting our efforts between those. Then in the afternoon we’ll be heading to the Using TLS in Applications Working Group (uta).


NOTE: If you are unable to attend IETF 96 in person, there are multiple ways to participate remotely.


6MAN will be discussing a tranche of drafts dealing with updates to the IPv6 specification, addressing architecture and path MTU discovery as currently defined in RFC 2460, RFC 4291 and RFC 1981. There’s also a last call on the draft recommendation draft-ietf-6man-default-iids to change the default interface identifier (IID) generation scheme where SLAAC is used to generate a stable IPv6 address. Along similar lines is another draft on generating non-stable addresses draft-gont-6man-non-stable-iids-00 that are not predictable for security reasons, whilst further two drafts draft-carpenter-6man-whats-global-00 and draft-bchv-rfc6890bis-00 aim to clarify the unclear use of ‘global’ in the context of IANA special purpose IPv6 address registries. Last but not least, there’s a new draft dealing with the issue of multihoming using provider-assigned addresses without using network prefix translation.

TLS continues to work on an update to the TLS protocol. This is a very active working group with a plan to publish an update to TLS in 2016, so this meeting will be devoted to resolving the open issues with the current specification as documented in the issue tracker. There will also be discussions on AES-OCM, TLS Client Puzzles, and TLS Blocking alerts if there is time remaining in the session.

UTA is building on this work to get TLS support incorporated into existing applications, and the working group will be focusing on support for TLS in SMTP during its meeting on Tuesday afternoon.

For more background, please read the Rough Guide to IETF 96 from Olaf, Dan, Andrei, Mat, Karen and myself.

Relevant Working Groups:

Read more here:: www.internetsociety.org/deploy360/blog/feed/

Deploy360@IETF96, Day 2: IPv6 & TLS

By News Aggregator

berlin

By Kevin Meynell

After a busy first day for the Deploy360 team at IETF 96 in Berlin, Tuesday is primarily devoted to IPv6 and TLS. Throughout this week at IETF 96 we’ll be bringing you these daily blog posts that point out what we are focused on during that day.

There’s a clash between IPv6 Maintenance (6man) and Transport Layer Security (tls) Working Groups on Tuesday morning at 10.00 CEST (UTC+), so we’ll be splitting our efforts between those. Then in the afternoon we’ll be heading to the Using TLS in Applications Working Group (uta).


NOTE: If you are unable to attend IETF 96 in person, there are multiple ways to participate remotely.


6MAN will be discussing a tranche of drafts dealing with updates to the IPv6 specification, addressing architecture and path MTU discovery as currently defined in RFC 2460, RFC 4291 and RFC 1981. There’s also a last call on the draft recommendation draft-ietf-6man-default-iids to change the default interface identifier (IID) generation scheme where SLAAC is used to generate a stable IPv6 address. Along similar lines is another draft on generating non-stable addresses draft-gont-6man-non-stable-iids-00 that are not predictable for security reasons, whilst further two drafts draft-carpenter-6man-whats-global-00 and draft-bchv-rfc6890bis-00 aim to clarify the unclear use of ‘global’ in the context of IANA special purpose IPv6 address registries. Last but not least, there’s a new draft dealing with the issue of multihoming using provider-assigned addresses without using network prefix translation.

TLS continues to work on an update to the TLS protocol. This is a very active working group with a plan to publish an update to TLS in 2016, so this meeting will be devoted to resolving the open issues with the current specification as documented in the issue tracker. There will also be discussions on AES-OCM, TLS Client Puzzles, and TLS Blocking alerts if there is time remaining in the session.

UTA is building on this work to get TLS support incorporated into existing applications, and the working group will be focusing on support for TLS in SMTP during its meeting on Tuesday afternoon.

For more background, please read the Rough Guide to IETF 96 from Olaf, Dan, Andrei, Mat, Karen and myself.

Relevant Working Groups:

Read more here:: www.internetsociety.org/deploy360/blog/feed/

The post Deploy360@IETF96, Day 2: IPv6 & TLS appeared on IPv6.net.

Read more here:: IPv6 News Aggregator

Deploy360@IETF95, Day 3: DNS, SIDR & IPv6

By News Aggregator

Sara Dickinson at DPRIVE

By Kevin Meynell

Day 3 is another busy day for the Deploy360 team at IETF 95, albeit with a more orderly schedule. We kick-off with the DNS PRIVate Exchange and IPv6 Maintenance Working Groups, followed by the second session of the Secure Inter-Domain Routing Working Group, and first session of the Domain Name System Operations Working Group.


NOTE: If you are unable to attend IETF 95 in person, there are multiple ways to participate remotely.


DPRIVE has a short session in Atlantico C to continue discussions on DNS over TLS and DNS over DTLS which aims to secure the connections between DNS clients and the recursive resolvers that people use. This follows on from the Specification for DNS over TLS that was recently submitted for publication as an RFC to the IESG, and forms an important part of the overall encryption work being done by the IETF to protect against pervasive monitoring.

Over in Buen Ayre C, 6MAN will discuss proposed updates to the IPv6 specification, addressing architecture and path MTU discovery as currently defined in RFC 2460, RFC 4291, and RFC 1981. There are also two working group drafts relating to extension headers for routing and hop-by-hop options which allow for differential handling of packets by forwarding and control planes in routers. A further draft has the aim of allowing larger packet sizes (MTUs) to be negotiated on Ethernet provisioned links that are able to support so-called jumbo frames.

In the afternoon, SIDR continues from where it left off on Monday, but today’s session will focus on the requirements for RPKI Relying Parties. There will also be a discussion on detecting and mitigating route leaks – namely valid announcements that nevertheless propagate beyond their intended scope. There are a couple of proposals to extend the capabilities of BGPSEC to detect route leaks, but also to enhance BGP Open messages to enable BGP neighbours to specify their relationship (i.e. peer, customer, provider, internal) and thereby enforce appropriate configuration on both sides.

We finish the day with the first session of DNSOP (the second being on Friday morning). This includes two DNSSEC related drafts on speeding up negative answers from NSEC records for the root zone, as well as one on requirements and usage guidance for DNSSEC cryptographic algorithms with the intent of phasing out potentially less secure implementations.

Relevant Working Groups:


Image: Sara Dickinson presenting at the DPRIVE Working Group

Read more here:: www.internetsociety.org/deploy360/blog/feed/

The post Deploy360@IETF95, Day 3: DNS, SIDR & IPv6 appeared on IPv6.net.

Read more here:: IPv6 News Aggregator

Deploy360@IETF95, Day 3: DNS, SIDR & IPv6

By Kevin Meynell

Sara Dickinson at DPRIVE

Day 3 is another busy day for the Deploy360 team at IETF 95, albeit with a more orderly schedule. We kick-off with the DNS PRIVate Exchange and IPv6 Maintenance Working Groups, followed by the second session of the Secure Inter-Domain Routing Working Group, and first session of the Domain Name System Operations Working Group.


NOTE: If you are unable to attend IETF 95 in person, there are multiple ways to participate remotely.


DPRIVE has a short session in Atlantico C to continue discussions on DNS over TLS and DNS over DTLS which aims to secure the connections between DNS clients and the recursive resolvers that people use. This follows on from the Specification for DNS over TLS that was recently submitted for publication as an RFC to the IESG, and forms an important part of the overall encryption work being done by the IETF to protect against pervasive monitoring.

Over in Buen Ayre C, 6MAN will discuss proposed updates to the IPv6 specification, addressing architecture and path MTU discovery as currently defined in RFC 2460, RFC 4291, and RFC 1981. There are also two working group drafts relating to extension headers for routing and hop-by-hop options which allow for differential handling of packets by forwarding and control planes in routers. A further draft has the aim of allowing larger packet sizes (MTUs) to be negotiated on Ethernet provisioned links that are able to support so-called jumbo frames.

In the afternoon, SIDR continues from where it left off on Monday, but today’s session will focus on the requirements for RPKI Relying Parties. There will also be a discussion on detecting and mitigating route leaks – namely valid announcements that nevertheless propagate beyond their intended scope. There are a couple of proposals to extend the capabilities of BGPSEC to detect route leaks, but also to enhance BGP Open messages to enable BGP neighbours to specify their relationship (i.e. peer, customer, provider, internal) and thereby enforce appropriate configuration on both sides.

We finish the day with the first session of DNSOP (the second being on Friday morning). This includes two DNSSEC related drafts on speeding up negative answers from NSEC records for the root zone, as well as one on requirements and usage guidance for DNSSEC cryptographic algorithms with the intent of phasing out potentially less secure implementations.

Relevant Working Groups:


Image: Sara Dickinson presenting at the DPRIVE Working Group

Read more here:: www.internetsociety.org/deploy360/blog/feed/