2013-02-07 19:35, Roger Jørgensen rog...@gmail.com :
sorry, but we can't all be nice all the time, see more inline,
On Thu, Feb 7, 2013 at 7:21 PM, Rémi Després despres.r...@laposte.net wrote:
snip
(b) The benefit comes from the following, i.e. one of the 4rd objectives:
- We want to
Erik,
To me the FreeBSD is the obviously correct behavior. They are supposed
to be interface-local, hence not arriving from somewhere else. There
could be security implications with applications using this to pass
packets between them and not expecting that a forged packet could be
arriving
On Fri, Feb 08, 2013 at 10:03:51AM +0100, Ole Troan wrote:
you don't think the text in RFC4007 is clear enough?
It doesn't explicitly say that packets sent to ff01::/16
must be dropped if originated from another host. Only that it
is useful only for loopback delivery of multicasts within
a
... You just ASSUME something I think we all understand is not
possible to guaranty. There will be collision, deal with it.
Let me make the point again.
It is a fact (not an assumption) that RFC4291-conforming IIDs either have
u=0, in which case other bits may have any values, or, if
2013-02-08 à 10:51, sth...@nethelp.no :
... You just ASSUME something I think we all understand is not
possible to guaranty. There will be collision, deal with it.
Let me make the point again.
It is a fact (not an assumption) that RFC4291-conforming IIDs either have
u=0, in which case
Hi, Fred,
Sorry for the delay in providing comments (as promised). Here they are:
Section 2:
The current Internet cell size is effectively 1500 bytes, i.e., the
minimum MTU configured by the vast majority of links in the Internet.
IPv6 constrains this even further by specifying a
Folks,
As requested by Ole, here's the summary of changes from version -01 (the
one WGLC'ed) to version -03 (the current one):
* Incorporated text noting that the algorithm should handle reserved
IIDs, and how to handle the case in which such an IID is generated.
* Added more details regarding
However, there is nothing which enforces RFC4291-conforming IIDs for
(for instance) statically configured IPv6-addresses.
So in what way do
well defined u/g values for RFC4291-conforming IIDs help you?
1.
Users that manually configure their IPv6 addresses should be
knowledgeable about what
Greetings,
A new IPv6 over foo I-D has been posted at
http://tools.ietf.org/html/draft-brandt-6man-lowpanz-00.
This I-D specifies an IPv6 encapsulation for ITU-T G.9959 radio networks that
I'd describe as an alternative to IEEE 802.15.4 in home and building
automation.
The I-D provides some
On Friday 8th Feb 2013, Karl Auer wrote, in part:
Do you mean that the ESP header must be the first item in the
fragmentable part of the first fragment? Or that the ESP header
must be (at least partly) in the non-fragmentable part of the
first fragment?
I can't lex your question, so please
On 08/02/2013 13:38, RJ Atkinson wrote:
On Friday 8th Feb 2013, Karl Auer wrote, in part:
...
In turn, your confusion puzzles me.
Me too. TCP is also an encapsulating header; its contents just don't happen
to be encrypted. The draft's definition of Entire IPv6 header chain uses
TCP as an
On 08 Feb 2013, at 09:36 , Brian E Carpenter wrote:
Me too. TCP is also an encapsulating header; its contents
just don't happen to be encrypted. The draft's definition
of Entire IPv6 header chain uses TCP as an example:
Note: If there is an upper layer header, only the header (and
Le 2013-02-08 à 11:59, Havard Eidnes h...@uninett.no a écrit :
However, there is nothing which enforces RFC4291-conforming IIDs for
(for instance) statically configured IPv6-addresses.
So in what way do
well defined u/g values for RFC4291-conforming IIDs help you?
1.
Users that manually
Le 2013-02-08 à 12:08, Roland Bless roland.bl...@kit.edu a écrit :
Hi,
On 08.02.2013 09:31, Rémi Després wrote:
Hosts of an IPv6 customer site can have IPv6 addresses assigned, with
SLAAC or DHCPv6, BEFORE 4rd is activated.
If these addresses become in conflict with the CE 4rd
Hi,
I experience Address Resolution problem while using Linux 2.6.27.
A and B use global IPv6 addresses.
* 2009::6:173 - 'A' global address (the capture monitors its port)
* 2009::6:172 - 'B' global address
Both A and B are about 8 seconds in the reachable states (STALE /
Hi Fernando,
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Fernando Gont
Sent: Friday, February 08, 2013 2:16 AM
To: fltemp...@acm.org
Cc: ipv6@ietf.org
Subject: Feedback on draft-generic-6man-tunfrag-07
Hi, Fred,
Sorry for the
On Fri, 2013-02-08 at 08:38 -0500, RJ Atkinson wrote:
On Friday 8th Feb 2013, Karl Auer wrote, in part:
Do you mean that the ESP header must be the first item in the
fragmentable part of the first fragment? Or that the ESP header
must be (at least partly) in the non-fragmentable part of the
On Fri, 8 Feb 2013, Mudric, Dusan (Dusan) wrote:
Q: Is this a known problem? If yes, is there a patch for it?
I believe this is not the correct list for asking these questions. The
linux netdev is probably more suitable place to ask linux specific
questions.
Then again, I doubt you'll get
On 02/08/2013 03:16 PM, Templin, Fred L wrote:
Unfortunately, link adaptation can present a significant burden to
the link endpoints, i.e., especially when the link supports high data
rates and/or is located nearer the middle of the network instead of
nearer the edge. An
On 02/08/2013 12:17 PM, RJ Atkinson wrote:
**How many bytes of the transport header+payload are included in this
definition?**
For ESP, is it 8 bytes (SPI + Sequence Number)?
I think that would be OK. Certainly it MUST NOT be
more than those 8 bytes, because beyond there lies
encrypted
Hi, Dusan,
On 02/08/2013 03:12 PM, Mudric, Dusan (Dusan) wrote:
· During the time 173 can’t reach 172 there are ICMPv6 NS
messages from 173 and NA to 173. 173 ndisc_recv_na() is not called.
NAs are silently discarded somewhere. At the same time, 173 neighbor
cache entry does not
Hi Fernando,
-Original Message-
From: Fernando Gont [mailto:fg...@si6networks.com]
Sent: Friday, February 08, 2013 1:20 PM
To: Templin, Fred L
Cc: ipv6@ietf.org
Subject: Re: Feedback on draft-generic-6man-tunfrag-07
On 02/08/2013 03:16 PM, Templin, Fred L wrote:
Hi Remi,
A few months ago, I raised some concerns around RFC 6164 which permitted use of
/127 prefixes on inter-router p2p links.
You mention use of u/g bits and reserved IID range for 4rd
Don't you think that network operators who have by now implemented 6164 based
addressing in their networks
On 08/02/2013 21:42, Fernando Gont wrote:
On 02/08/2013 12:17 PM, RJ Atkinson wrote:
**How many bytes of the transport header+payload are included in this
definition?**
For ESP, is it 8 bytes (SPI + Sequence Number)?
I think that would be OK. Certainly it MUST NOT be
more than those 8
24 matches
Mail list logo
