Protocol for Carrying Authentication for Network Access (PANA) Relay Element
draft-ohba-pana-relay-03

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'Protocol for Carrying Authentication for Network Access (PANA) Relay Element' to Proposed Standard (draft-ohba-pana-relay-03.txt)

The IESG has approved the following document:
- 'Protocol for Carrying Authentication for Network Access (PANA) Relay
   Element'
  (draft-ohba-pana-relay-03.txt) as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Jari Arkko.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ohba-pana-relay/

Ballot Text

Technical Summary

  The document specifies PANA Relay Element (PRE) functionality which
   enables PANA messaging between a PaC and a PAA where the two nodes
   cannot reach each other by means of regular IP routing. For example,
   a joining node (PaC) may only be able to use a link-local IPv6 address
   to communicate with a parent router prior to PANA authentication. The
   PAA typically resides in a 6LoWPAN Border Router which is often
   multiple IP hops away from the PaC. The PRE implemented on the parent
   router is used for relaying PANA messages between the PaC and the PAA
   in this scenario.

Working Group Summary

   This is a submission from outside the working groups. It has been worked on
   by a set of individuals focused on Internet of Things deployments.

Document Quality

   We are told that PANA relay (and RFC 5191 of course)  is being implemented by some ZigBee vendors
   and demonstrating interoperability in an IP mesh networking environment.

Personnel

   The Document Shepherd is Margaret Wasserman and the responsible
   Area Director is Jari Arkko.

RFC Editor Note

Replace the first paragraph of Section 3 with this:

PRE/PAA security is OPTIONAL since PANA messages are designed to be
used in untrusted networks, but if cryptographic mechanism is
supported, it SHOULD be IPsec. When the device characteristics preclude
support for IPsec, an alternative mechanism such as DTLS [REF], or
link-layer cryptographic security, etc. may be used instead. This section
describes how IPsec [RFC4301] can be used for securing the PANA relay
messages.

RFC Editor Note