so what has happen to this? Still no feedback from authors or chairs or?
On Wed, 11 Jul 2007, Paul Vixie wrote:
snip
I'm not sure what the status of Paul's document is since the drafts
directory only contains this one:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-02.txt
Is
so what has happen to this? Still no feedback from authors or chairs or?
nothing.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
On 2007-07-13 18:16, Stephen Sprunk wrote:
...
As far as why site has been abused to mean administrative domain,
that comes from the IETF and RIRs being very ISP-centric, as I said; a
single downstream connection denotes a single site regardless of how
complex the internal network behind it is
Thus spake Roger Jorgensen [EMAIL PROTECTED]
On Fri, 13 Jul 2007, Stephen Sprunk wrote:
Also, in the case of SLAs, the utility of the addresses is
impacted greatly by whether you consider a site to be a
single administrative domain, where there would not be
internal collisions, vs. considering
A site is a network of computers with a single administration, ...
Where has the IETF redefined the meaning of the word site? ...
This has been a longstanding problem in the IETF; in fact, the inability
to agree on what site means was one of the reasons SLAs were ...
why does it mather
.)
Thanks - Fred
[EMAIL PROTECTED]
-Original Message-
From: Jeroen Massar [mailto:[EMAIL PROTECTED]
Sent: Friday, July 13, 2007 7:41 AM
To: Paul Vixie
Cc: IETF Ops; ipv6@ietf.org
Subject: What is a site (Re: draft-ietf-ipv6-ula-central-02.txt)
[cross cc'd to v6ops as this sounds
Thus spake Roger Jorgensen [EMAIL PROTECTED]
On Thu, 12 Jul 2007, Stephen Sprunk wrote:
This has been a longstanding problem in the IETF; in fact,
the inability to agree on what site means was one of the
reasons SLAs were deprecated. The word site is often
abused to mean administrative domain
On Fri, 13 Jul 2007, Stephen Sprunk wrote:
Thus spake Roger Jorgensen [EMAIL PROTECTED]
On Thu, 12 Jul 2007, Stephen Sprunk wrote:
This has been a longstanding problem in the IETF; in fact,
the inability to agree on what site means was one of the
reasons SLAs were deprecated. The word site is
As far as why site has been abused to mean administrative
domain, that comes from the IETF and RIRs being very
ISP-centric, as I said; a single downstream connection
denotes a single site regardless of how complex the
internal network behind it is or how many other locations it
serves.
which again give us some sort of aggregation... is this something we
want? (althought it would fit us, where I work, perfectly since we would
get almost all the space we need quite easy:-)
I would agree with Tony that aggregation of ULA-G space should be allowed.
I know there are many
Thus spake [EMAIL PROTECTED]
A site is a network of computers with a single administration,
this can mean indeed a major corporation (who maybe even
require multiple /48's which is why rfc4193 is a bit off to cover
those cases)
Where has the IETF redefined the meaning of the word site?
In
On Tue, 10 Jul 2007, james woodyatt wrote:
snip
Hmmm. I guess the alternative is that the purpose of ULA-C/G is to mitigate
the risk of collision when merging on the order of hundreds of thousands of
ULA networks in one routing realm... sort of like creating a local DFZ of a
sort.
Forgive
It is more about creating a address space that can be used
for OTHER thing than the DFZ-way of thinking Internet we have now.
Up until now, I've been on the fence regarding ULA-centrally-registered
address space, but after several comments in the past two days, I now
support defining these
[EMAIL PROTECTED] wrote:
It is more about creating a address space that can be used
for OTHER thing than the DFZ-way of thinking Internet we have now.
Up until now, I've been on the fence regarding ULA-centrally-registered
address space, but after several comments in the past two days, I
The question here still remains though: how really different
is this from PI. In effect it is non-DFZ-PI space that is
being defined here.
PI (Provider Independent) is not a relevant term to refer to addresses
that are allocated to end-user organizations for use in their own
networks. There
On Wed, 2007-07-11 at 12:21 +0100, Jeroen Massar wrote:
The question here still remains though: how really different is this
from PI. In effect it is non-DFZ-PI space that is being defined here.
RIR's themselves could thus also set aside a /20 or something and
allocate /40-/48's from that
It is more about creating a address space that can be used for OTHER thing
than the DFZ-way of thinking Internet we have now.
yup.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests:
Paul's draft which assigns 12 bits to each RIR seems to be the right
thing since it clearly delineates which RIR is responsible for each
subset range, and therefore if an RIR policy dictates special handling
for certain ULA addresses, there is a simple technical means to
accomplish this.
However, they are Unique, and they are Local. Perhaps ULRA (Unique Local
Registered Addresses) is sufficiently different from ULA that people
will not accidentally look to RFC 4193 for advice?
suits me.
IETF IPv6 working
7:24 AM
To: ipv6@ietf.org
Subject: Re: draft-ietf-ipv6-ula-central-02.txt
Paul's draft which assigns 12 bits to each RIR seems to be the right
thing since it clearly delineates which RIR is responsible for each
subset range, and therefore if an RIR policy dictates special
handling
On Wed, 11 Jul 2007, Tony Hain wrote:
I have a few points on Paul's draft:
snip
Major complaint - aggregation
There needs to be at least a modest capability to aggregate. I
understand the aversion to having these show up in the DFZ, but if 5.1 were
really true that would not be an
Roger Jorgensen wrote:
On Wed, 11 Jul 2007, Tony Hain wrote:
I have a few points on Paul's draft:
snip
Major complaint - aggregation
There needs to be at least a modest capability to aggregate. I
understand the aversion to having these show up in the DFZ, but if
5.1 were
really true
On Mon, 2007-07-09 at 10:05 -0500, Stephen Sprunk wrote:
* ULA-C/G are NOT ment to be used on internet
OTOH, there's no way for the IETF or RIRs to stop it from happening. I'm
not saying it will, but it is irresponsible to claim it won't when there's
no mechanism to enforce that.
On Mon, 2007-07-09 at 16:44 -0700, bill fumerola wrote:
AfriNIC apparently has decided they can get into the routability business
by stipulating that PIv6 space allocated must be 'announced' within a
year or it will be taken back. the first time they use that clause to
take back space,
On Mon, 9 Jul 2007, james woodyatt wrote:
On Jul 3, 2007, at 13:23, Stephen Sprunk wrote:
The only difference is that if there's a registry, the end-users have
someone to sue when a collision happens.
This sounds like yet another reason to hate ULA-C. Seriously.
must be you American (I
[EMAIL PROTECTED]
Responder a: [EMAIL PROTECTED]
Fecha: Mon, 9 Jul 2007 16:44:18 -0700
Para: Stephen Sprunk [EMAIL PROTECTED]
CC: ipv6@ietf.org
Asunto: Re: draft-ietf-ipv6-ula-central-02.txt
On Mon, Jul 09, 2007 at 09:48:12AM -0500, Stephen Sprunk wrote:
Good grief. The RIRs today cannot
On Jul 10, 2007, at 04:38, Roger Jorgensen wrote:
On Mon, 9 Jul 2007, james woodyatt wrote:
On Jul 3, 2007, at 13:23, Stephen Sprunk wrote:
The only difference is that if there's a registry, the end-users
have someone to sue when a collision happens.
This sounds like yet another reason to
Thus spake Roger Jorgensen [EMAIL PROTECTED]
On Mon, 9 Jul 2007, james woodyatt wrote:
On Jul 3, 2007, at 13:23, Stephen Sprunk wrote:
The only difference is that if there's a registry, the end-users
have someone to sue when a collision happens.
This sounds like yet another reason to hate
On Tue, 2007-07-10 at 14:11 -0500, Stephen Sprunk wrote:
Thus spake Per Heldal [EMAIL PROTECTED]
On Mon, 2007-07-09 at 10:05 -0500, Stephen Sprunk wrote:
* ULA-C/G are NOT ment to be used on internet
OTOH, there's no way for the IETF or RIRs to stop it from happening. I'm
not saying
nope.
Hmmm. I guess the alternative is that the purpose of ULA-C/G is to mitigate
the risk of collision when merging on the order of hundreds of thousands of
ULA networks in one routing realm... sort of like creating a local DFZ of
a sort.
Forgive me, but that sounds even more surreal.
for the constructive education.
Kevin
-Original Message-
From: Pekka Savola [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 19, 2007 2:41 PM
To: Jeroen Massar
Cc: Thomas Narten; Mark Andrews; ipv6@ietf.org
Subject: Re: draft-ietf-ipv6-ula-central-02.txt - reverse DNS
On Tue, 19
:[EMAIL PROTECTED]
Sent: Thursday, June 21, 2007 11:42 AM
To: IETF IPv6 Mailing List
Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case
On Jun 21, 2007, at 11:03, Paul Vixie wrote:
mark andrews has [observed] that there is no need for the
resolution perimeter of a PTR to differ from
At this point it is plain to see that ULA-C is nothing but PI
address space, because the IETF is in no position to enforce
otherwise. So please, let's just call it what it is.
The IETF is not in a position to enforce the special handling of ULA-C
addresses however, IANA via the RIRs is in
On 2007-07-09 13:58, Jeroen Massar wrote:
...
Now I do see another use for this kind of address space, but then it
should not be called this way. It could be used for ID/LOC solutions,
where these kind of addresses are Explicit-non-DFZ addresses. But if
that is the reason for what folks want to
Having had my name on RFC 1918, I think understand some of the issues.
There is precisely one that I find at all interesting in this proposal,
having stated the concern in RFC 1627:
* avoiding collisions, and Geoff Huston's math demonstrates the
likelihood of that happening
But one
Thus spake Eliot Lear [EMAIL PROTECTED]
Stephen Sprunk wrote:
The supposed use case for ULA-C is large orgs who
interconnect privately with other large orgs. If you _don't_
allow ULA-Cs in the global reverse DNS, then every org in
the internetwork must hack their local DNS servers to
recognize
Thus spake [EMAIL PROTECTED]
At this point it is plain to see that ULA-C is nothing but PI
address space, because the IETF is in no position to enforce
otherwise. So please, let's just call it what it is.
The IETF is not in a position to enforce the special handling of
ULA-C addresses
Thus spake Roger Jorgensen [EMAIL PROTECTED]
On Mon, 9 Jul 2007, Eliot Lear wrote:
At this point it is plain to see that ULA-C is nothing but PI
address space, because the IETF is in no position to enforce
otherwise. So please, let's just call it what it is.
it is NOT the same, there are
, with trivial ACL's the private network could be managed out
of PI/PA.
-Original Message-
From: Stephen Sprunk [mailto:[EMAIL PROTECTED]
Sent: Monday, July 09, 2007 9:53 AM
To: Eliot Lear
Cc: Thomas Narten; Mark Andrews; ipv6@ietf.org; Pekka Savola
Subject: Re: draft-ietf-ipv6-ula-central
[eliot lear]
Having had my name on RFC 1918, I think understand some of the issues.
forgive them, eliot. my name is on ULA-G but a lot of people (including
you, for example) still assume that i don't understand all of the issues.
RFC 1918 not being unique meant that providers really had no
Paul Vixie wrote:
as the contributor of the DNS-related paragraph near the end of RFC 1918
section 5, i can tell you that whatever the RFC says will only be a general
hint to operators and implementors, who will proceed to do whatever they
darn well want.
Can we then not make the very simple
On Jul 3, 2007, at 13:23, Stephen Sprunk wrote:
The only difference is that if there's a registry, the end-users
have someone to sue when a collision happens.
This sounds like yet another reason to hate ULA-C. Seriously.
--
james woodyatt [EMAIL PROTECTED]
member of technical staff,
fortunately then, ULA hasn't caught on.
Actually, we have no way of knowing that, which is
a feature, not a bug.
Brian
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests:
On 2007-07-04 04:23, Paul Vixie wrote:
With the current draft, that is correct. With Paul's proposed changes of
27 Jun, they definitely aggregate at the LIR and RIR levels, making it
much harder to defend the position that they won't end up in the DFZ.
the aggregation present in that version
With the current draft, that is correct. With Paul's proposed changes
of
27 Jun, they definitely aggregate at the LIR and RIR levels, making it
much harder to defend the position that they won't end up in the DFZ.
the aggregation present in that version was unintentional. if you look at
[EMAIL PROTECTED] wrote:
With the current draft, that is correct. With Paul's proposed changes of 27
Jun, they definitely aggregate at the LIR and RIR levels, making it much harder
to defend the position that they won't end up in the DFZ.
the aggregation present in that version was
[vixie]
my concern about aggregation is that if someone receives 8 /48's that are
aligned as a /45 then they could conceivably advertise it as a /45. i
hope that IANA will allocate nonaligned blocks, or perhaps give even
numbers to one RIR and odd numbers to the next, and that the RIRs
scott liebrand has already followed up on most of what i thought interesting
in brian dickson's latest post on this thread, so i'll limit myself to this:
The thing we need to be concerned about is not only route leakage, but
packet leakage, especially if it has the ability to affect the core
Wouldn't such packets be considered bogons and get blocked (either via
specific filters for fc00::/7 or uRPF) at the edge of your network before
the server even saw them?
right up to the point where they fill one of my peering circuits, yes.
after that, i have to track them back to the source
Thus spake Scott Leibrand [EMAIL PROTECTED]
I think what we wanted to get rid of in IPv6 was one-to-many
NAT, also know as PAT (among other names). In IPv6, we
can stick to one-to-one NAT, which eliminates most of the
nastiness we associate with NAT in today's IPv4 world.
The only legitimate
Thus spake [EMAIL PROTECTED]
BTW, this business of birthday paradox clashes has been beaten
on wrt to other random address assignment paradigms too; in
particular, CGAs. There, you have ~60 (?) bits for uniqueness
but it has still been implied that any non-zero probability
of collision is too
Thus spake Brian E Carpenter [EMAIL PROTECTED]
On 2007-06-27 16:31, Kevin Kargel wrote:
...
The problem I see with having small ULA-C allocations is that as people
move around geographically those allocations will lose aggrebility.
I don't understand your comment. No ULA prefix aggregates
Stephen Sprunk wrote:
With the current draft, that is correct. With Paul's proposed changes
of 27 Jun, they definitely aggregate at the LIR and RIR levels, making
it much harder to defend the position that they won't end up in the DFZ.
I'm not quite following your logic here. If ARIN
Thus spake Scott Leibrand [EMAIL PROTECTED]
Stephen Sprunk wrote:
With the current draft, that is correct. With Paul's proposed changes of
27 Jun, they definitely aggregate at the LIR and RIR levels, making it
much harder to defend the position that they won't end up in the DFZ.
I'm not
With the current draft, that is correct. With Paul's proposed changes of
27 Jun, they definitely aggregate at the LIR and RIR levels, making it
much harder to defend the position that they won't end up in the DFZ.
the aggregation present in that version was unintentional. if you look at
On 2007-07-01 17:53, [EMAIL PROTECTED] wrote:
A site is a network of computers with a single
administration, this can mean indeed a major corporation (who
maybe even require multiple /48's which is why rfc4193 is a
bit off to cover those cases)
Where has the IETF redefined the meaning of the
My main question about ULA-C still stands: how is it
different from PI?
To understand the difference between PI and ULA-C you need to understand
the difference between the public Internet and an IP internetwork. Any
set of networks that use the Internet Protocols are an IP internetwork.
A site is a network of computers with a single
administration, this can mean indeed a major corporation (who
maybe even require multiple /48's which is why rfc4193 is a
bit off to cover those cases)
Where has the IETF redefined the meaning of the word site?
In plain English, this word
First, s/laptop/platform - where, a platform could be
something relatively small (like my laptop) or something
quite a bit larger (like a cruise ship). Any points
in-between (planes, trains, automobiles, etc.) also meet the
description. But, all of them are platforms and all of them
are
On 2007-06-27 20:26, Scott Leibrand wrote:
Brian E Carpenter wrote:
Scott, you say
In a situation like this, I need to be able to resolve PTRs for hosts
using my neighboring networks' ULA space
Why do you need to do this?
For all the same reasons I need to resolve PTRs of hosts on the
Brian E Carpenter wrote:
Scott, you say
In a situation like this, I need to be able to resolve PTRs for hosts
using my neighboring networks' ULA space
Why do you need to do this?
The need can be seen, but the big question is: why does one need it in
the *global* root.
If one is in a
On 2007-06-27 00:42, Roger Jorgensen wrote:
On Thu, 21 Jun 2007, james woodyatt wrote:
snip
We successfully deprecated site-local unicast addressing by painting
it with the stink of IPv4 network address translation. However, we
retained the technical consensus that unreachable nodes still
: draft-ietf-ipv6-ula-central-02.txt
On Jun 25, 2007, at 17:01, Geoff Huston wrote:
i.e. if we all pick numbers and stuff them into the DNS,
then by the
time the 1,240,000 selection had taken place the probability that a
collision has occurred exceeds 0.5
That's only a problem
On 2007-06-27 16:31, Kevin Kargel wrote:
...
The problem I see with having small ULA-C allocations is that as people
move around geographically those allocations will lose aggrebility.
I don't understand your comment. No ULA prefix aggregates ever - they
will always be specific routes, and
james woodyatt wrote:
[..]
I merely contend-- albeit heretically-- that L=0 in RFC 4193 is
nonsense. We should hand fc00::/8 back to IANA and revise RFC 4193 so
that fd00::/8 is the ULA prefix identifier, where all addresses are
allocated according to to the procedure currently defined, have
On Jun 27, 2007, at 04:09, Brian E Carpenter wrote:
On 2007-06-27 00:42, Roger Jorgensen wrote:
On Thu, 21 Jun 2007, james woodyatt wrote:
snip
We successfully deprecated site-local unicast addressing by
painting it with the stink of IPv4 network address translation.
However, we retained
Brian E Carpenter wrote:
Scott, you say
In a situation like this, I need to be able to resolve PTRs for hosts
using my neighboring networks' ULA space
Why do you need to do this?
For all the same reasons I need to resolve PTRs of hosts on the
Internet. I'm a network engineer, so my main
Discussions on this list seem to indicate that globally routable PI might
not be attainable for very small sites such as my laptop. That would be an
example of where I can't get my own PI prefix, right?
[EMAIL PROTECTED]
on a site small enough to be its own network (like your laptop), i
@ietf.org
Subject: Re: draft-ietf-ipv6-ula-central-02.txt
Discussions on this list seem to indicate that globally
routable PI might
not be attainable for very small sites such as my laptop.
That would be an
example of where I can't get my own PI prefix, right?
[EMAIL PROTECTED
From: Templin, Fred L [EMAIL PROTECTED]
I am talking about a laptop that connects an arbitrarily-
complex internal network of virtual hosts and routers, and
an arbitrarily-complex set of external devices attached on,
e.g., Ethernet, Bluetooth, etc. ...
so, there's a routing protocol here?
I am talking about a laptop that connects an arbitrarily-
complex internal network of virtual hosts and routers, and
an arbitrarily-complex set of external devices attached on,
e.g., Ethernet, Bluetooth, etc. ...
First, s/laptop/platform - where, a platform could be
something relatively
Christian Huitema wrote:
And before you leap into I'm never going to use the DNS, so whats the
problem? please also note that I'm not saying that putting these
addresses into the DNS is good, bad or indifferent.
What about indifferent?
Suppose that we pre-populate the ip6.arpa tree with
On 25 Jun 2007, at 10:39pm, Scott Leibrand wrote:
Apparently people are still having a hard time visualizing use
cases for ULA-C, so let me try again to lay one out:
[...]
In addition, I am likely to change ISPs over time, and I'm too
small to qualify for PI space,
It seems that if you
Leo Vegoda wrote:
On 25 Jun 2007, at 10:39pm, Scott Leibrand wrote:
Apparently people are still having a hard time visualizing use cases
for ULA-C, so let me try again to lay one out:
[...]
In addition, I am likely to change ISPs over time, and I'm too small
to qualify for PI space,
On Jun 25, 2007, at 22:28, Christian Huitema wrote:
Suppose that we pre-populate the ip6.arpa tree with synthetic name
server records, so that the name server for a given ULA prefix
ula-48::/48 (ULA-C or not) always resolves to ula-48::1 (or any
other suitably chosen anycast host
On Tue, 19 Jun 2007, Pekka Savola wrote:
On Tue, 19 Jun 2007, Thomas Narten wrote:
And help me understand how this equates to the AS112 issues. For sites
that (today) get PI space and don't actually advertise it to the
internet, aren't the DNS issues _exactly_ the same?
IMHO, if reverse DNS
On Thu, 21 Jun 2007, Brian E Carpenter wrote:
I see Thomas' argument for tolerating occasional use of entries in the
global DNS for ULAs - but it seems that it leads to too many complications
to be recommended. Since I'm sure the IETF isn't ready yet to endorse the
reality of split DNS
On Thu, 21 Jun 2007, james woodyatt wrote:
snip
We successfully deprecated site-local unicast addressing by painting it with
the stink of IPv4 network address translation. However, we retained the
technical consensus that unreachable nodes still need to be uniquely
addressable, and what's
... and then you are back to being bound to some IP addresses (for
your DNS) belong to someone and you might not want that at all.
Enterprises changing providers also need to change IP for
their DNS, or
simple get PI for these IP addresses. And if you get PI, why ULA-C?!
Discussions on
Paul Vixie wrote:
Apparently people are still having a hard time visualizing use cases for
ULA-C, so let me try again to lay one out:
...
thanks.
And thank you for your thoughtful and reasoned response.
So, again, I see that ULA-C is a very simple solution to fill a very useful
So perhaps another question is whether it is too much to ask
for more certainty (ULA-C) and less mystery (RFC4193 ULA)?
So, you reckon the chance of an administrative error in ULA-C
land giving two users the same prefix is less than the
2^-40 chance of a ULA clash between two users?
On Wed, Jun 20, 2007 at 12:27:17PM +0200, Eliot Lear wrote:
There are two that I can point you at, and perhaps the temporal
difference would be at least amusing:
* Renumbering: Threat or Menace?, Lear, Katinsky, Tharp, et al,
Proceedings of the Tenth Systems Administration
Jeroen,
Touching on just one aspect of your thoughtul post:
DNS is an integral part of addressing and if
we're going to move forward with ULA-C as delegated
addressing then let
us move forward with addressing in its entirety.
So you want a disconnected address space which gets
-Original Message-
From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 24, 2007 11:59 PM
To: Templin, Fred L
Cc: james woodyatt; IETF IPv6 Mailing List
Subject: Re: draft-ietf-ipv6-ula-central-02.txt
So perhaps another question is whether it is too much
Templin, Fred L wrote:
Jeroen,
Touching on just one aspect of your thoughtul post:
DNS is an integral part of addressing and if
we're going to move forward with ULA-C as delegated
addressing then let
us move forward with addressing in its entirety.
So you want a disconnected address
-Original Message-
From: Jeroen Massar [mailto:[EMAIL PROTECTED]
Sent: Monday, June 25, 2007 8:27 AM
To: Templin, Fred L
Cc: bill fumerola; ipv6@ietf.org
Subject: Re: draft-ietf-ipv6-ula-central-02.txt
Templin, Fred L wrote:
Jeroen,
Touching on just one aspect of your
BTW, this business of birthday paradox clashes has been beaten
on wrt to other random address assignment paradigms too; in
particular, CGAs. There, you have ~60 (?) bits for uniqueness
but it has still been implied that any non-zero probability
of collision is too great.
Fred
[EMAIL
Templin, Fred L wrote:
[..]
If you are only connecting to another ULA network, then why would one
ever need NS entries in ip6.arpa for this space?
To aid in connecting to another ULA network.
So you are able to setup routing between those two sites, but feeding
them with NS entries for your
Jeroen,
-Original Message-
From: Jeroen Massar [mailto:[EMAIL PROTECTED]
Sent: Monday, June 25, 2007 9:00 AM
To: Templin, Fred L
Cc: bill fumerola; ipv6@ietf.org
Subject: Re: draft-ietf-ipv6-ula-central-02.txt
Templin, Fred L wrote:
[..]
If you are only connecting to another
]
Sent: Monday, June 25, 2007 9:17 AM
To: Jeroen Massar; bill fumerola
Cc: ipv6@ietf.org
Subject: RE: draft-ietf-ipv6-ula-central-02.txt
Jeroen,
Touching on just one aspect of your thoughtul post:
DNS is an integral part of addressing and if we're going to move
forward with ULA-C
Templin, Fred L wrote:
[..]
Thus you are connecting to the Internet, using IPv4 or IPv6 doesn't
matter, you have a dependency on the Internet. As such you are not
working dis-connected from the Internet and you have a
dependency on it.
Only when you want to connect to another site.
Thus
Jeroen Massar wrote:
As such, what is the 'local' part again, how local is it really? And how
is ULA-C then different from PI? Why bother people with this ULA-C thing
when they really need PI in the first place? Which they can already get
for $100/year from ARIN and which will be guaranteed
On 25 Jun 2007, at 1:17pm, Scott Leibrand wrote:
[...]
PI space is *not* available, *at any price*, to small sites.
How many of these sites that are too small to qualify for PI space
are likely to have such a large number of inter-site connections that
there is a credible risk that there
Leo Vegoda wrote:
On 25 Jun 2007, at 1:17pm, Scott Leibrand wrote:
PI space is *not* available, *at any price*, to small sites.
How many of these sites that are too small to qualify for PI space are
likely to have such a large number of inter-site connections that
there is a credible risk
On Jun 25, 2007, at 09:33, Templin, Fred L wrote:
I already gave my use-case in:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg07806.html
The use-case I am most interested in is Mobile Ad-Hoc Networks
(MANETs) in which two or more MANETs can merge (e.g., due to
mobility). If each
: bill fumerola; ipv6@ietf.org
Subject: Re: draft-ietf-ipv6-ula-central-02.txt
Templin, Fred L wrote:
[..]
Thus you are connecting to the Internet, using IPv4 or IPv6 doesn't
matter, you have a dependency on the Internet. As such you are not
working dis-connected from the Internet and you
Templin, Fred L wrote:
Jeroen,
=20
Touching on just one aspect of your thoughtul post:
=20
DNS is an integral part of addressing and if
we're going to move forward with ULA-C as delegated=20
addressing then let
us move forward with addressing in its entirety.
So you want a
james woodyatt wrote:
On Jun 25, 2007, at 09:33, Templin, Fred L wrote:
I already gave my use-case in:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg07806.html
The use-case I am most interested in is Mobile Ad-Hoc Networks
(MANETs) in which two or more MANETs can merge (e.g., due
Depends on what level of collision risk you are happy with, and this
depends on the scenario where you are assessing that risk.
[...]
- a set of us pick numbers from a pool, and we compare numbers. The
probability that two or us have picked the same number is the case where
a random
On Jun 25, 2007, at 17:01, Geoff Huston wrote:
i.e. if we all pick numbers and stuff them into the DNS, then by
the time the 1,240,000 selection had taken place the probability
that a collision has occurred exceeds 0.5
That's only a problem for people who have to pick a number that
1 - 100 of 196 matches
Mail list logo
