Subject: AD review of draft-ietf-ipv6-node-requirements-05.txt

From: Thomas Narten <[email-masked]>
Date: Wed, 27 Aug 2003 17:29:40 -0400

The WG has asked this  be published as an Informational document. Here
are my review comments. I assume some discussion  and a revised ID
will be needed before I forward the document to the IESG as a whole.

Note: some of these points may best be responded to by starting a
separate thread, so folk can easily follow individual topics of
interest.

Thomas

substantative (more or less...):

General comment. There are places in the document where it is not
immediately clear whether something is required to be implemented or
not. Sometimes the wording is just "support", and in the context of
the wording, this may depend on deployment considerations. I would
except that the purpose of this document is to make it clear what
needs to implemented. I mention some specific cases below, but may not
have caught them all... It might be good to scan the document for
"support" and check that the intent is clear.

>    Nodes MUST always be able to receive fragment headers. However, if it
>    does not implement path MTU discovery it may not need to send
>    fragment headers.  However, nodes that do not implement transmission
>    of fragment headers need to impose a limitation to the payload size
>    of layer 4 protocols.
     
This would seem inconsistent with the following wording in RFC 2460:

    In response to an IPv6 packet that is sent to an IPv4 destination
    (i.e., a packet that undergoes translation from IPv6 to IPv4), the
    originating IPv6 node may receive an ICMP Packet Too Big message
    reporting a Next-Hop MTU less than 1280.  In that case, the IPv6 node
    is not required to reduce the size of subsequent packets to less than
    1280, but must include a Fragment header in those packets so that the
    IPv6-to-IPv4 translating router can obtain a suitable Identification
    value to use in resulting IPv4 fragments.  Note that this means the
    payload may have to be reduced to 1232 octets (1280 minus 40 for the
    IPv6 header and 8 for the Fragment header), and smaller still if
    additional extension headers are used.

>    Router Discovery is how hosts locate routers that reside on an
>    attached link. Router Discovery MUST be supported for
>    implementations. However, an implementation MAY support disabling
>    this function.

Why the MAY above? If there are reasons to allow this, it would be
good to give some examples of the WG's thinking for calling out such
an exception. Also, this is a change to 2461 I assume?

>    Prefix Discovery is how hosts discover the set of address prefixes
>    that define which destinations are on-link for an attached link.
>    Prefix discovery MUST be supported for implementations. However, the
>    implementation MAY support the option of disabling this function.

same comment with regards to MAY. And also, am I right to assume that
disabling this function would need to be done on a per-interface basis
(in which case the current text isn't explicit enough)? I.e, is this
related to some 3G type deployment?

>    Duplicate Address Detection MUST be supported (RFC2462 section 5.4
>    specifies DAD MUST take place on all unicast addresses).

This reference to 2462 section 5.4 is a tad misleading. The relevant
paragraph in 2462 says:

> 5.4.  Duplicate Address Detection
> 
>    Duplicate Address Detection is performed on unicast addresses prior
>    to assigning them to an interface whose DupAddrDetectTransmits
>    variable is greater than zero. Duplicate Address Detection MUST take
>    place on all unicast addresses, regardless of whether they are
>    obtained through stateful, stateless or manual configuration, with
>    the exception of the following cases:

Note that one of the exception cases is stateless addr conf when
configuring multiple addresses using the same IID. Is node-requirments
trying to override this exception? If so, it should be explicit about
it. Otherwise, I'm not sure why the above sentence is included in
node-requirements.

> 4.5.4 Default Address Selection for IPv6 - RFC3484
> 
>    Default Address Selection for IPv6 [RFC-3484] SHOULD be supported, if
>    a node has more than one IPv6 address per interface or a node has
>    more that one IPv6 interface (physical or logical) configured.
> 
>    If supported, the rules specified in the document MUST be
>    implemented. A node needs to belong to one site, however there is no
>    requirement that a node be able to belong to more than one site.

This is really weasle worded. Is 3484 mandatory to _implement_ or not?
You can't make its implementation dependent on whether there are
multiple addresses, since the number of addresses a node will have is
not something an implementor will know, as it's an operational issue.

>    DNS, as described in [RFC-1034], [RFC-1035], [RFC-1886], [RFC-3152]
>    and [RFC-3363] MAY be supported.  Not all nodes will need to resolve
>    names.  Note that RFC 1886 is currently being updated [RFC-1886-BIS].

1886-bis has been approved by the IESG I believe...

Also, I suspect this section really needs to talk about resolvers and
resolver behavior, rather than just say DNS. Most of the server issues
do not apply to generic IPv6 nodes. But almost every node will have
some sort of resolver...

> 5.3.1 Managed Address Configuration

IMO, it doesn't make sense to  talk about "implementing DHC" without
being more specific. I suspect that all of this section is about the
client part of DHC, not the server. It would be good to make this
clear. Ditto for 5.3.2.

   Stateless DHCPv6 [DHCPv6-SL], a subset of DHCPv6, can be used to
   obtain configuration information. A node that uses stateless DHCP
   must have obtained its IPv6 addresses through some other mechanism,
   typically stateless address autoconfiguration.

Does this even need mentioning? I.e, what are the real implications
for clients? Do they need to implement full blown dhc (the client
part)? Or do they implement some subset?  (Hmm... reading the related
draft, clients implement a subset... And this document has a normative
reference to the other ID, so either this document needs to be more
explicit about what stateless DHCPv6 is, or will have to wait on the
other document.)

> 6.1 Transition Mechanisms
> 
>    IPv6 nodes SHOULD use native addressing instead of transition-based
>    addressing (according to the algorithms defined in RFC 3484).

Is this a statement about what needs to be implemented? Or is this an
operational statement? (This document seems to be mostly about the
former, and this statement seems odd without more context...)

>    Routers do not need to support route optimization or home agent
>    functionality.
> 
>    Routers SHOULD support the generic mobile IP requirements.

I think it would be better to replace the above with something like:

  Routers SHOULD support the router-specific extensions defined in
  Section 8.3 of MIPv6

And include a normative reference to the document.

> 7.2 Securing Signaling between Mobile Nodes and Home Agents
> 
>    The security mechanisms described in [MIPv6-HASEC] MUST be supported
>    by nodes implementing mobile node or home agent functionality
>    specified in Mobile IP [MIPv6].

So would presumably the applicable parts of Section 8  of the mipv6
spec. Better to cite them explicitely.

>    Generic Packet Tunneling [RFC-2473] MUST be supported for nodes
>    implementing mobile node functionality or Home Agent functionality of
>    Mobile IP [MIPv6].

This may not need mentioning, as it may already be covered in  Section
8 of the mipv6 spec.

Actually, this entire section may warrant rethinking given the
existance of Section 8  in the MIPv6 spec.

Section 9 begins by saying:

> 9. Router-Specific Functionality
> 
>    This section defines general host considerations for IPv6 nodes that
>    act as routers.  Currently, this section does not discuss routin-
>    specific requirements.

an then immediately says

> 9.1.1 IPv6 Router Alert Option - RFC2711
> 
>    The Router Alert Option [RFC-2711] MUST be supported by nodes that
>    perform packet forwarding at the IP layer (i.e. - the node is a
>    router).

But this seems like a "forwarding-related" requirement. When do
routers send router alerts? They need to process them when they are
received, e.g., as part of MLD stuff. When else are they used?

> 11. Security Considerations

This section seems both too detailed and not detailed enough. Too
detailed in that it talks about security issues related to some
(arbitrary?) protocols like ICMPv6, but not detailed enough in that it
is anywhere complete and doesn't mention many other protocols that
could also be included if one were to include ICMPv6. My suggestion
would be to up-level here and not talk about detailed security issues
of individual protocols. If you want to do that, point to the security
sections in other documents. But if you do this, you'll have a hard
time deciding whether to mention every document or just some.

Does _this_ document itself introduce or raise any security issues not
covered elsewhere? That is the question this  document should focus
on. The answer may be mostly no.

Finally, there are an awful lot of references to IDs in the normative
section. That's a problem. See defn. of normative in
draft-rfc-editor-rfc2223bis-06.txt.

Nits/editorial:

>    The goal of this document is to define the set of functionality
>    required for an IPv6 node; the functionality common to both hosts and
>    routers.  Many IPv6 nodes will implement optional or additional

Sentence with semi-colon doesn't parse. :-(

> 3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464
> 
>    Transmission of IPv6 Packets over Ethernet Networks [RFC-2464] MUST
>    be supported for nodes supporting Ethernet interfaces.

I don't quite like the way this (and subsequent) sentences is
worded. We don't want to  imply that nodes that support IPv4 over
Ethernet must also support this...

How about:

   Nodes supporting IPv6 over Ethernet interfaces MUST implement
   Transmission of IPv6 Packets over Ethernet Networks [RFC-2464].
   
same applies to remaining LL sub-sections.

>    IPv6 over ATM Networks [RFC2492] MUST be supported for nodes
>    supporting ATM interfaces.  Additionally, the specification states:

what does "the specification" refer to? How about saying

   Additionally, RFC 2492 states:

>    option of disabling this function. The ability to understand specific
>    Router Advertisement optionss is dependent on supporting the
s/optionss/options/
>    specification where the RA is specified.

s/the RA/the particular RA option/

>    Redirect functionionality SHOULD be supported. If the node is a
spelling
>    router, Redirect functionionality MUST be supported.

>    Path MTU Discovery [RFC-1981] MAY be supported.  It is expected that
>    most implementations will indeed support this, although the possible
>    exception cases are sufficient that the used of "SHOULD" is not
>    justified.  The rules in RFC 2460 MUST be followed for packet
>    fragmentation and reassembly.

Same comment applies here as mentioned earlier.

>    Nodes that are routers MUST be able to generate link local addresses
>    as described in this specification.

"this specification" is ambiguious. Do you mean 2460?

>    If an application is going join any-source multicast, it SHOULD
>    support MLDv1.  If it is going to support Source-Specific Multicast,

s/join any-source multicast/to join any-source multicast group addresses/

also:

   If an application is going join any-source multicast, it SHOULD
   support MLDv1.  If it is going to support Source-Specific Multicast,
   it MUST support MLDv2 [MLDv2] and conform to the Source-Specific
   Multicast overview document [RFC3569]; refer to Source-Specific
   Multicast architecture document for details [SSMARCH].

Is worded oddly. If  A, you SHOULD do MLDv1. If B, you MUST do
MLDv2. Shouldn't the first SHOULD be a MUST as well? How can you not
support MLDv1 if you are going to join multicast groups and not going
to do MLDv2?

>    This specification MUST be supported if jumbograms are implemented
>    [RFC-2675].  One open issue is if this document needs to be updated,
>    as it refers to an obsoleted document.

Drop last sentence? I suspect it's irrelevant, as the updated that is
needed is cosmetic/editorial, not substantative. Right?

>   This document is currently being updated.

s/this document/RFC2893/

>   7.3 Generic Packet Tunneling in IPv6 Specification - RFC2473

nit: indention is wrong on this heading.

>    3DES-CBC does not suffer from the issues related to DES-CBC. 3DES-CBC
>    and ESP CBC-Mode Cipher Algorithms [RFC2451] MAY be supported. AES-
>    128-CBC [ipsec-ciph-aes-cbc] MUST be supported, as it is expected to
>    be a widely available, secure algorithm that is required for
>    interoperability. It is not required by the current IPsec RFCs,
>    however.

Perhaps add to last sentence, "but is expected to become required in
the future" ???

   act as routers.  Currently, this section does not discuss routin-
   specific requirements.

s/routin/routing/

>    At least the following two MIBs SHOULD be supported MIBs SHOULD be
>    supported by nodes that support an SNMP agent.

duplicate words.

> 10.1.1  IP Forwarding Table MIB
> 
>    Support for this MIB does not imply that IPv4 or IPv4 specific
>    portions of this MIB be supported.

Which MIB is this? (No reference provided...)

> 10.1.2 Management Information Base for the Internet Protocol (IP)

Ditto.

> 12.1 Normative
> 
>    [DHCPv6-SL]    R. Droms, "A Guide to Implementing Stateless DHCPv6
>                   Service", Work in Progress.

For all the references, please include the ID name, so folk can
actually figure out which ID it refers to. Also the RFC editor will
want to know this too, so they can put in the right references, in
case any are already RFCs.

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 28 Aug 2003 06:48:23 +0900 (JST)

> it. Otherwise, I'm not sure why the above sentence is included in

	there was a big discussion in the recent IETF meeting (don't remember
	which one) and the consensus was to drop "you can omit DAD for
	addresses with same IID" part from the DAD, IIRC (need to check
	minutes).  if my memory is corret, my guess is that the node
	requirement is more up-to-date on this issue.

itojun

---

From: Geoff Huston <[email-masked]>
Date: Thu, 28 Aug 2003 08:14:09 +1000

I see that the local use address draft has been revised and published as a WG
document.

In section 3.2.2 of the draft, it notes that, in reference to Locally
Assigned  Global IDs that  "the likelihood of conflict is small. "

I had noted in draft-huston-ipv6-local-use-comments-00.txt that  the
likelihood of conflict is given by  the formula:

P = 1 - ((n!)  / ((n**d)(n-d)!))

where n = 2**40 and d is the number of random 'draws' from the pool.

The likelihood of conflict exceeds 0.5 after only 1.24 million draws. I'd
contend that this is definitely not "small" as described in the draft.

It appears to me that the comment  in this section of the unique local
addr draft is misleading, and I'd like to request that this section of the
draft be replaced with a more rigorous mathematical analysis of the
probability of collision.

Thanks,

    Geoff

---

From: Thomas Narten <[email-masked]>
Date: Wed, 27 Aug 2003 21:08:27 -0400

> 	requirement is more up-to-date on this issue.

I too seem to recall a discussion or two on this topic, even before
vienna. But

1) should node-requirements be the document that updates this, or
   should addrconf be updated?

2) If the former, the words in the current document aren't  explicit
   enough. Especially given the following wording in
   node-requirements:

>    This document tries to avoid discussion of protocol details, and
>    references RFCs for this purpose.  In case of any conflicting
>    text, this document takes less precedence than the normative
>    RFCs, unless additional clarifying text is included in this
>    document.

Thomas

---

From: Brian Haberman <[email-masked]>
Date: Thu, 28 Aug 2003 08:13:54 -0400

Hi Geoff,

> contend that this is definitely not "small" as described in the draft. 

My disagreement with this calculation is two-fold.

The first issue I have is that these addresses are not meant to be routed
globally, so there is an additional variable that needs to be considered
when calculating P for collisions.  That is, the P above needs to take into
account the probability that two networks trying to use the same prefix are
connected.

My second issue is with the formula itself.  RFC 1889 uses an MD5 hash for
calculating its SSRC Identifier (a 32-bit number).  That document states:

          the probability that two sources independently pick the same value
          can be approximated for large N [20] as 1 - exp(-N**2 / 2**(L+1)).
          For N=1000, the probability is roughly 10**-4.

N represents the number sources (number of entities making a random 
selection)
and L is the length of the identifier.  I see this formula being more 
representative
of the probability of collision.

Regards,
Brian H.

---

From: Hans Kruse <[email-masked]>
Date: Thu, 28 Aug 2003 10:03:00 -0400

But don't "conflicts" matter only for separate sites that later decide to 
connect to each other using these addresses?

In that context 1 out of 1.24 million seems small.  That does not mean we 
should not include that math, just that the conclusion is valid, especially 
for an address type that is designed to be near-unique as opposed to 
guaranteed unique.

> contend that this is definitely not "small" as described in the draft.

Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems Management
Adjunct Associate Professor of Electrical Engineering and Computer Science
Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Geoff Huston <[email-masked]>
Date: Fri, 29 Aug 2003 09:54:26 +1000

You are correct in that the "conflicts" matters at the point that the two sites
want to interact in such a fashion that the expose their local use addresses
to each other, now or at any time in the future.

Now if you have a random selection algorithm that truly has 2**40 bits
of entropy the chances of any two identified random draws from
this space having a clash remains 1 / (2**40), but if you take the total
pool of such randomly drawn numbers and ask "how big does the pool
need to get to lift the change of a clash within the pool above 0.5?",
then the pool size is 1.24 million. If the expectation that this address
format is to be used extensively for local connectivity independently of
upstream connectivity then I would contend that uniqueness is essential,
and the local selection methodology should not be proposed, as its
uniqueness properties are flawed.

So I suppose I am saying that this is "nowhere near unique", and that if 
the entire idea
of this concept is to avoid the use of reused private RFC1918-styled addresses
and the associated NAT functionality, then this local selection algorithm 
should
not be included in this proposal.

    regards,

    Geoff

At 10:03 AM 28/08/2003 -0400, Hans Kruse wrote:
>should not include that math, just that the conclusion is valid, 
>especially for an address type that is designed to be near-unique as 
>opposed to guaranteed unique.
>

---

From: Geoff Huston <[email-masked]>
Date: Fri, 29 Aug 2003 10:41:21 +1000

Thanks for your response Brian,

You note two objections to my comments regarding the random self-selection
method as described in the local use address draft.

Firstly: "That is, the P above needs to take into account the probability that
two networks trying to use the same prefix are connected."

I would contend that this is an incomplete analysis of the uniqueness 
requirement.
The requirement for uniqueness is triggered when any two networks using
such self-selected global IDs as local address prefixes want to interact in 
such
a fashion that the expose their local use addresses to each other, now or 
at any
time in the future. This statement covers a broader range of potential 
scenarios
and underpins the entire argument for uniqueness in any form of addressing
architecture.

Your second issue is "with the formula itself".  The underlying reasoning 
behind the
formula:

is that the probability of a clash within a pool of numbers where the pool 
is of size
d and the number space is of size n is 1 minus the probability that all the 
selected
numbers are unique. This is a simple exercise in probabilities:

for a pool of size 2 the probability of uniqueness is (n-1)/n
for a pool of size 3 the probability of uniqueness is ((n-1)/n) x ((n-2)/n)
with the general solution as indicated above.

I would observe that this is a correct analysis of the probability of
a collision occurring within a pool of d selections from a total space
of n possible values.

You appear to be asking a different question, namely: "the probability
that two sources independently pick the same value", and this is a
question relating to degree of entropy in the random selection algorithm.
The formula provided above assumes 'perfect' entropy, where
the selection algorithm is equally likely to pack any of the n
possible values. In this case the changes of a collision occurring with a
pool of size 2 is 1/n. My comment is that the factors you need to be mindful of
are not only the true randomness of the random number generator,
but also the total size of the pool and the size of the number space.

regards,

    Geoff

---

From: Pekka Savola <[email-masked]>
Date: Fri, 29 Aug 2003 08:33:27 +0300 (EEST)

On Thu, 28 Aug 2003, Geoff Huston wrote:
[...]
> contend that this is definitely not "small" as described in the draft.

I consider this a bug.  Actually, the number of draws should be smaller, 
e.g. 1000, to avoid having local addresses misused where they should not.

That way, prople wouldn't get delusions to e.g. route such addresses in 
the Internet.  1.24 million draws until a probable conflict could still 
sound attractive.

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

---

From: Geoff Huston <[email-masked]>
Date: Fri, 29 Aug 2003 16:01:43 +1000

Of course one could take this approach to its logical conclusion and
specify a single global ID to use in such a context. That will reduce
the minimum number of draws to generate a collision to 2. Is that what
you are after?

thanks,

    Geoff

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Aug 2003 14:29:52 +0200

Geoff,

Now I understand your argument, I don't think it holds water.
The fact that there is a 50% chance of a conflict somewhere inside
a set of a million enterprises doesn't bother me in the least.

If an enterprise has direct interconnection to 2**8 other enterprises,
in a space of 2**40 random numbers, that enterprise is looking at a 
2**-32 chance of hitting a conflict and being forced to renumber. 
That's acceptable.

Even if an enterprise expects direct interconnecion to 2**20 other 
enterprises, the chance of having to renumber is 2**-20, i.e. one
in a million. That's probably acceptable.

If an enterprise network manager doesn't think it's acceptable,
s/he can wait until IANA has set up the centrally allocated solution,
or use a PA prefix.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: "Alan E. Beard" <[email-masked]>
Date: Fri, 29 Aug 2003 10:42:15 -0400 (EDT)

Pekka:

I am distressed.  Please see inline for specifics.

AEB

> the Internet.  1.24 million draws until a probable conflict could still
Hmmm.  Was not one of the stated benefits of unique-local the uniqueness
(or near-uniqueness) of the address allocations generated by proposed
allocation algorithm?  A suggestion to _deliberately_ increase the
probability of allocation conflict strikes me as a fundamental conceptual
change to the proposal.  With a change of this magnitude, it seems to me
that the resulting draft would be so greatly at variance with the
conceptual basis of the Hinden original that a new, wholly independent
proposal would be in order, leaving the unique-local draft to stand or
fall of its own merit.

Additionally, such a suggestion, if implemented, would effectively
prohibit one of the chief *legitimate* uses of GUPI address address
allocations: routing between private networks on private (or VPN) links
under bilateral agreements between the end networks.  Private routing
arrangements are considered highly desirable to enterprise network
operators (in fact, most enterprise network managers will tell you, with
quite considerable warmth, that such arrangements are indispensible);
decreased probability of uniqueness in allocations would, IMHO, leave the
unique-local proposal fatally flawed.  If we wish to discourage ubiquity
in deployment of NAT6, perhaps we should look to notions other than this.

Furthermore, we can discourage global routing of unique-local prefixes by
inserting into the unique-local draft more explicit language prohibiting
propagation of such prefixes into the global routing tables.  Some
suggested text (in rough form) is given here:

* Manufacturers of routers MUST include in router code a routing black
hole for the entire unique-local address block. Router manufacturers MUST
ensure that said black hole cannot be deconfigured, turned off, or
otherwise overridden in toto; however, manufacturers MAY provide a
configuration facility to "punch through" the black hole for
user-specified prefixes within the unique-local block. Router
manufacturers SHOULD include in user documentation language to the effect
that routing of unique-local prefixes beyond site boundaries contravenes
IETF recommendations, and that routing of unique-local prefixes may be
configured *only* where the user can ensure that such routes will not be
propagated into third-party routing tables except by prior agreement
between private networks, and that under no circumstances will such routes
be propagated into public network routing tables.

* Service Providers MUST configure a black hole for the entire
unique-local address block on all links which carry public-network
traffic. Service Providers SHOULD configure a black hole for the entire
unique-local address block at all AS boundary points.

I might suggest that similar language be added to the appropriate
router-requirements documents when (or if) an RFC on this matter is
finally published.

The private-link ox is largely property of the enterprise network
managers; we are unlikely to greatly endear ourselves to the enterprise
network folks if we gore that ox, even inadvertently, in our crusades to
extirpate NAT and prevent the public routing of local address spaces.  I
think it unwise to provoke these folks still further.

In summary:

1) the suggestion to make unique-local address allocations considerably
less than unique would, if incorporated into the extant draft,
fundamentally alter the concepts upon which the original Hinden proposal
appears to have been crafted; if such a suggestion is to be considered, a
more appropriate means might be a new individual draft

2) an allocation scheme for unique-local prefixes which produces a
probability of collision above, say, one in several million, will likely
render unique-local addresses of very limited utility for one (perhaps
more than one) of the legitimate uses of such address space; specifically,
interconnection of private (frequently enterprise) networks over private
links

3) increased rate of conflict in allocation of prefixes may tend to
encourage, rather than elimiate, use of NAT6

4) we can, IMO, discourage global routing of unique-local prefixes by
means other than increasing the probability of address conflicts: one such
means (perhaps partial) is suggested above

Please disabuse me of any errant notions in the suggestions above. ;-)

Regards,

AEB

-- 
Alan E. Beard <[email-masked]>
AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809
863.815.2529

---

From: Hans Kruse <[email-masked]>
Date: Fri, 29 Aug 2003 10:14:34 -0400

I am still not sure I agree with the conclusion.  If I execute an address 
draw, and then decide to connect to 5 other networks, what is the 
probability of a conflict?  It greater than 1/(2**40), but much, much 
smaller than 0.5; the "0.5" problem arises only if someone wants to connect 
1.24 million networks.

The more important point to me, however, is that the locally generated 
random prefix is only one of two mechanisms.  If I were planning to 
interconnect a bunch of locally addressed networks, I would get 
registry-assigned local prefixes anyway -- which are designed to be 
globally unique.  For a nomadic network using locals internally only, the 
random selection should be fine, even if you interconnect with a small 
number of other networks on occasion.

--On Friday, August 29, 2003 09:54 +1000 Geoff Huston <[email-masked]> 
wrote:

> the entire idea of this concept is to avoid the use of reused private
> RFC1918-styled addresses and the associated NAT functionality, then this
> local selection algorithm should not be included in this proposal.

---

From: "Brian Haberman" <[email-masked]>
Date: Thu, 28 Aug 2003 08:13:54 -0400

Hi Geoff,

Regards,
Brian H.

---

From: "Geoff Huston" <[email-masked]>
Date: Thu, 28 Aug 2003 08:14:09 +1000

Thanks,

    Geoff