Subject: grow: follow-up re: IESG BCP consideration of Embedded Addresses draft

From: Dave Plonka <[email-masked]>
Date: Mon, 27 Sep 2004 12:47:31 -0500

GROWers,

On Sep 16, the IESG considered our embed-addr draft as BCP:

- 'Embedding Globally Routable Internet Addresses Considered Harmful'
   http://www.ietf.org/internet-drafts/draft-ietf-grow-embed-addr-03.txt

My interpretation of the subsequent report by our area director is
that, while most ADs liked it, overall they would like some
improvements concerning "the lack of alternatives" [to embedding
addresses].

Of the GROW participants, I would appreciate your suggestions or
additions so that I can improve this document to submit it for
reconsideration as BCP.

I'm willing to recast the document to more clearly highlight the
existing recommendations/alternatives (in outline form).  It already
recommends all that I've thought of that is currently best practice,
e.g.:

   - use DHCP, w/the appropriate service-specific options (incl. NTP)
   - disable features unnecessary/unknown to the user
   - stop publicly advertising IP addresses as service identifiers
   - provide user interfaces for features wh/generate unsolicited traffic

Some further guidance offered was:

   > [The ADs] were looking for some
   > recommendations on what to do if one needs to get certain config
   > information and specifics on how. Therefore, it looks like we will
   > need another revision before we can get this one approved.

Personally, I don't know of any standard configuration protocol for
dissemination of such configuration information, other than the
aforementioned DHCP so we could use some contributions.

Thanks!
Dave

-- 
[email-masked]  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI
_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/

---

From: Pekka Savola <[email-masked]>
Date: Tue, 28 Sep 2004 08:03:41 +0300 (EEST)

Btw, did you take a look at the comments at:
https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1421&filename=draft-ietf-grow-embed-addr

..they might give more ideas what the other ADs thought?

>    - provide user interfaces for features wh/generate unsolicited traffic

I think these are OK as far as they apply.. but there are cases when 
they don't -- for example, there may not be DHCP/PPP options for the 
configured value.

I think the doc assumes that instead of gluing an global IP addresses, 
the problem could be mitigated by inserting a global FQDN, like 
ntp.wisc.edu, when the owner of that service could redirect the users 
at will.

There is another alternative, that is, to use the DNS vendor branch to 
look up this information.  E.g., ntp.linksys.com or whatever.  The 
vendor can then redirect to appropriate servers, or even 127.0.0.1 if 
necessary.

That has already been done a number of times e.g., by Microsoft (their
Teredo and 6to4 relays are of the form like 6to4.ipv6.microsoft.com,
and the systems by default look that up).

An alternative is to rely on service discovery protocols, similar to 
ones discussed in draft-palet-v6ops-tun-auto-disc-01.txt .. but these 
aren't quite there yet.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings