= Someone, somewhere (perhaps the IAB) needs to write an
architectural document to tell various industries to _stop_ doing
that. The IID is a set of bits that have no meaning, please stop
trying to create it in an industry/link layer technology-specific
manner. It does do anything and it's
On Mon, Feb 18, 2013 at 9:36 PM, Scott Brim s...@internet2.edu wrote:
I have the usual concerns about privacy. I have no problem with someone
knowing the endpoint that is communicating is associated with a vehicle
(or that I, a human, am communicating from a vehicle). However, if
someone
But, unless there is an actual problem with the design the IETF has
adopted, I am reluctant to change it just because.
i know. ipv6 is perfect, widely deployed, and unchangable. i hope we
all like v4 nat.
I can find many reasons to remove the magic from the U and G bits. I
personally ran
The obvious conclusion to this argument is that a *lot* of DHCP
functionality will be duplicated in ND. Is this where we want to go?
I'm coming from the DHCP side of the argument. In my world DHCP is
needed because it gives you a single place to handle dynamic address
allocation, *and* it ties
= The router doesn't need to know the host's route table, it knows
which
address it included in its RAs, which is what the host records.
I'm not sure why you think that there is no way the router can
construct
that message reliably. If it uses the same address it uses for its
RAs,
it
I've come across what looks like a bug in the ICMPv6 spec.
= You mean in 4861 or ICMPv6?
Specifically, RFC 4861 says that A host MUST silently discard any
received Redirect message that does not satisfy all of the following
validity checks amongst which is The IP source address of the Redirect
= The router doesn't need to know the host's route table, it knows which
address it included in its RAs, which is what the host records.
I'm not sure why you think that there is no way the router can construct
that message reliably. If it uses the same address it uses for its RAs,
it
can
Hi
Should a host reply to a neighbour discovery message if the source
address is a link-local address?
= Yes.
Hesham
I read RFC 4861 and did not find
anything suggesting that a link-local source address is not allowed.
Matthew
Just a quick comment below
There was a bunch of stuff about the M and O flags in RFC2462, almost
all of which was removed in RFC4862. In RFC2462, the word
should (*not* capitalised) was used, along with phrases like is to
be.
= should does not need to be capitalised to indicate that it's a
On May 9, 2011, at 5:37 PM, Fred Baker wrote:
On May 9, 2011, at 5:15 PM, Thomas Narten wrote:
When are we going to start counting cell phones, tablets and other
electronic devices?
When they start implementing IPv6 at all...
iOS and Symbian appear to do IPv6 pretty well. I think
I don't think go away is the right answer. I think your model has
flaws is closer.
The key message is that if they apply for patents in it (BMW) they
clearly see dollar-signs and its very hard to trump money.
= I don't think it's as organised as you might think. People apply for
patents all
On 22/09/10 3:56 PM, Mikael Abrahamsson swm...@swm.pp.se wrote:
On Wed, 22 Sep 2010, Hesham Soliman wrote:
= But you're saying that as an operator need, when in fact your rationale
is to reduce vendor code. Is any vendor complaining about this? Is this an
Well, yes, I want to reduce
On 21/09/10 3:41 PM, Mikael Abrahamsson swm...@swm.pp.se wrote:
On Tue, 21 Sep 2010, Brian E Carpenter wrote:
I think the technical issue there is that ND and RA were designed as a
package, and you certainly can't run without ND.
Well, the DHCPv6 standard can be changed to hand out
On 21/09/10 9:36 PM, Mikael Abrahamsson swm...@swm.pp.se wrote:
On Tue, 21 Sep 2010, Hesham Soliman wrote:
= Before getting into the merits of your idea, why do you want to do
that? A pointer to some requirements or an email with the foreseen
benefits would be useful.
I mentioned
I agree. You want this minor change to be done in all host stacks. At this
stage IMO it's way too late. I'm dealing with some vendors now and I don't
hear any complaints about supporting ND in their routers/switches, that's
anecdotal but we didn't see this on the mailing list either. I can't see
On 22/09/10 3:21 PM, Mikael Abrahamsson swm...@swm.pp.se wrote:
On Wed, 22 Sep 2010, Hesham Soliman wrote:
I agree. You want this minor change to be done in all host stacks. At this
stage IMO it's way too late. I'm dealing with some vendors now and I don't
hear any complaints about
On 22/09/10 3:30 PM, Mikael Abrahamsson swm...@swm.pp.se wrote:
On Wed, 22 Sep 2010, Hesham Soliman wrote:
= I understand that, but I think that to make this work you will need
to do that with zero modifications to the host's IPv6 stack. I don't
think you can count on people modifying
They are already optional. Those people who don't want to use ND/RAs are
likely to already have knobs to switch them off (Cisco switch off RAs by
default on some interface types already) and will have static
configuration mechanisms.
.. and what (I, and others) are saying is that we would
On 22/09/10 3:39 PM, Mikael Abrahamsson swm...@swm.pp.se wrote:
On Wed, 22 Sep 2010, Hesham Soliman wrote:
On 22/09/10 3:30 PM, Mikael Abrahamsson swm...@swm.pp.se wrote:
On Wed, 22 Sep 2010, Hesham Soliman wrote:
= I understand that, but I think that to make this work you will need
Fred,
What I would rather have said was that mechanisms such as
SEcure Neighbor Discovery (SEND) may be helpful in private
addressing domains where spoofing is possible. Let me know
if this makes sense.
Except for the practical problems involved in deploying SEND.
Can it be said that
On 5/08/09 8:24 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote:
Hi Joel,
On 2009-08-05 03:08, Joel M. Halpern wrote:
It has become clear with the passage of time that the description of the
flow label in the original IPv6 specs served only to convince everyone
not to use that
On 30/07/09 2:54 PM, Christian Huitema huit...@microsoft.com wrote:
BEHAVE's issue is to decide whether dropping them is
an acceptable recommendation for v4-v6 translators.
So there are really several cases
1) No fragmentation:
1a) Checksum correct, = No issue, just translate.
On 28/07/09 5:29 PM, Francis Dupont francis.dup...@fdupont.fr wrote:
In your previous mail you wrote:
Thoughts?
= I am strongly against changing all IPv6 implementations.
IMHO the simplest solution is to drop UDP packets with zero checksums
(as far as I know all IPv4
All
I strongly recommend that people read section 1 of RFC 2765. Here is some of
the relevant text:
Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e.
the UDP checksum field is zero) are not of significant use over
wide-areas in the Internet and will not be translated by
On 28/07/09 6:49 PM, Christopher Morrow morrowc.li...@gmail.com wrote:
On Tue, Jul 28, 2009 at 4:23 AM, Hesham Solimanhes...@elevatemobile.com
wrote:
All
I strongly recommend that people read section 1 of RFC 2765. Here is some of
the relevant text:
Fragmented IPv4 UDP packets that
On 25/07/09 12:07 AM, Rémi Denis-Courmont r...@remlab.net wrote:
On Fri, 24 Jul 2009 23:40:14 +1000, Hesham Soliman
hes...@elevatemobile.com
wrote:
SeND is theoretically not easy to deploy - you need to provision
cryptography material on all nodes.
= Why? You only need to provision
On 24/07/09 11:52 PM, Arnaud Ebalard a...@natisbad.org wrote:
Hi Hesham,
Hesham Soliman hes...@elevatemobile.com writes:
SeND is theoretically not easy to deploy - you need to provision
cryptography material on all nodes.
= Why? You only need to provision routers if you want
Looks good in general, but I'm not sure if the host can always determine the
nature of the link or the level of security available on that link. It can
probably infer (sometimes inaccurately) but it's not laways possible to
know.
I agree with the SHOULDs and the intention of the MAY, I just
-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of ext
Hesham Soliman
Sent: Wednesday, July 22, 2009 11:46 PM
To: Laganier, Julien; Thomas Narten; ipv6@ietf.org
Subject: Re: Node Requirements: Issue 13 - CGA/SeND support
Looks good in general, but I'm not sure
.
--julien
Hesham Soliman hes...@elevatemobile.com wrote:
Looks good in general, but I'm not sure if the host can always
determine the nature of the link or the level of security available
on that link. It can probably infer (sometimes inaccurately) but
it's not always possible to know.
I
As a general node requirement, SHOULD is the right level, not MUST.
= +1
Apart from the technical discussion of whether IPsec is actually useful for
applications etc. The way KEYWORDS are defined, a MUST makes little
sense because IPv6 will not break without IPsec.
The argument for
I am getting back to replying to some emails that were sent
in response
to our drafts. I did explain what an aggregation router was
when we met
face to face at IETF. If you had read our drafts, that was one way to
learn about properties of an aggregation router wrt to ND. It was
To give a little more detail to that implementation bug, it
seems the
host implementation inferred an on-link prefix from an address
assigned through DHCPv6. We believe the implementation
carried over
IPv4 behavior, in which it's common to pass on-link prefix
information
I know how to configure off-link on a router. I was asking the
community. At least the people we pinged in the past in the community
didn't know how or didn't reply including Hesham.
How off-link is configured is described in section 2.1, and
2.2.1 of our
draft. Your explanation
Hello again,
This is a follow up on the comments we discussed earlier. Ralph, please let
me know if you're ok with my suggestions below. The document is waiting on
your response! The rest of your comments are all in the document.
I think this is general advice to people thinking about
.
I intend to submit the draft tomorrow.
Hesham
- Ralph
On 1/5/07 3:40 AM, Hesham Soliman [EMAIL PROTECTED] wrote:
Hello again,
This is a follow up on the comments we discussed earlier.
Ralph, please let
me know if you're ok with my suggestions below. The
document
Fred,
Ok, thanks, I've made the change.
Hesham
-Original Message-
From: Templin, Fred L [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 06, 2007 5:00 AM
To: Hesham Soliman; Ralph Droms; Thomas Narten
Cc: ipv6@ietf.org; Brian Haberman; Erik Nordmark; Bob
Hinden
= I agree with this. Pekka himself mentioned that this is
not a compliant behviour according to 2461. A contant is a
*contant*, which means it doesn't change :)
= I obviously meant constant :)
Hesham
Variables are also given max and min values, which by the
english meaning of
Hi Hesham, please allow me to interfere, splitting the thread to a
different topic. I do not give an oppinion in this message about the
original message's comments.
Do you or co-authors think it may be useful to add several
clarifications in the 2461bis with respect to how ND would
Hi Ralph and Thomas,
Just updating the doc for final (hopefully!) submission.
A couple of conclusions from the discussion below are unlear to me. So your
responses will help me clarify the new document.
Substantive/editorial: I'm confused by the statements in
section 3.2,
= Yes to both questions I think. If we didn't point to
MLDv1 then the
change woulod not be backward compatible. I.e. using MLDv2
only would break
old implementations. As for the second question, I agree
that it makes MLDv2
normative but I was hoping the or would get us out of
to clarify issues
that have come up since the publication of RFC 2461. Hesham
Soliman was the sole editor for this revision of the document.
Special thanks should be given to [insert names here - I note that
most of the listed names are the same as those in 2461. Anyway, can
-Original Message-
From: Soliman, Hesham [mailto:[EMAIL PROTECTED]
Sent: Wed 11/22/2006 4:51 AM
To: Scott W Brim; General Area Review Team; Jari Arkko; Mark Townsley
(townsley); Bob Hinden; Brian Haberman; Thomas Narten; Erik Nordmark;
William Allen Simpson; ipv6@ietf.org;
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
44 matches
Mail list logo
