Subject: [radext] Notification of draft-ietf-softwire-map-radius work in Softwire

From: Jouni Korhonen <[email-masked]>
Date: Mon, 5 Aug 2013 11:11:52 +0300

Folks,

Softwire is working on RADIUS attributes & procedures for yet another IPv6 transition mechanism provisioning & configuration using AAA. I encourage to follow up the progress of this work, specifically those who has interest on IPv6.

- JOuni (as a co-chair)

---

From: Alan DeKok <[email-masked]>
Date: Tue, 06 Aug 2013 10:16:38 -0400

> Softwire is working on RADIUS attributes & procedures for yet another IPv6 transition mechanism provisioning & configuration using AAA. I encourage to follow up the progress of this work, specifica…

  A quick editorial review:

  ... the User-password attribute (2)
   SHOULD be filled by the shared MAP password that has been
   preconfigured on the DHCPv6 server

  I would recommend allowing for other forms of authentication.  It's
nice to suggest User-Password SHOULD be used.  But other authentication
methods exist, and could be allowed.

   In both above-mentioned scenarios, Message-authenticator (type 80)
   [RFC2869] SHOULD be used to protect both Access-Request and Access-
   Accept messages.

  The Access-Accept is already signed by the response authenticator.  A
Message-Authenticator attribute isn't strictly necessary here.

 ... 4.3.3. Encapsulation/Translation Flag Sub Option

  This is a boolean flag in 16 bits of space.  As per 6158, it should be
using a 32-bit integer.

  The same comment applies to the later sub-options.

  As an additional note, using pre-defined data types would simplify
this draft.  Most of the ASCII art could go away, and it would be MUCH
clearer when people used "ad hoc" data types, instead of the standard ones.

  Alan DeKok.