>
> A simple api ext doc would be great. But not part of the advanced api.
> We need to ship the base and advanced apis now.
>
That's what I was aiming for; a short and simple advanced api socket
extension doc as a guideline for MIPv6 compatible applications.
I agree that the server side app
> > In your previous mail you wrote:
> >
> >An alternative approach could be: If the application cares about
> >the source address, it can use the Mobile IP API to figure out which
> >ones are home address, which ones are care-of address, and than
> >explicitly "bind" the socket
> I think that we should stop calling these addresses "site-local",
> as that is prone to confusion. We would create a separate set
> of globally-unique/provider-independent (GUPI? Pronounced
> "guppy" or "goopy", depending on how much you like them? :-))
> addresses for use as local addresses i
Just as note thus far with mipv6 testing and technology interoperation
with other mipv6 vendors not one application has had to be altered to
support mipv6 (e.g. ftp, telnet, streaming video/audio, sip, and a few
others). Clearly they had to be ported to IPv6 but nothing special was
done for mipv6
John,
I have not found any more deprecated cases. But will keep looking just
in case.
For the M bit. If it is set to a client then the client must find a
stateful server for managed addresses to be unconditionally mandatory
compliant. Rationale is if the M bit is set the network administrators
> => in order to use the API, an application needs to be changed.
> So with only the API, the only way to influence the Co@/H@ choice
> is to change all common applications... So the API will get only
> very limited use and the smart user should still wait for a device
> to fulfill his needs.
>
Pekka / Margaret
My $0.02 about the hash/random/collision issue: It's a non-issue.
The prefix generation happens only one time for the site. Collisions
would not be detected until two sites merge or establish a VPN
connection.
The site gets its GUPI /48 prefix once, then the network administrato
Jari,
> Jari Arkko wrote:
> The question is: if you need perfectly unique addresses,
> why can't you use normal, global addresses? There we
> already have an existing registration process and
> standards.
Pardon me? There is no such thing for end-sites as of today.
> My thinking is that global a
Pekka Nikander wrote:
"Good enough" ones are easy to generate without too
much human intervention, for example, without any
connection to the registry. OTOH, they are not
necessarily unique, and therefore not "good enough"
for some people. IMHO, both types are needed.
Pekka,
I still don't kn
On Sun, 24 Nov 2002, Pekka Nikander wrote:
> Michel Py wrote:
> >> There is room for both models at the same, and "good enough" is not
> >> going to be good enough for everybody.
>
> Margaret Wasserman wrote:
> > I would need to see a very compelling case for why two types
> > of globally-unique/p
Pekka,
> Pekka Nikander wrote:
> Thus, from my point of view, the differences seem to
> boil down into two issues:
> 1. In the mixed space method, you can defer your
> registration and still have a fairly large probability
> of succeeding later in registration.
> 2. In the split space meth
> It is actually my (weak) understanding that taking more inputs
> does not actually result in more "uniqueness", at least for
> random number generation.
> Does anyone know how that works for hashing?
This is well explained in RFC 1750, Randomness Recommendations for Security, D.
Eastlake, S
Margaret,
It is actually my (weak) understanding that taking more inputs
does not actually result in more "uniqueness", at least for
random number generation.
Does anyone know how that works for hashing?
AFAIK, the bigest problem with random number generation is
non-random seed data. Adding m
Pekka,
> Pekka Nikander wrote:
> "Good enough" ones are easy to generate without too
> much human intervention, for example, without any
> connection to the registry. OTOH, they are not
> necessarily unique, and therefore not "good enough"
> for some people. IMHO, both types are needed.
Agreed.
Michel Py wrote:
There is room for both models at the same, and "good enough" is not
going to be good enough for everybody.
Margaret Wasserman wrote:
I would need to see a very compelling case for why two types
of globally-unique/provider-independent addressing are needed
before I would like to
Michel,
In any case, a modest suggestion: Let's separate
the GUPI prefix generation and registration processes,
and make them sequential.
I have another suggestion: Let's split the FEC0::/10 space in two parts:
One for the unregistered "good-enough" and one for the registered truly
unique. By
Hi Dan,
> |There could be another model, where the end-site would request the block
> |to one of their ISPs and the ISP access the IANA or RIR web site on
> |behalf of the customer.
>
> Let's not encourage ISPs to be in the address allocation business any more
> than necessary. :) Besides, what
On Sun, 2002-11-24 at 04:12, Michel Py wrote:
> This sounds like a terrible idea. Site-locals are not for everyone, and
> we certainly don't want to encourage their use by making it plug and
> play.
Agreed, for site-locals alone it is a terrible idea.
Philosophically I'm with you, although I tend
On Sat, 23 Nov 2002, Margaret Wasserman wrote:
> >FEC0::/10 has about 38 usable bits there. That's enough for "unique
> >enough". No need for even that. Let's assume /16 - /40 -- 24 bits would
> >be enough too. By birthday paradox, even in that case, collisions should
> >only be probable if you
I don't think it necessarily requires registration - usually a
traceroute toward the leaked route will give a good indication where it
is coming from.
This assumes that the only type of leaking that you are concerned
about is route leaking.
It would also be good, in many cases, to be able to
20 matches
Mail list logo
