If I am reading this correctly, in the end this is riven by the fact
that existing boxes can easily filter on addresses (although it will
take a lot of filters), but can not apply ACLs to DSCPs or extension
headers?
It seems like what we need is a draft that clearly explains why trying
to
analysis, this seems somewhere between useless and
extremely dangerous.
Yours,
Joel M. Halpern
On 5/30/2013 3:00 AM, Sheng Jiang wrote:
...
Hi, Tim,
It is exactly what the draft document. These semantics is only meaningful
locally within the assigning provider network. It may only
18:17, Joel M. Halpern j...@joelhalpern.com a écrit :
I a not clear what aspect of the semantics of u==1 and the relationship to
EUI-64 is a dead duck. Currently, if you see something with u==1, you know it
was made from an EUI-64. Under your proposal, you would not know that.
Yous tae below
To a significant degree Randy, I agree with you in your comment about
magic bits. If I were designing IPv6 from scratch (counter-factual in
so may ways at once) I would not do it that way.
But, unless there is an actual problem with the design the IETF has
adopted, I am reluctant to change
the rule.
I have no problem with clarifying under-specified corner cases.
But why change the rule we have? Is there a problem with the current
rule that I am missing?
Yours,
Joel
On 2/2/2013 3:35 AM, Brian E Carpenter wrote:
Joel,
On 02/02/2013 00:41, Joel M. Halpern wrote:
With regard
With regard to section 3, I would ask the question in the reverse.
(which may actually be the same quewstion Fernando is asking.)
If we assume that there is value in being able to perform the diagnostic
operation described, then it seems that one needs to be able to tell
when it can be
Understood. No objection from here.
Yours,
Joel
On 1/17/2013 5:27 AM, Magnus Westerlund wrote:
On 2012-12-12 09:44, Magnus Westerlund wrote:
Thanks for the Review,
On 2012-12-12 02:02, Joel M. Halpern wrote:
This (and the companion document draft-ietf-6man-udpzero) seem ready
In reading the discussion,a nd trying to think through what I understand
to be correct, it seems that there is an unforeseen ambiguity in the way
the current documents about IPv6 IIDs are written.
I think that there are two possible meanings, ad we should decide
explicitly which one we want.
, 2012, at 3:50 PM, Joel M. Halpern wrote:
In reading the discussion,a nd trying to think through what I understand to be
correct, it seems that there is an unforeseen ambiguity in the way the current
documents about IPv6 IIDs are written.
I think that there are two possible meanings, ad we should
, Joel M. Halpern wrote:
As I understand it, the original intent with the U bit was to provide an easy
way to create IID that were highly likely to be distinct from all other IIDs
(on the link). As IEEE reserves the G bit, we marked that as special as well
when the U bit was set.
Changing
This (and the companion document draft-ietf-6man-udpzero) seem ready for
publication to me.
I do have a minor questions. It is sufficiently minor that if necessary
it may be ignored so publication can proceed.
I section 5, bullet 3 talks about tunnel protocol will not
significantly
, 2012 at 9:01 PM, Joel M. Halpern j...@joelhalpern.com wrote:
Taking things out of order:
If you are really going to lock covert channels, then you will have to block
HTTPS except to known sites (and check the hostname against the IP address,
etc...) That has not, and I hope is not, and acceptable
in some host, you are already vulnerable
on this front. In fact, a broken implementation trying to process
something is far more likely than a broken default case.
Yours,
Joel M. Halpern
On 11/19/2012 2:48 PM, Marc Lampo wrote:
Hello Brian,
(as I expected, you were the first to react - didn't
It seems to me that the proposed document is a partial fix to a marginal
problem.
Yes, I take it as given that if I followed the references I wind find
descriptions of the attacks. I do see how one could force fragmented
packets if one knew that A was talking to B at the current moment.
,
Joel M. Halpern
On 4/19/2012 11:40 AM, Bob Hinden wrote:
All,
This message starts a two week 6MAN Working Group on advancing:
Title : UDP Checksums for Tunneled Packets
Author(s) : Marshall Eubanks
P.F. Chimento
Filename
It seems likely to me that an efficient host implementation can meet the
existing requirement relative to sourcing a packet with such options
without noticeable load. So there does not seem any point in relaxing
the requirement.
And technically, if the host puts ina strict source route, and
Support.
I have read this document. It provides a useful function in practical
fashion. It is ready for publication.
Yours,
Joel M. Halpern
On 11/3/2011 11:32 AM, Bob Hinden wrote:
All,
This message starts a two week 6MAN Working Group Last Call on advancing:
Title
connections.
We probably need to allow an incoming TCP SYN to trigger an NS for the server.
Maybe with some rate control to protect against attacks.
-- Christian Huitema
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Joel M.
Halpern
Sent
jaeggli wrote:
On 10/21/11 07:44 , Joel M. Halpern wrote:
I would like to call people's attention to the draft below.
I would like to hear from folks as to what they think of this complement
to some of the existing work on the ND based denial of service attack.
I do not intend to present
Based Denial of Service
Attacks
Author(s) : Joel M. Halpern
Filename: draft-halpern-6man-nddos-mitigation-00.txt
Pages : 6
Date: 2011-10-17
It has been observed that with the large space of IPv6 addresses
within a subnet
application communication will be via an ALG.
Based on our experience, that seems to be a very bad design target.
And it seems unnecessary for the goal of having stable itnernal
addresses for internal communication.
Yours,
Joel M. Halpern
On 9/28/2011 3:57 PM, Roland Bless wrote:
Hi David
, easily recognizable private IP addresses are a really
good feature.
Bert
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Joel M.
Halpern
Sent: Wednesday, September 28, 2011 4:10 PM
To: Roland Bless
Cc: 6man
Subject: Re: Centrally assigned ULAs
There appear to be several different cases, which can be addressed by
different reasonable mechanisms (not firewalls, and not lengthening the
subnet prefix.)
For ISPs, I would assume the primary concern is routers connecting to
subnets used to provide services. A non-dynamic approach to ND
in the
marketting literature. Sorry.)
Yours,
Joel
On 7/13/2011 12:07 PM, Mikael Abrahamsson wrote:
On Wed, 13 Jul 2011, Joel M. Halpern wrote:
For ISPs providing bridged residential services, the ISP normally
operates on the basis that it gets registration information from all
the devices
I rather hate the following idea, and I am not sure that security
gateways would be willing to follow it.
In order for flow label usage to actually help the ECMP hardware, we
have to expect it to work.
What if security gateways were expected to put reasonable, flow
distributing, flow -labels
,
it won't break sessions, but it will degrade performance.
Brian
On 2011-05-09 12:02, Joel M. Halpern wrote:
I rather hate the following idea, and I am not sure that security
gateways would be willing to follow it.
In order for flow label usage to actually help the ECMP hardware, we
have
I would observe that we have multiple documents which note the
importance of traceability for problem resolution. Treating privacy
as an all-or-nothing thing is probably a misleading perspective.
It is extremely likely that privacy addresses, and their bindings to
homes or office desktops,
, Manav (Manav)
Cc: Joel M. Halpern; Christopher Morrow; ipv6@ietf.org
Subject: Re: Hop-by-Hop Extension Header processed in Slow Path?
Manav,
On 04/02/2011 03:53 a.m., Bhatia, Manav (Manav) wrote:
One of the major reasons given for not accepting this was
that no new
extension headers need
Lets be a little careful here:
1) If we say No Extension Headers for intermediate processing, and No
Hop By Hop Options, then we are saying that we do not want any
extensions intended to be processed in intermediate routers. While I
personally like that, I want to make really sure that we
routers will simply
assume that the flow label is useless, since we can not expect peering
scale routers to remark the flow label of packets based on deep packet
inspection.
Also, in many cases, as described in other documents, such re-marking is
effectively impossible.
Yours,
Joel M. Halpern
The goal is not to split single flows across multiple links. In fact,
based on the experience that this causes excessive disordering, we
generally require that load splitting techniques must avoid splitting
flows across links.
Which gets us to the problem. In using multiple links (ECMP /
Yes, the usage of ECMP / LAG is very common. Yes, there is plenty of
data that shows that using just the src and dst IP address in the hash
is NOT good enough. (This does start to get into the quesiton of
whether blindly using the ports is good enough,l but that is the current
practice.)
A data center load balancer can afford, by its nature, to do as much
work as it needs to in order to get the information it needs.
The same can not be said for the ECMP / LAG case which Brian, Shane,
Steve, and I have been talking about.
Specifically, with the structure of extension headers,
Let me phrase Brian's comment differently.
Presume we actually get wide use of the flow label in accordance with
the load balancing draft.
What can go wrong? Well, someone could send all their traffic with a
single flow label, reducing the randomness.
So what goes wrong. All of that
For clarity, in terms of the pieces of your original note:
I consider (a), specifying the format at least to the level of requiring
TLV encoding, to be a good idea.
I do not see any particular advantage in (b), allocating a code point,
but I can live with it if the WG wants it.
And (c),
Then what about if we forget firewalls for the moment?
A lot of routers look for the TCP/UDP Port numbers for LAG/ECMP computation.
Many of them can cope with having a destination options extension, and
therefore that is clearly the better way to handle such information.
And anything we do
If we take the view that a firewall will block anything it does not
know, without question or limit, then
1) We have no way to extend our basic protocols that will pass through
firewalls (we have to tunnel / encapsulate)
2) you are correct that this document does not help.
Also, if we assume
meet specific handling constraints.
Putting handling directives in the extension header means that we are
explicit reversing a statement in RFC 2460.
Yours,
Joel M. Halpern
On 11/17/2010 3:52 AM, Hagen Paul Pfeifer wrote:
On Tue, 16 Nov 2010 20:58:39 -0500, Steven Blake wrote:
This does
Yes, we should adopt this document as a working group document.
I hope that we can quickly complete work on this document.
Yours,
Joel
On 10/9/2010 12:39 PM, Brian Haberman wrote:
All,
I am starting a one week consensus call on adopting:
Title : Using 127-bit IPv6 Prefixes on Inter-Router
Doug, I am confused by your comments.
Let me describe how I understand the situation. We claimed, when we
crafted IPv6, that hosts did not need to use DHCP for address
assignment. As such, many host stacks did not use DHCP for address
assignment.
Now, operators wanted to offer IPv6
The question of whether DHCP should be used to supplement SLAAC when
SLAAC is used for address assignment, woudl seem to be a separate
question. In, for example, the SAVI work, we have been told repeatedly
by folks deploying IPv6 that they have to be able to use SLAAC for
address assignment.
While there may be a few firewalls that will do whatever they think they
need to in order to shut down covert channels, I do not see that as a
significant factor. I imagine most devices will not do so, since it
does represent a meaningful threat to the site being protected.
(There are other
That was supposed to read since it does NOT represent a meaningful threat.
Joel
On 9/7/2010 9:32 PM, Joel M. Halpern wrote:
While there may be a few firewalls that will do whatever they think they
need to in order to shut down covert channels, I do not see that as a
significant factor. I
I want to emphasis one aspect of what Wes said.
We see ECMP (and layer two link aggregates) used almost everywhere.
They are used for many reasons. For example, in some network designs I
have seen there are at least two links between every pair of devices.
Those designs also usually include
The more I think about encouraging locally defined use of the flow
label, the less I like it.
The basic problem is that in the context we are discussing, is for use
by routers.
If you have locally defined flow label usage, then
1) Any vendor selling to an operator has to somehow manage to
The problem for me is that if it is arbitrarily mutable, then we can not
use the flow label in a reliable and useful fashion in the ECMP / LAG.
After all, if it is arbitrarily mutable some ISP might set it to 0xFACE
because that was useful to them without regard to specific flows.
I would
There seem to be two separate things going on here, and they appear to
be getting mixed.
The first thing is the notion that the host should set a non-zeero value
into the flow label. They should do so with the constraint that
different packets which are part of the same flow MUST have the
As far as I can tell, the ping-pong behavior is a bug.
The operators do need some help from the vendors working around the bugs
until the vendors can fix them.
Separately, it appears that the operators want to use /127 for pt-to-pt
inter-router links, and I see no good reason to say that they
is.)
Yours,
Joel M. Halpern
Gorry Fairhurst wrote:
Using UDP-Lite would be fine. I'm not sure how a transition to UDP with
no checksum would help the transport concerns with mis-delivery, etc.
Gorry
Margaret Wasserman wrote:
I had a thought on the use of zero UDP checksums in IPv6...
What if we
Given that LISP ITRs work by intercepting packets that are not addressed
to them, a host implementation would need to be able to intercept
packets in the stack. That is going to need some ability to modify
kernel behavior.
(Yes, I think we will see LISP enabled hosts. I don't think mobility
I believe that saying ITRs don't receiving packets. is a linguistic
step that only confuses people. ITRs receive unencapsulated packets
from the site, and encapsulate them in LISP headers (assuming mappings
are already available.) Now, one can argue that the ITR function in the
router does
Maybe I was missing a bet. You would have to direct all the packets
from the host back to user space to be processed, since it is only the
LISP logic that can decide whether the packet should be tunneled or not.
But if they support that concept, then it can be done.
And yes, that does seem to
Actually, looking at this as a LISP problem is probalby misleading.
This issue applies to any intermediate device based, high capacity,
tunnel mechanism.
1) High capacity tunnel mechanisms are going to be concerned to
implement in hardware, where the UDP checksum may be difficult
2) High
be
that the packet is dropped, which is fine), but we wouldn't have to
worry about what happens when a LISP packet arrives at the wrong LISP
node and/or when a response is sent back to the wrong LISP node.
Thoughts?
Margaret
On Aug 4, 2009, at 10:51 PM, Joel M. Halpern wrote:
The problem
Reading this discussion, there seem to be a small number of practical
choices.
If the vendor hardware that is / will be handling IPv6 can handle the
flow label as part of the ECMP / LAG calcualtion, than an I-D /
direction to use the flow label seems sensible. (This is about what
will be
long time since I actually worked with this aspect of
router (forwarding) logic.
Joel
Margaret Wasserman wrote:
Hi Joel,
On Aug 5, 2009, at 1:42 PM, Joel M. Halpern wrote:
Reading this discussion, there seem to be a small number of practical
choices.
If the vendor hardware
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 field for anything. Even now, no one is sure what to do
with it.
To propose that encapsulators should use this field to mark the
57 matches
Mail list logo
