Would you expand a bit on this?
Jul 2014 - Advance IPv6 core specifications to Internet standard
And after the discussions in Berlin about fragmentation, the dates of
the milestones look a bit ambitious to me.
Regards,
as
On 10/11/13 2:38 PM, The IESG wrote:
> The IPv6
They aren't.
There are still many places where I come from where operators do not
support native IPv6 and people need to rely in tunnels to start trying IPv6.
Regards,
as
On 7/30/13 11:55 PM, Ronald Bonica wrote:
> Fred,
>
> I was thinking of tunnels as legacy applica
Ron, Warren
In general I tent to agree with you.
Would you have references or data to back up these two statements?
1) " Most popular TCP [RFC0793] implementations leverage this technology
and restrict their segment size so that IP fragmentation is not
required."
2) " As a result,
Agreed.
Let's ask some "running code" people some input about the practical
constraints.
/as
On 6/12/13 6:21 PM, Ray Hunter wrote:
>>> So a limit of 128 would currently probably be ok, but I personally would
>>> prefer the limit to be a bit higher just to have some extra margi
ator
> problem if you expect to be able to find an l4 header as part of your
> forwarding decision
>>
>> On Mon, Jun 10, 2013 at 8:09 AM, Arturo Servin
>> mailto:arturo.ser...@gmail.com>> wrote:
>>
>>
>> There is another conversation in v6op
There is another conversation in v6ops that mentioned that switching
ASICs do not inspect beyond 40 bytes.
-as
On 6/9/13 10:46 AM, Fernando Gont wrote:
> Ray,
>
> On 06/08/2013 01:06 PM, Ray Hunter wrote:
>> I was thinking something along the lines of:
>>
>> - The preferred len
Probably this could be a good opportunity to publish a document "do not
do this".
/as
On 5/30/13 12:17 PM, Joel M. Halpern wrote:
> While it is true that any operator can do whatever they want, this
> proposal is architecturally a bad way to achieve the kind
>>> Yes. We will do so in the future version.
>>
>>Good, and I think it's important to do so. George and Lorenzo's
>> comments are
>>good starting points for that section. The potential
>> privacy/information
>>leakage aspect is also worth capturing, should those addresses be
>> seen
>>outside
Hi
On 28/02/2013 17:51, Ole Troan wrote:
> Hi,
>
> The draft-gont-6man-predictable-fragment-id document has been discussed a few
> times.
> At the IETF84 (minutes attached below), and in the thread:
> http://www.ietf.org/mail-archive/web/ipv6/current/msg15836.html
>
> Could we get the working g
template and forgot to
> change it.
> It should be "Informational", thanks for finding this bug.
>
> B.R.
> Bing
>
>> -Original Message-
>> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
>> Arturo Servin
>> S
Dear authors,
Very interesting document and very valuable to document the current
behavior of the A, M and O flags (that have caused some headaches to
some including myself when troubleshooting IPv6).
I see that has been submitted as "Proposed Standard" but I failed to
find what y
Tim
I have mixing feelings about. I like the option, but I am not sure if I
would deploy it for my production services, perhaps only for training
labs and some other no critical infrastructure. Definitely I would not
want a rogue RA injecting the wrong prefix for my servers.
Also,
Ammar
Agree with Albert.
You are trying to add capabilities in the wrong layer.
Regards,
as
On 18/10/2012 18:50, Manfredi, Albert E wrote:
> I don't see any of this as being remotely desirable, as part of IETF
> standards.
>
> If a router is to be installed in a repressive cou
I would not support to add GPS coordinates to the IPv6 header. I think
it violates the user privacy.
As a user, I sometimes want to disclosure my position, but only to
services that I know and I want to. I wouldn't want to do it
automatically to the whole Internet.
I woul
I think it was mentioned that LLA may be dependent in the HW address.
Of course, you can configure the MAC address to be the same, but then the
argument of "no-configuration" in favour of LLA is less significant.
IMHO GUA are less susceptible to change (considering that
Support.
/as
On 13 Jun 2012, at 09:32, Ole Trøan wrote:
> All,
> This starts a 2-week consensus call on adopting
>
> Title : Security Implications of the Use of IPv6 Extension Headers
> with IPv6
> Neighbor Discovery
> Author(s) : F. Gont
> Filena
Thanks. It is clear now.
.as
On 26 Jan 2012, at 12:00, Fernando Gont wrote:
> [Subject changed so that this doesn't "mix" with the poll]
>
> Hi, Arturo,
>
> On 01/26/2012 09:59 AM, Arturo Servin wrote:
>> When you say "Namely, they try to pe
Support to adopt as WG document.
Couple of questions.
Fernando,
When you say "Namely, they try to perform IPv6
reassembly with the "atomic fragment" and any other fragments already
queued with the same set {IPv6 Source Address, IPv6 Destination
Address, Fragment
Support.
-as
On 29 Nov 2011, at 13:51, Brian Haberman wrote:
> All,
> This message starts a two week 6MAN Working Group on advancing:
>
> Title : RFC3627 to Historic status
> Author(s) : Wesley George
> Filename : draft-ietf-6man-3627-historic-00.txt
> Pages : 4
> Date
Nalini
Basically I agree with what others said.
If there were any reason for not using the flow label, I think you
should state it very clearly in the document.
Regards,
.as
On 22 Jul 2011, at 04:59, Roland Bless wrote:
> Hi Erik,
>
> On 22.07.2011 08:35, Erik Kline wrote:
>
What's the point?
If you asume unrealistic scenarios to prove your concept, then you
have a problem with your solution.
The problem is that you have a link where the attacker can have
2^64 different addresses to spoof and it can send NS request at any
rate.
-as
On Wed, Jul 13, 2011 at
IMHO I think this would be a vector for other attacks in ND.
You may solve a remote attack but you are opening the door to local
attacks, and a big ones I think.
Regards,
.as
On 12 Jul 2011, at 04:48, Philip Homburg wrote:
> So what I was thinking of, what if a router that is
Jean-Michel,
On 16 Jun 2011, at 14:13, Jean-Michel Combes wrote:
> Hi,
>
> I've read quickly these two drafts. Here are some comments/questions:
>
> o draft-gont-v6ops-ra-guard-evasion
>
> IMHO, this draft should update RFC 6105 (If so, RFC6105 reference
> should move from Informative Referenc
Fernando,
Some comments.
Minor, typos, etc.
I think you missed the reference to RFC 6105, this is the same problem
with the reference than
http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt
May be it is just me and the excess of caffeine but the
I do not see why the ITU has to start from zero. There are several (or
some at least) very good RFC and I+D documents related to IPv6 security. I
think we should recommend them to ITU, it is good that they let us know, it
would be better if they use our work as a foundation.
just my 2
Are there any guidelines, informational RFCs or best practices documents in
how organizations (ISPs, private Enterprises or government organizations)
should deploy IPv6?
Thanks in advance,
-as
IETF IPv6 working group mailing
26 matches
Mail list logo
