On Thu, Apr 03, 2003 at 03:44:29PM -0800, Michel Py wrote:
> http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-ipv6-gusl-00.txt
Comments below ;)
> Nokia should not be the only company to provide free registration; as a
> matter of fact I think it would be good to have two servers.
Surely, it would be nice if anyone who wanted to could be such a server.
> Feel free to comment on the text, it does need polishing.
Now, concerning the draft, here are my comments. Please have mercy, as this is
the first time I've ever responded with serious comments to a draft!
C. Non-goals:
Change the scope or usage of site-local addresses.
What do you mean by scope? Also, you can scarcely change the usage since
there is no *standard* usage.
This document uses "site" having the same meaning as "end site" as
described in [IPV6POLICY].
It seems dangerous to start using a word in the wrong way, even if you document
it. I imagine that it can only propogate the confusion, although I have no
suggested solutions other than to use a different word.
1.1 Rationale.
This section is a bit confusing. Perhaps the following is better:
The mailing list has expressed a desire that site-local prefixes have
the following properties: free, automatic, no registration, and
unique. Since these properties are somewhat contradictory, it is
necessary to partially compromise specific properties. However,
multiple non-exclusive compromises are possible, so multiple
non-exclusive compromises are offered by this document.
Concerning:
If the router has the capability of saving its
configuration in non-volatile memory such as NVRAM, Flash,
or disk file the site-local prefix MUST be saved as part of
the configuration and the generation MUST happen only once;
subsequent restarts MUST use the site-local prefix stored
in the configuration.
I think that this text is not only necessary, but harmful. The only reason
the prefix could change is if some nic's were added or removed. If it is the
case that a nic is removed, the router must regenerate a new prefix. I think
this goal is achieved by simply removing the text.
1.2.2 Unregistered, free, unique, sequentially allocated:
FEF0::/12
This is fine as long as Nokia never goes out of business (I'm not being snide,
I'm being practical). My assumption accounts for this, but I don't think it's
a big deal. I think we can trust Nokia to hand this over to another company if
the need ever arises.
- Allocation is rate-limited at one prefix per day per IPv6
/64 prefix or IPv4 address.
I can think of a few situtations where this limit would be too much.
Personally, I was thinking of simply requiring a valid email address, and
applying a minimal Turing test to make sure that a real person is making the
request. As long as a real person is involved, he can request as many prefixes
(one at a time) as he wants. This is not a big deal, though.
Options a) and b) MUST NOT be available if the router does not
have the capability of saving its configuration in non-volatile
memory such as NVRAM, Flash, or disk file.
I think this goes without saying. If it must be said, I don't think you need
to use "MUST NOT". I think "will not" is sufficient.
2.2 All IPv6 capable routers MUST implement a default black hole
I think SHOULD is sufficient. If even 90% of routers implement this
requirement, it will be enough.
In fact, I think sections 2.2 and 2.3 should be removed. Afterall, routers
internal to a site should route site-locals just fine (per Margaret Wasserman's
nesting ideas). I would possibly replace this with non-normative text
suggesting that border firewalls and ISP's should filter this stuff.
GUSL addresses MUST NOT be used for communication with other sites.
Routers MUST NOT forward any packets with GUSL source or
destination addresses outside of the site.
I'm personally not a fan of this. I can understand trying to protect the DFZ,
but I think it should be perfectly fine to connect two sites using site-local
addresses and a tunnel. Perhaps we should require that only unique (not
probably unique) prefixes should be allowed to do this, though.
6. Security considerations.
It'd be nice if there was text reminding people that site-locals don't
necessarily provide security.
Best Regards,
-jj
--
Hacker is to software engineer as
Climbing Mt. Everest is to building a Denny's there.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
