Subject: PAA Discovery

From: Paal Engelstad <[email-masked]>
Date: Fri, 1 Feb 2002 21:53:49 +0100

Hi all,

I recently submitted a draft proposing a mechanism for discovering IP-addresses of PAAs. It is a lightweight and straightforeward solution based on extensions to RAs and/or to DHCP messages.

There are naturally other alternatives:
More heavyweight discovery: SLP
More lightweight discovery: No such discovery, e.g. the authentication request is multicasted (the SNARD-draft proposal.)

Apart from this, I expect it to be a generic solution that should interwork well with a number of PANA protocol proposals, especially those based on EAP, such as EAP-over-ICMP.

You will find the draft at:

http://www.ietf.org/internet-drafts/draft-engelstad-pana-paa-discovery-00.txt

Comments are welcome,
Paal

_________________________________________
Abstract:
A PANA authentication protocol is under development in the PANA Working Group. It will allow hosts to authenticate with PANA Authentication Agents (PAAs). The protocol is expected to run over some IP-based transport protocol, such as ICMP, UDP, TCP or SCTP. Before a host can authenticate with a PAA, it must obtain an IP-address of the PAA. This document specifies such a 'discovery' mechanism by defining extensions (or options) to Router Advertisements and DHCP messages for both IPv4 and IPv6. Hosts MAY also obtain an identity of a PAA and other information during the discovery process. The proposed discovery mechanism makes no assumptions about the location of a PAA, and more than one PAA may be discovered.

---

From: "James Kempf" <[email-masked]>
Date: Fri, 1 Feb 2002 14:11:37 -0800

> I recently submitted a draft proposing a mechanism for discovering
IP-addresses of PAAs. It is a lightweight and straightforeward solution
based on extensions to RAs and/or to DHCP messages.
> More heavyweight discovery: SLP

I'll dispute this assertion. The SLP implementers group is currently
working to take SLP to draft standard and has eliminated a number of
mechanisms that were either not implemented or were deemed to be too
heavyweight.
Check draft-guttman-rfc2608bis-01.txt.

Furthermore, I would like to argue strongly against a "roll your own"
discovery technique approach. If you
don't like SLP try:

1) DHCP

2) DNS/mDNS

3) LDAP

Unless you are talking about something like routing, there is absolutely
no reason to come up with
a new discovery technique. I've spent the last two years going around to
working groups who
argue that their protocol is so "different" and "unique" that they must
invent a new discovery protocol.
The problem with this is that it is another special, one off discovery
protocol that must be administered
Not only that, but somebody has to implement the tools to administer the
discovery protocol. Imagine what it would be like if every WG decided
they wanted to implement their own transport protocol, or name service
protocol, or <pick a currently used protocol for a standard architecural
element>. Unfortunately, the IAB/IESG hasn't yet seen
fit to try to enforce architectural consistency on service discovery,
since it is in some sense, not
perceived as a serious enough problem. But for the people who have to
implement the tools and
administer it, it sure enough is.

We don't need a special purpose discovery protocol for PANA, let's just
figure out what the right existing protocol is and how to use that.

                jak