Marcelo is working on organizing a SEND interop test sometime next year,
probably in Madrid. We are trying to identify implementors so that we can
find out whether there would be enough interest to hold the test. I have
private email from a couple people who told me they have implementations
is the paging agent.
On Tue, 2006-09-05 at 12:54 -0700, James Kempf wrote:
Erik,
Couple points.
Most cellular networks don't have more than one active last hop router,
so
the issue of multiple routers doesn't apply.
Regarding the number of packets, the question is over what period
There is an assumption here that the L2 paging system is run off the AR.
This is not necesarily the case. It won't be for Wimax, for example.
jak
- Original Message -
From: Pars MUTAF [EMAIL PROTECTED]
To: James Kempf [EMAIL PROTECTED]
Cc: Erik Nordmark [EMAIL PROTECTED
line is, other SDOs get to say how it works, not the IETF.
jak
- Original Message -
From: Pars MUTAF [EMAIL PROTECTED]
To: James Kempf [EMAIL PROTECTED]
Cc: Erik Nordmark [EMAIL PROTECTED]; ipv6@ietf.org
Sent: Wednesday, September 20, 2006 12:49 PM
Subject: Re: Proposal
- Original Message -
From: Manfredi, Albert E [EMAIL PROTECTED]
To: James Kempf [EMAIL PROTECTED]
Cc: ipv6@ietf.org
Sent: Wednesday, September 20, 2006 1:17 PM
Subject: RE: Proposal to change aspects of Neighbor Discovery
I think Pars' point is not restricted to L2 mechanisms, though
It supports both Linux and BSD. You can download it here:
http://www.docomolabs-usa.com/lab_opensource.html
jak
- Original Message -
From: John Spence [EMAIL PROTECTED]
To: ipv6@ietf.org
Sent: Sunday, September 17, 2006 4:15 PM
Subject: CGA/SeND implementation - I believe
Let me be more specific. It will not convince 3GPP and Wimax Forum that
periodic, multicast RAs should be deployed in their network. 3GPP2 already
does not use RA beacons for Mobile IPv4.
jak
- Original Message -
From: Soliman, Hesham [EMAIL PROTECTED]
To: James Kempf
level for
things like power control, and it is more efficient to let that take care of
these kinds of functions.
jak
- Original Message -
From: Pars Mutaf [EMAIL PROTECTED]
To: Thomas Narten [EMAIL PROTECTED]
Cc: James Kempf [EMAIL PROTECTED]; Erik Nordmark
[EMAIL PROTECTED
filter is fine.
jak
- Original Message -
From: Erik Nordmark [EMAIL PROTECTED]
To: James Kempf [EMAIL PROTECTED]
Cc: Basavaraj Patil [EMAIL PROTECTED]; ipv6@ietf.org; ext
Pars MUTAF [EMAIL PROTECTED]
Sent: Thursday, August 31, 2006 5:17 PM
Subject: Re: Proposal to change
Erik,
I think the proposal was not to keep the router information until it was
explicitly invalidated but rather that the host could individually solicit
prior to the expiration of the lifetime. The router information state is
still soft state, its just that the renewal is different. 2641
anybody say what real implemetations do with this?
- Original Message -
From: Templin, Fred L [EMAIL PROTECTED]
To: Julien Laganier [EMAIL PROTECTED]; James Kempf
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; INT Area [EMAIL PROTECTED]; IETF IPv6 Mailing
List ipv6@ietf.org
Sent: Thursday, August
No, but I think it would be worthwhile to find out what real implemenations
do. Unless an IETF standard has specific RFC 2119 languge in it, your milage
can vary.
jak
- Original Message -
From: Templin, Fred L [EMAIL PROTECTED]
To: James Kempf [EMAIL PROTECTED]; Julien
Like I said, unless the RFC says MUST, your milage may vary. People often
have all kinds of reasons to ignore recommendations that aren't required.
jak
- Original Message -
From: Templin, Fred L [EMAIL PROTECTED]
To: James Kempf [EMAIL PROTECTED]; Julien Laganier
[EMAIL
not go beyond this point
or YOU WILL DIE.
In the first case, some adverturesome person might decide the risk is worth
it. In the second, only a fool would try it.
jak
- Original Message -
From: Templin, Fred L [EMAIL PROTECTED]
To: James Kempf [EMAIL PROTECTED]; Julien
First off, a prefix advertised in an RA is not assigned to an end
node, it
is assigned to a link. A prefix can only rightly be considered to be
assigned to a node when it is delegated via DHCP, this allows the node
to
then assign the prefix to links downstream, or delegate further if the
Fred,
jak The last paragraph of Section 2.1 in 4291 says:
Currently, IPv6 continues the IPv4 model in that a subnet prefix is
associated with one link. Multiple subnet prefixes may be assigned
to the same link.
jak So whether the term associated or assigned is used is not
any of my
suggestions, so there's little point in our continuing the discussion.
jak
- Original Message -
From: Templin, Fred L [EMAIL PROTECTED]
To: James Kempf [EMAIL PROTECTED]; INT Area
[EMAIL PROTECTED]; [EMAIL PROTECTED]; IETF IPv6 Mailing List
ipv6@ietf.org
Sent
Yes, I think there needs to be a distinction made between:
a) prefix delegation, in which the upstream router gives the prefix to the
downstream node in the expectation that the downstream node will be routing
to nodes downstream from it,
b) prefix assignment, in which the upstream router
RFC 3041 specifies privacy for autoconfiguration only. If DHCP is in use,
the node can simply request multiple addresses from DHCP, and to the extent
that the DHCP server allows a node to have more than one address, different
addresses can be used for different transactions.
jak
I don't think the issue is so much the lifetime of the RA as the need to
wake up a dormant mode host when an unsolcited RA is multicast. I assume a
dormant mode host coming out of dormant mode will have some amount of work
to do to get its IP traffic channel in shape. This will naturally
Francis,
Are you also proposing that cellular-type protocols, such as 802.16 should
disable their power saving narrowband signaling channels and be forced to
work like 802.11?
jak
- Original Message -
From: Francis Dupont [EMAIL PROTECTED]
To: Syam Madanapalli [EMAIL
DoCoMo Labs USA has finally released its OpenSource implementation of RFC
3971, 3972, and 3779 for SEcure Neighbor Discovery (SEND). The code and
documentation can be downloaded at:
http://www.docomolabs-usa.com/lab_opensource.html
Please don't send email directly to me about the
Yes, I've been of the opinion for some time that the IP over ATM and other
nonbroadcast links work might be relevent. The arugment against this has
been that 802.16 nodes don't have direct contact with their neighbors
because they have to go through the base station, but I am not sure why this
The other alternative to hierarchy for scalability is separate addressing
domains. But let's not go there.
jak
- Original Message -
From: Erik Nordmark [EMAIL PROTECTED]
To: Pekka Nikander [EMAIL PROTECTED]
Cc: Internet Area [EMAIL PROTECTED]; ipv6@ietf.org
Sent: Thursday,
I agree. I think any allocation should be considered experimental,
particularly since there is a possibility that the identifiers might become
longer in the future. However, it is also possible that 128 bit identifiers
might become standard practice. At this point, we don't really know.
Greg,
I'm glad you've been following up on this, but there is a key point missing
I think. US Patent Law is based on litigation, not regulation. The US Patent
Office typically only conducts a cursory examination of prior art, and
unless the patent application is contested before approval, the
Title: Message
Yes, if the host has the certificate path for the default
router, it need not send CPS.
jak
- Original Message -
From:
Hongyan Ma
To: James Kempf ; ipv6@ietf.org
Sent: Wednesday, September 21, 2005 7:45
PM
Subject: RE: About CPS message
Check RFC 3111. Unfortunately, SLP hasn't been very widely
used, though there are a few very specific cases where it has been (iSCSI
discovery, SIP proxy discovery, among others).
I would not be in favor of extending the RA for this purpose
in any case. LW DHCP is a better choice and has
A friend sent me this reference. I have not looked into this in detail, so
this may be a well-known problem:
http://kerneltrap.org/node/5382
Any comments?
jak
IETF IPv6 working group mailing list
ipv6@ietf.org
Likewise, an Optimistic node can still inject IP packets into the
Internet that will in effect be spoofed packets appearing to come
from the legitimate node. In some cases, those packets may lead to
errors or other operational problems, though one would expect that
upper
Applying IPsec doesn't help solve the authorization issue of who
should be allowed to receive packets sent to a particular anycast
address.
Can you tell me any address or type of address for which that is an
objective either of internet routing or addressing?
It is possible to
I agree.
jak
- Original Message -
From: Mark Andrews [EMAIL PROTECTED]
To: Fred Baker [EMAIL PROTECTED]
Cc: Brian Haberman [EMAIL PROTECTED]; James Kempf
[EMAIL PROTECTED]; Margaret Wasserman [EMAIL PROTECTED];
Bob Hinden [EMAIL PROTECTED]; IPv6 WG ipv6@ietf.org; Joe Abley
Sounds eminently logical. I think it makes sense to remove the restriction
in draft-ietf-ipv6-addr-arch but spend some time discussing the finer points
in more depth rather than try to craft some text on the fly to substitute.
GROW might be the right place to do so (I see there's a draft about
SEND secures the mapping between an IPv6 address and a MAC address, but
it does nothing to guarantee that the L2 topology actually delivers the
packets to the intended destination. When we expand all that energy
signing neighbor discovery packets, have we really improved security?
Here's a
http://www.speakeasy.net/netshare/
jak
- Original Message -
From: Bob Hinden [EMAIL PROTECTED]
To: James Kempf [EMAIL PROTECTED]
Cc: Erik Nordmark [EMAIL PROTECTED]; Brian Haberman
[EMAIL PROTECTED]; Thomas Narten [EMAIL PROTECTED]; Margaret
Wasserman [EMAIL PROTECTED]; IPv6
The counterexample is that there are ISPs that have their home users
with 802.11 run public hotspots and get some compensation from the
ISP. In this case, since it is a public access 802.11, SeND would be a
good thing to use. And 802.11 is also a key scenario for proxynd.
This is the
= it should be good to get more infos because AH itself is subject
to calls for deprecation based on the facts ESP can be used in place
of it in most cases and AH is not very used...
If AH is not heavily used today (or used at all), then why is there a
backward compatibility issue with
Hmmm ... since we're dealing with probabilities here, it would
almost make sense to say on a media with packet loss probability
P_loss, send it N times where P_loss ^ N = P_acceptable. But
then we're stuck trying to make a decision about P_acceptable,
and in any case P_loss is unlikely to be
Looks fine to me.
jak
- Original Message -
From: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, July 20, 2004 12:54 AM
Subject: [psg.com #256] Eliminate random delay in RS transmission
Issue:
---
This issue was raised in order to speed movement detection
for
Why not send this email message to the IAB and ask?
jak
- Original Message -
From: JINMEI Tatuya / [EMAIL PROTECTED]@C#:H (B [EMAIL PROTECTED])
To: [EMAIL PROTECTED]
Sent: Monday, July 12, 2004 5:15 AM
Subject: [2462bis] IAB recommendation on prefix lengths
Hello,
I'd
directly on NBMA links, as perhaps 3314 and 3316 indicate, then references
to those.
jak
- Original Message -
From: Soliman Hesham [EMAIL PROTECTED]
To: James Kempf [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, June 14, 2004 8:40 PM
Subject: RE: [rfc2461bis] Security issues
Hesham,
Section 3 looks good.
On Section 11, I've got the following comments:
1) Much of what is in the Section 11.1 seems a summary of RFC 3756. On the
one hand, I suppose it is helpful to refresh the reader's memory, on the
other, it could shorten the spec and make for less reading. It's just
Kempf; Rajeev Koodli
Subject: Common ICMP Type Assignment for Experimental Protocols
Folks,
James Kempf, Rajeev Koodli and I have been discussing with Thomas Narten
about an ICMP Type for experimental protocols. Since Thomas suggested we
query
the IPv6 WG for feedback on this, I'm sending
Jinmei/Brian,
I agree with Brian's comments. RFC 3587 is very clear that unless the first
three bits of the address are set to 0, the interface id is required to be
64 bits. So there should be no conflict.
jak
- Original Message -
From: Brian E Carpenter [EMAIL PROTECTED]
RFC 2461 explicitly doesn't require checking the set of prefixes (but
it does say to check that the lifetimes on a prefix which both routers
advertise are consistent, etc).
*If* we are going to change this, I don't think it should be a subtle
setence in 2461bis; I think it should be a
Hi Erik,
The fact that SEND doesn't currently provide security for proxy neighbor
advertisements is an indication that 1) there isn't much perceived need
for it and/or 2) it is hard to do since authorization is a challenge.
Indeed, proxy ND was perceived to be one of two hard problems during
]
To: James Kempf [EMAIL PROTECTED]; Erik Nordmark
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, March 02, 2004 5:44 PM
Subject: Re: ndproxy and SEND
If what you are both saying is correct, then perhaps either SEND
or ND-Proxy (or both) is only half-baked. Which one
obvious approach
would be to require a third party trust root, like RD in SEND already does.
But there might be others.
jak
- Original Message -
From: Christian Huitema [EMAIL PROTECTED]
To: Fred Templin [EMAIL PROTECTED]; James Kempf
[EMAIL PROTECTED]; Erik Nordmark [EMAIL
ND proxy is the equivalent of ARP spoofing.
SEND is the antidote to ARP spoofing.
Why should we be surprised that they are not compatible?
Agreed.
Question is what we should do about it.
Having two conflicting things move forward towards the standards track
doesn't seem like the best
Putting that aside, a SEND node could well *defend* the address
fe80::A for DAD/DIID purposes, but it would never actually use it.
I think that's the issue. Should a SEND or 3041 node be required to defend
LL addresses that use suffixes configured for their global unicast addresses
even though
I agree.
jak
- Original Message -
From: JINMEI Tatuya / [EMAIL PROTECTED]@C#:H (B [EMAIL PROTECTED])
To: James Kempf [EMAIL PROTECTED]
Cc: Pekka Nikander [EMAIL PROTECTED]; Nick 'Sharkey' Moore
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, March 01
We have two nodes, a SEND node and a DIID node.
SEND node:
- (for simplicity) do not implement the DIID-style optimization
- have an (e.g.,) EUI-64 based interface identifier, I.
- configure a SEND (CGA) address P:A (where A is the identifier, A != I)
DIID node
- implement the
- Original Message -
From: James Kempf [EMAIL PROTECTED]
Cc: Nick 'Sharkey' Moore [EMAIL PROTECTED]; IPV6 WG [EMAIL PROTECTED]
Sent: Sunday, February 29, 2004 8:53 PM
Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275]
DAD text inconsistencies)
We have two
My assumption is that SEND WG will adapt to the changes that RFC2462bis
will make. So if we tweak 2462 to require configuration of a link-local
address per suffix, SEND-CGA nodes will do this. This will then prevent
(well, detect) collision as discussed above.
SEND doesn't use a common
Not quite sure I entirely understand the issue, but SEND makes no change in
the basic underlying DAD algorithm. If the address suffix generated from the
key hash changes due to a change in the prefix, then the address has to be
re-DAD-ed. If the node decides to reuse the old suffix, then the
The issue always has been where in IETF to get these collection of delays
addressed in a co-ordinated fashion. DNA was thought to be the venue, but it
has chosen not to. Given we have to address the delays piecemeal, then
OptiDAD seems like a place to start.
jak
- Original
Hi Nick,
I'd certainly be interested in hearing about this and having the IPv6 group
take it up, since the MIP group declined to take it up. I haven't read the
draft in a while, but I will try to take a look at it before the meeting. If
there is enough interest, I am not sure whether it would be
= There are two issues here: a) The current Keywords used
for IPsec. They should definitely be lighter (no SHOULDs,
MAY at best) or removed totally. b) What to use for SEND.
I have no idea about b). As for a) I think we should remove
any keywords on IPsec. I tend to think MAY is appropriate
Jim,
Are there any precedents? What has IETF done in other cases where specs have
been rev-ed?
The only case I personally know of is Mobile IPv4, in which the
author/editor name was not changed when a new revision was put out, but
perhaps there are others where different procedures were
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 current
60 matches
Mail list logo
