[Cross-posting to hipsec since this analysis seems to
be important for HIP, too. CC:s appropriately, please.]
The recent discussion on the ML has led me to believe
that we have a fairly poor understanding on what we
are speaking about. (Dave Crocker has also privately
pointed this out, thereby m
Erik,
> Erik Nordmark wrote:
> I don't think an identifier is necessary in every packet.
> But I do think it makes sense to have a shim layer above IP which
> uses locators in the packets below (for IP's routing) and presents
> fixed length identifiers in the pseudo-headers passed to/from the
> up
Pekka,
> Pekka Nikander wrote:
> So, the question is about either using identifiers that
> sometimes are also locators vs. using identifiers that
> never are locators. If we could use identifiers that
> are always also locators, we would not need this discussion
> at all; the current IP addresse
Pekka,
> Pekka Nikander wrote:
> I don't remember any more what might have been the reasons
> for having more bits. Could you please remind me?
Darn, I was hoping _you_ could refresh my memory.
I think that there were two things: crypto and hints about the locators.
If my recollection is correc
> MT> In the case of mobility and multihoming, you might want a stable
> MT> identifier on a per-packet basis which is independent of the routing
> MT> layer.
>
> A number of folks clearly have in mind using the identifier in every packet.
> My question is: Why is this needed? What requires put
James,
>> The "security" associated with a current, bare-bones mono-address
>> host-to-host IP exchange is pretty darn small. I'd summarize it as simply
>> being the assertion that a datagram probably did come from the IP address
>> in the relevant field of the datagram.
JK> Well, I think an argu
Hi Pekka,
On maandag, sep 15, 2003, at 13:26 Europe/Amsterdam, Pekka Nikander
wrote:
It looks like that we are speaking about different issues.
I was trying to analyse the long term consequences of
various practises. I fully agree that we most probably
need to have identifiers that are also lo
Dave,
I've been trying to stay out of this discussion, but there's one point in
your email that I think needs comment, and since I haven't seen anybody else
make it, I guess it's up to me.
> Are we, perhaps, trying to add other functionality to the IP service,
beyond
> simply providing the curren
Margaret, Thomas,
The chairs of the IPv6 working group, on behalf of the working group,
request that the following document be published as a Proposed Standard:
Title : Management Information Base for the Internet Protocol
(IP)
Author(s) :
Randall R. Stewart (home) wrote:
Now as to the applicability in SCTP and ADD-IP...
There is a difference with mobile-ip in that an SCTP association is already
established. Each node CN and MN have "connection" state. There has
been a 64bit random value exchanged and the "ADD-IP" which is equivial
Pekka Nikander wrote:
vinton g. cerf wrote:
We would also want to look very carefully at the potential spoofing
opportunity that rebinding would likely introduce.
Randall R. Stewart (home) wrote:
This is one of the reasons the authors of ADD-IP have NOT pushed to
get it done.. some more
work
vinton g. cerf wrote:
We would also want to look very carefully at the potential spoofing
opportunity that rebinding would likely introduce.
Randall R. Stewart (home) wrote:
This is one of the reasons the authors of ADD-IP have NOT pushed to get
it done.. some more
work needs to be done on this a
Hi Pekka,
[...]
> The reason why some people seem to dislike non-locator
> identifiers is that they may be hard to be used for referral.
IMHO an important benefit of having locator identifier is that it just works
without additional stuff for a big number of hosts. I mean, regular non
mobile non
Hi Itojun,
Could you let us know where is documented the IPv4 compatible deprecation?
I believe that some future confusions could be prevented regarding which
address continue to be used if a new documentation has been published.
robson
-Original Message-
From: [EMAIL PROTECTED] [mailto
On Mon, Sep 15, 2003 at 09:22:59PM +0900, Jun-ichiro itojun Hagino wrote:
> > Please could someone explain how IPv4 compatible IPv6 address is
> > used?
>
> its use is deprecated.
Ah, misread compatible for mapped. Don't see compatible mentioned very often
now as Itojun says :)
Tim
-
Hi,
On Mon, 15 Sep 2003, Brian E Carpenter wrote:
> I believe RFC 2993 actually covers all the issues (including the one
> of VPNs between RFC 1918 sites, especially in section 7.6).
Thanks for the pointer. Yes, RFC 2993 seems to cover many aspects which
seem surprisingly familiar ;-), but I'm
> Given this background, I don't see any immediate drawbacks
> from the following approach to referral. When a host want
> to send an end-point identifier to another host, it always
> includes either a currently known working address for the
> identifier, a name (e.g. DNS name) that can be easily
> Please could someone explain how IPv4 compatible IPv6 address is
> used?
its use is deprecated.
itojun
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/list
Iljitsch,
It looks like that we are speaking about different issues.
I was trying to analyse the long term consequences of
various practises. I fully agree that we most probably
need to have identifiers that are also locators for quite
some time. (That's why I think Hinden/Haberman addresses
ar
On maandag, sep 15, 2003, at 11:54 Europe/Amsterdam, Pekka Nikander
wrote:
So, the question is about either using identifiers that
sometimes are also locators vs. using identifiers that
never are locators.
Now, if we use identifiers that are never locators, the
situation seems to be semantically
Michel,
Pekka Nikander wrote:
I do understand your point about the benefits of an
identifier also being a locator, but I also believe
that the benefits of clean separation will more than
pay the drawbacks in the long run. (I don't have any
analysis or data to support this belief, though.)
Michel P
Michel,
[Sorry for the late reply. Cross-posted to HIPSEC since
there is the specific question about HIT length. Please
adjust your reply list.]
Iljitsch van Beijnum wrote:
Are you saying that we should make a clear distinction between
identifiers and locators, and not have any values that are
Dave Crocker wrote:
...
>
> BEC> If you are looking for stable identifiers for "stacks" (in the
> BEC> terminolgy of draft-irtf-nsrg-report-09.txt) it seems unlikely
> BEC> that an FQDN is a safe answer.
>
> It is probably worth noting that the NSRG report uses domain names to label
> the differe
Pekka,
I believe RFC 2993 actually covers all the issues (including the one
of VPNs between RFC 1918 sites, especially in section 7.6).
Given how difficult it was to get that RFC published, I wonder if it
is worth the effort of writing what would efefctively be the same
document, but with an emp
Pekka,
Unfortunately, if someone had this they probably would have used it to
explain why local addresses should be removed from IPv6.
Since no one was able to produce it then, I doubt it exists now.
But I would love to see it if there is one, as this would help close the
issue, because it would
On maandag, sep 15, 2003, at 07:33 Europe/Amsterdam, Pekka Savola wrote:
I'm wondering whether there exist any educational material why
RFC1918-like addressing is really *NOT* a good idea (or even, list and
evaluate the tradeoffs), and how to get around it. ("If one can state
clearly arguments why
RFC 2893.
> Please could someone explain how IPv4 compatible IPv6 address is
> used?
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
---
27 matches
Mail list logo
