Joel Jaeggli has entered the following ballot position for
draft-ietf-6man-ext-transmit-04: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
Joel Jaeggli has entered the following ballot position for
draft-ietf-6man-ext-transmit-04: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
On Oct 8, 2013, at 12:06 PM, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
On 08/10/2013 20:19, Joel Jaeggli wrote:
...
--
DISCUSS
, or packet classifiers, inspect other
parts of each packet.
I find that more palatable yeah.
(and possibly some changes for consistency later in the document)
Brian
On 09/10/2013 08:22, joel jaeggli wrote:
On Oct 8, 2013, at 12:06 PM, Brian E Carpenter brian.e.carpen...@gmail.com
On 09/10/2013 08:22, joel jaeggli wrote:
On Oct 8, 2013, at 12:06 PM, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
On 08/10/2013 20:19, Joel Jaeggli wrote:
...
--
DISCUSS
On 6/24/13 3:35 PM, james woodyatt wrote:
On Jun 24, 2013, at 15:11 , Ronald Bonica rbon...@juniper.net wrote:
Network operators MAY filter IPv6 fragments.
Ack. It is a statement of fact, not an IETF imposed requirement.
I hate to be *that* guy... but, perhaps you want to bin this whole draft
On 6/24/13 12:19 PM, Marc Lampo wrote:
-1
Not because I'm a fan of fragmentation, but I think a layer 3 (IP)
protocol that does not support fragmentation should really be a *new*
IP version.
In my opinion, the changes are too dramatic :
if layer 3, not supporting fragmentation, is asked to
On 6/21/13 10:03 AM, Ray Hunter wrote:
I have also read this draft.
It mentions that DNSSEC will be impacted.
What's the alternative if DNSSEC can't send multiple UDP fragments?
so I'm pretty sure I don't want to expose myself to really big replies
because that pushed the opportunity to
On 6/11/13 1:39 PM, Fernando Gont wrote:
On 06/11/2013 11:01 AM, Ole Troan wrote:
a router does ECMP on the 5-tuple. the extension header chain doesn't
help with that. a middlebox makes some policy decision on arbitrary
bits in the packet (including L7). I'm not sure I see what help the
On 6/10/13 4:09 PM, Nalini Elkins wrote:
The lower bound is probably 53. There's a lowest common denominator
problem if you expect to be able to find an l4 header as part of your
forwarding decision
Guys,
53 = not good. Just because some people are re-using old hardware
cards they had
On 6/10/13 9:35 PM, Ray Hunter wrote:
Christopher Morrow mailto:christopher.mor...@gmail.com
10 June 2013 20:59
On Mon, Jun 10, 2013 at 2:44 PM, Ray Hunter v6...@globis.net wrote:
Christopher Morrow mailto:christopher.mor...@gmail.com
10 June 2013 17:22
On Mon, Jun 10, 2013 at 10:56 AM, Nalini
On 6/8/13 4:17 AM, Owen DeLong wrote:
2. Comcast only appears to have a /29 and a /28 (2001:558::/29, 2601::/28). That's only
1.5M /48s, and they have about 10x that many customers. They likely can't use /48 plus
semantic prefixes, because if ARIN doesn't accept semantic prefixes as using
On 6/6/13 1:25 PM, Ray Hunter wrote:
Nalini Elkins wrote:
But the reality of the situation is that much of the Internet appears
to be running where
n is an arbitrary number picked out of the air by a vendor
The number is the product of compromise between (in no particular order)
performance,
On 6/6/13 10:41 PM, Ray Hunter wrote:
joel jaeggli mailto:joe...@bogus.com
6 June 2013 22:19
On 6/6/13 4:09 PM, Fernando Gont wrote:
On 06/06/2013 06:20 PM, Nalini Elkins wrote:
So, if we are talking about the MTU of the local egress interface, then
since, I believe, the minimum MTU size
On 6/6/13 10:09 AM, Lorenzo Colitti wrote:
On Thu, Jun 6, 2013 at 10:56 PM, Ted Lemon ted.le...@nominum.com
mailto:ted.le...@nominum.com wrote:
Saying it says nothing of the sort without even citing it is
not a very convincing argument. If you want to state convincingly
that it
On 6/6/13 4:09 PM, Fernando Gont wrote:
On 06/06/2013 06:20 PM, Nalini Elkins wrote:
So, if we are talking about the MTU of the local egress interface, then
since, I believe, the minimum MTU size for IPv6 is 1,280, then all
devices should be prepared to examine up to 1,280 bytes to get the L4
Message-
From: joel jaeggli [mailto:joe...@bogus.com]
Sent: Tuesday, June 04, 2013 6:27 AM
To: Ivan Pepelnjak
Cc: Andrew McGregor; Brian E Carpenter; v6...@ietf.org WG; ipv6@ietf.org;
manning bill
Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-
jiang-v6ops-semantic-prefix
On 6/3/13 3:59 PM, Andrew McGregor wrote:
That's completely true; many switch chips cannot route on longer than
/64 prefixes, so attempting to do so starts to either heat up the
software slow path, or consume ACL entries, or is simply not supported
at all. While this is arguably a bug, it is
/commmand/reference/cli2.html#wp11682185
cam tables are designed or partitioned in general to favor ipv4 route
count over ipv6, while route table size is impacted that does not affect
throughput.
=
Mistyped and autocorrected on a clunky virtual keyboard
On 4. jun. 2013, at 01:08, joel jaeggli
On 5/29/13 11:47 PM, Lorenzo Colitti wrote:
On Thu, May 30, 2013 at 3:33 PM, Tim Chown t...@ecs.soton.ac.uk
mailto:t...@ecs.soton.ac.uk wrote:
I agree. That said, an ISP, enterprise or group of organisations
can follow whatever semantics they wish within their own borders.
As long as
On 5/25/13 1:36 PM, Brian E Carpenter wrote:
Ray,
On 25/05/2013 21:55, Ray Hunter wrote:
Brian E Carpenter mailto:brian.e.carpen...@gmail.com
24 May 2013 22:50
On 25/05/2013 00:40, John Leslie wrote:
Ray Hunter v6...@globis.net wrote:
I would also like to see some text on whether it is
On 5/2/13 2:24 PM, Fred Baker (fred) wrote:
On May 2, 2013, at 2:17 PM, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
That's why I think the way out is to use the wiggle room mentioned
above. I hope we can.
I'm afraid I don't see any wiggle room. Section 3 of RFC 6437 requires every
On 4/4/13 7:07 PM, Ted Lemon wrote:
On Apr 4, 2013, at 7:44 PM, Richard Roy dick...@alum.mit.edu wrote:
[RR] As I am sure you know, privacy is a cross-layer issue. Any layer that
compromises privacy, compromises it for the user/ITS station. That said,
FNTP/WSMP replace the IP layer with a
On 4/4/13 8:16 AM, Alexandru Petrescu wrote:
Le 03/04/2013 21:08, Doug Barton a écrit :
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
On 04/03/2013 09:00 AM, Michael Richardson wrote: | So, I have a
question: how much privacy is actually contained in the | VIN or
indexed by the VIN? Given
and there's also free food. So come join us.
Tuesday, April 9, 2013
7:00 PM
Mentor Graphics Building B
46885 Bayside Parkway, Fremont, CA
http://www.meetup.com/Silicon-Valley-Automotive-Open-Source/events/101945752/
On 4/4/13 9:01 AM, joel jaeggli wrote:
On 4/4/13 8:16 AM, Alexandru Petrescu
On 4/3/13 12:08 PM, Doug Barton wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/03/2013 09:00 AM, Michael Richardson wrote:
| So, I have a question: how much privacy is actually contained in the
| VIN or indexed by the VIN? Given that it's printed on the windshield.
| Yes, it
On 2/19/13 6:31 AM, Alexandru Petrescu wrote:
Le 18/02/2013 22:07, Roger Jørgensen a écrit :
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
On 2/19/13 12:40 PM, Alexandru Petrescu wrote:
I think I may need to actually better expose the problem: how to form
IPv6 addresses for vehicles. (yes we know these already exist: DHPCv6,
PRefix Delegation on cellular, stateless autoconf, NAT, NPT, 64share).
One of the questions I have in
On 2/6/13 3:41 PM, Ronald Bonica wrote:
Ole,
I am supporting this draft because the community has become accustomed to
stateless firewalls on routers. These stateless firewalls are capable of
filtering based upon information gleaned from both the IPv6 and L4 header.
When a stateless firewall
On 2/5/13 6:56 AM, Warren Kumari wrote:
On Feb 5, 2013, at 9:01 AM, sth...@nethelp.no wrote:
With these specifications, it is impossible on a SLAAC link that two hosts that
have universal-scope addresses (necessarily different if they communicate at
the MAC layer), would have conflicting
On 2/5/13 6:36 AM, Brian E Carpenter wrote:
On 05/02/2013 14:11, Rémi Després wrote:
Le 2013-02-05 à 15:01, sth...@nethelp.no a écrit :
With these specifications, it is impossible on a SLAAC link that two hosts that
have universal-scope addresses (necessarily different if they communicate at
On 2/3/13 11:39 AM, Joel M. Halpern wrote:
On 2/3/2013 2:36 PM, Brian E Carpenter wrote:
On 03/02/2013 17:26, Joel M. Halpern wrote:
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
On 11/21/12 11:43 PM, Ammar Salih wrote:
Dears,
I can see almost everyone agrees to that the RIR info is not accurate and in
many cases is incorrect, so why the hassle of assigning wrong locations? And
why developers are building their applications based on incorrect
information.
The RIR isn't
On 9/26/12 9:47 PM, Randy Bush wrote:
There is clearly two set of recommendations over the same addressing
scenario which I am only trying to clarify with the IETF community.
There aren't really. The world moved on from 3627 and the scenario
described in 6164 represents both observed reality
On 9/21/12 12:03 AM, Usman Latif wrote:
I suppose bodies like IETF all need to ensure that there are
definitive guidelines around addressing architectures so that future
implementations of procotol stacks and features donot overlap with
bits in the IPv6 address space that could potentially
Greetings,
On the heals of work on draft-ietf-6man-impatient-nud-02 and rfc 6583 the
authors have decided to take a lot at their proposal for gratuitous neighbor
advertisement. We believe that this approach has the potential to ameliorate
some problems experienced today in large broadcast
I think this is an important change, and I think our work on the problem
side of the things underscores that.
As a contributor I am in favor of advancing this document.
That said I'd also like to hear from implementers that this is a
reasonable fix with few if any negative consequences
On 8/15/12 12:00 PM, Manfredi, Albert E wrote:
sth...@nethelp.no wrote:
Globally unique. The point here is that the Ethernet standards require
a globally unique MAC address *per box*, not necessarily per interface.
The Sun way of storing a MAC address in EEPROM and configuring all
network
On 8/11/12 8:36 AM, Bob Hinden wrote:
Ole,
On Aug 11, 2012, at 1:33 AM, Ole Trøan wrote:
Fred,
Call this making sure I'm on the same page as anyone else…
RFC 4941 describes privacy addresses, and RFC 4291 describes an EID based on a
MAC Address. RFC 4862 describes stateless address
I just wanted to say that we revved this to remove pointers to expired
drafts replacing them instead with a pointer to
http://tools.ietf.org/html/rfc6583 and some minor word-smithing.
The substance of the draft in particular the suggested algorithm has not
changed.
On 7/31/12 4:50 PM, Erik
On 4/8/12 00:10 , Brian E Carpenter wrote:
On 2012-04-07 17:17, Joel jaeggli wrote:
I hesitate to suggest this because I'll probably turn into a pillar of
salt at some point for harping on it. however...
Just don't look back (towards IPv4).
Getting new extension headers generally parsed
I hesitate to suggest this because I'll probably turn into a pillar of
salt at some point for harping on it. however...
Getting new extension headers generally parsed is a high bar to get
over. That said within one domain of control you might be able to fit a
subset of the information you're
we posted a new version of the neighbor discovery enhancement draft with
the intention of keeping the discussion of standards track-requiring
ehancement to v6nd alive, as we have pushed the operational advice and
impletementation recomendations into a v6ops draft now in WGLC that
draft is:
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 this at the WG
Sorry meant to actually reply.
I'm curious, essentially what the implications are for interaction
between an existing implimentation in a host, and an nd implimentation
which no longer does discovery.
On 10/24/11 06:21 , Joel jaeggli wrote:
On 10/21/11 07:44 , Joel M. Halpern wrote:
I would
On 9/28/11 19:09 , Christopher Morrow wrote:
On Wed, Sep 28, 2011 at 8:51 PM, Dan Wing dw...@cisco.com wrote:
It's too bad computer science is not a science, or we would actually
look at the past, and this mistakes that were made, to build tomorrow's
systems. ALGs were a mistake.
I like
On 9/29/11 06:44 , Christopher Morrow wrote:
On Thu, Sep 29, 2011 at 4:59 AM, Roland Bless roland.bl...@kit.edu wrote:
Hi Jeroen,
Am 29.09.2011 09:30, schrieb Jeroen Massar:
You do realize that the RIRs are providing exactly what you describe? :)
- globally guaranteed unique (due to
On 9/29/11 06:20 , Dan Lanciani wrote:
Jeroen Massar jer...@unfix.org wrote:
|On 2011-09-29 09:20 , Roland Bless wrote:
| Hi Brian,
|
| Am 28.09.2011 23:07, schrieb Brian E Carpenter:
| On 2011-09-28 23:08, Roland Bless wrote:
| ...
| The current ULA-C...
|
| What do you mean? There
On 9/19/11 21:50 , Brian E Carpenter wrote:
On 2011-09-20 15:58, Randy Bush wrote:
I think that RFC 5952 (an update on RFC 4291) provides the guidance
you describe in section 4.2.3.
I see that it does (and the errata on 4291 do not). Thanks.
A reasonable prefix will end with at least 64
On Aug 18, 2011, at 2:13 PM, Fred Baker wrote:
On Aug 18, 2011, at 12:43 PM, George, Wesley wrote:
B. 7.4 ND cache priming and refresh
WEG] might be worth thinking about situations where DHCPv6 is in use and
whether that can be leveraged to achieve something similar to this,
Greetings,
This is followup from our discussion in both v6ops and 6man. We got a lot of
useful input, but I would like to ask the mailing list to see if we can
solidify this into a course of action.
For reference:
ftp://ftp.ietf.org/internet-drafts/draft-gashinsky-v6nd-enhance-00.txt
to retransmit their NS/NA triggering
traffic if the stateless NS/NA transaction fails.
On Sun, 7 Aug 2011 10:57:45 -0700
Joel Jaeggli joe...@bogus.com wrote:
Greetings,
This is followup from our discussion in both v6ops and 6man. We got a lot of
useful input, but I would like to ask the mailing
If you're commenting on v6nd draft I don't think we have any intention of
connecting ~1.8 * 10^19 hosts to a subnet...
On Jul 26, 2011, at 5:10 PM, Alexandru Petrescu wrote:
2^64 is 10s of trillions (not just trillions) and only for anglo-saxons.
2^64 is exabytes of memory (not giga, nor
On Jul 26, 2011, at 6:09 PM, Alexandru Petrescu wrote:
Le 27/07/2011 00:05, Joel Jaeggli a écrit :
If you're commenting on v6nd draft I don't think we have any intention of
connecting ~1.8 * 10^19 hosts to a subnet...
Yes, commenting on the v6nd draft.
Listening to the disxcussion
On Jul 17, 2011, at 4:54 AM, Sander Steffann wrote:
Hi,
I think the same applies to hosts with lots of VMs: maintaining a potentially
large number of NC entries for a single MAC address is unlikely to scale.
This is what routing is designed for.
Then why are there 64 bits in the IID? And
On Jul 17, 2011, at 4:44 PM, Fred Baker wrote:
On Jul 17, 2011, at 1:53 AM, Philip Homburg wrote:
In your letter dated Sun, 17 Jul 2011 11:32:37 +0930 you wrote:
The quite novel technique of allocation transient addresses to
applications/processes to assist with firewalling also takes
On Jul 13, 2011, at 9:51 AM, RJ Atkinson wrote:
On Weds 13 July 2011 at 11:54:08 -0400, Joel Halpern wrote:
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
we had a couple of suggestions.
http://www.ietf.org/id/draft-gashinsky-v6nd-enhance-00.txt
On Jul 12, 2011, at 1:48 AM, Philip Homburg wrote:
Occasionally the subject comes up: /64 (and SLAAC) is bad because it is
easy to DoS routers by getting to perform too much ND.
At least in theory
On Jul 12, 2011, at 9:39 AM, Philip Homburg wrote:
In your letter dated Tue, 12 Jul 2011 12:09:03 -0400 you wrote:
You can't have two-party communication have only one part (the router) =
perform all the actions.
So, in my proposal, the router sends out a request for help. And all of its
On Jul 12, 2011, at 1:39 PM, Fred Baker wrote:
On Jul 12, 2011, at 4:48 AM, Philip Homburg wrote:
Occasionally the subject comes up: /64 (and SLAAC) is bad because it is
easy to DoS routers by getting to perform too much ND.
I suppose the same might be true of ARP. Has it been observed
/excissivly/excessively/
s/lowing/lowering/
s/investigationg/investigating/
s/maintaice/maintenance/
s/recieving/receiving/
s/correpsonding/corresponding/
thanks
cheers,
andrew
On Thu, 30 Jun 2011, Joel Jaeggli wrote:
I would direct the two working groups' attention if I may
On Jun 23, 2011, at 2:31 PM, Manfredi, Albert E wrote:
Ted Lemon wrote:
That's correct. Ultimately the security of the client depends on the
client being secure. Trying to secure the client by securing the
network is a noble cause, but ultimately doomed to failure, because you
can't
On Jun 22, 2011, at 4:41 AM, Mikael Abrahamsson wrote:
On Wed, 22 Jun 2011, Mark Smith wrote:
It may be getting to the point where it'd probably be easier to address
these issues by taking away hosts' ability to multicast to other hosts on
the same segment i.e. switch to an
On 8/23/10 5:11 AM, sth...@nethelp.no wrote:
These mechanisms are applicable to any type of link, would preserve the
simplicity of universal 64 bit IIDs and the other benefits of them e.g.
CGAs, as well as avoiding the ping-pong problem.
IMHO, the universality of 64 bit IIDs went down the
On 04/02/2010 11:11 AM, james woodyatt wrote:
On Apr 2, 2010, at 08:16, Brian E Carpenter wrote:
I do think that Google's solution to this, i.e. being selective
about who gets the records in the first place, is much less of
a hack, with less harmful side effects.
While everyone
It's my understanding that checksum zero udp packets were rare 10 years
ago... how common are they really?
joel
Rémi Després wrote:
Le 28 juil. 09 à 09:29, Francis Dupont a écrit :
= I am strongly against changing all IPv6 implementations.
In this instance, the change is only a backward
I did this for the ietf ids sensor and I haven't see any having run it
since noon.
udp[6:2] == 0
joel
Lars Eggert wrote:
On 2009-7-28, at 10:37, Christopher Morrow wrote:
apologies, I had a tcpdump expr fail :( I do see DNS though with out
checksums, I'll go dig for some more NFS or other
67 matches
Mail list logo
