Hi Wes,
On Oct 28, 2011, at 1:52 PM, Wes Beebee wbee...@cisco.com wrote:
What happens when both RA and DHCPv6 are configured?
Both sets of routes are configured.
This is exactly analogous to a situation where RAs are used and an
administrator has configured some routes using a configuration
On Oct 18, 2011, at 2:29 PM, Jari Arkko wrote:
2. Whether to allocate an EUI-64 from the IANA block and base the IID on
that, or to allocate just a reserved value per RFC 5453. Collisions are
extremely unlikely in either case. Personally, I'd prefer an EUI-64 based
approach though, because
On Sep 27, 2011, at 3:15 PM, Manfredi, Albert E wrote:
Doesn't seem logical to conclude that a NAT would be involved in any of this.
But even if it is, what's wrong with a basic NAT, i.e. one that provides a
simple one to one mapping for a subset of the internal addresses?
If you do need to
I had a thought on the use of zero UDP checksums in IPv6...
What if we allowed the use of zero checksums for UDP as a _negotiated
option_ in IETF tunneling protocols? Those protocols could default to
the use of UDP Lite (or UDP with non-zero checksums if their designers
prefer) and
Hi Vijayrajan,
On Oct 7, 2009, at 12:25 PM, Vijayrajan ranganathan wrote:
Hi Everyone,
Is there a notion that auto-configured IPv6 addresses based on
globally unique prefixes are transient compared to manually configured
ones?
Auto-configured global IPv6 addresses are leased to an interface
On Aug 11, 2009, at 3:58 AM, Luigi Iannone wrote:
If you want LISP on a desktop OS you need to update that OS, hence
at the same time you can patch it to handle the 0 UDP checksum
consequently. I do not see any real issue here.
So, if I want LISP on a non-open-source desktop, you think
Hi Steinar,
On Aug 11, 2009, at 4:11 AM, sth...@nethelp.no wrote:
The dataset analyzed is not relevant to today's networking
connectivity or technologies. Looking very quickly at a small set
of
data I have access to (servers serving web content to the internet
users):
32,945,810,591
Hi Dino,
On Aug 11, 2009, at 11:37 AM, Dino Farinacci wrote:
On Aug 8, 2009, at 8:34 PM, Dino Farinacci wrote:
The spec says ETRs MUST ignore the UDP checksum field. This is
what the LISP authors intended and has been implemented this way.
The spec says ITRs MUST set the UDP checksum
On Aug 11, 2009, at 12:46 PM, Dino Farinacci wrote:
Every host I'm aware of has a facility for setting up an interface
that routes some set of packets--including potentially the default
route--through a tunnel interface that then passes the packet to
userspace for processing.
We call LISP
Hi Dino,
On Aug 11, 2009, at 2:05 PM, Dino Farinacci wrote:
Why couldn't LISP be implemented as a logical interface that
encapsulates or not based on the contents of the LISP Mapping cache
and the results of mapping lookups?
Because you could have 100K of them. Interface data structures
On Aug 11, 2009, at 2:45 PM, Dino Farinacci wrote:
I was talking about running an ITR as a logical interface on a LISP-
aware end-node or a home gateway, so I'm not talking about
something that would need to scale to handle 100K simultaneous
connections.
Doesn't matter. You can still talk
On Aug 7, 2009, at 11:24 AM, Francis Dupont wrote:
= in fact the IPv6 addresses don't need to be the same when xTRs are
attached to regular links with /64 prefixes. So IMHO most of this
discussion is insane:
- if we need to vary things between a pair of IPv6 xTRs it should
be enough (and
Hi Noel,
On Aug 7, 2009, at 3:31 PM, Noel Chiappa wrote:
From: Francis Dupont francis.dup...@fdupont.fr
the O UDP checksum proposal obsoletes all the today deployed nodes
which check them (so all hosts I know and perhaps a lot of routers
too)
OK, so what are the other options for
The dataset analyzed is not relevant to today's networking
connectivity or technologies. Looking very quickly at a small set of
data I have access to (servers serving web content to the internet
users):
32,945,810,591 packets received, 0 dropped due to bad checksum (ip
header checksum)
Does UDP-Lite work through NAT
boxes? (LISP has a mobile-node mode, which we would like to see
work through
NAT boxes, so any proposed alternative solution has to work through
NAT boxes
too.)
For IPv6?
Sorry I didn't reply to this in the earlier message...
(1) There isn't enough NAT
Hi Havard,
On Aug 7, 2009, at 8:22 PM, Havard Eidnes wrote:
the O UDP checksum proposal obsoletes all the today deployed nodes
which check them (so all hosts I know and perhaps a lot of routers
too)
OK, so what are the other options for encapsulating a packet in a
IPv6
packet?
Um,
On Aug 8, 2009, at 8:34 PM, Dino Farinacci wrote:
The spec says ETRs MUST ignore the UDP checksum field. This is what
the LISP authors intended and has been implemented this way.
The spec says ITRs MUST set the UDP checksum field to 0.
Could you tell us how to achieve this on commonly
Hi Joel,
I think I understand both sides of the UDP checksum issue now...
We (or at least some of us) believe that it is a hard requirement to
support ECMP through legacy routing equipment. This equipment will
only identify flows using the 5-tuple described in the draft. These
devices
Hi Fred,
There are three things we are trying to address here:
- We want to support load balancing through legacy systems that only
support load balancing based on the 5-tuple of IP src/dest address,
protocol/next header and UDP or TCP src/dest ports. To meet this goal,
we need a UDP (or
Hi Fred,
On Aug 6, 2009, at 1:42 PM, Templin, Fred L wrote:
How are non-TCP/UDP flows handled by these legacy systems
today? For example, 6to4 uses ip-proto-41.
My understanding is that these flows will not be handled well...
Since ECMP load balancers will have limited information
Hi Joel,
On Aug 4, 2009, at 10:51 PM, Joel M. Halpern wrote:
The problem is not what the ITRs and ETRs use the field for. They
could / can use the field.
The problem is that the UDP header was introduced specifically so
that different flows would be different in a place that the routers
Hi Joel,
On Aug 4, 2009, at 10:51 PM, Joel M. Halpern wrote:
The problem is not what the ITRs and ETRs use the field for. They
could / can use the field.
The problem is that the UDP header was introduced specifically so
that different flows would be different in a place that the routers
Hi Shane,
On Aug 5, 2009, at 12:50 PM, Shane Amante wrote:
To bring this back up a level, while it's /possible/ to encourage
vendors to adopt the IPv6 flow-label as input-keys to their hash-
calculations for LAG/ECMP, it takes [a lot] of time to see that
materialize in the field.
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 that is / will be handling IPv6 can handle
the flow label as part of the ECMP / LAG calcualtion, than an I-D /
direction to
On Aug 5, 2009, at 2:54 PM, Christopher Morrow wrote:
What was the original reason for removing the ability to do zero
checksums on udp in v6? Are we sure that that decision is still
sensible/appropriate in today's internet/world?
I have not been around long enough to have been there when
On Aug 5, 2009, at 3:55 PM, Christopher Morrow wrote:
This I don't recall at all... I think part of my question is we (as a
group) are assuming that the reasons for requiring ipv6 udp checksums
as stated +10 years ago are still valid, I don't see data supporting
that fact.
There are some
On Jul 30, 2009, at 6:33 PM, Dino Farinacci wrote:
What I'm saying is that *if* UDP us used, it needs to be used
according to the RFCs that capture the IETF consensus on their use,
or the IETF consensus must be revised.
And what we are are saying is to be practical (and sensible).
On Jul 31, 2009, at 3:06 AM, Rémi Denis-Courmont wrote:
is basically UDP except the checksum would only covering the IPv6 and
transport header. Hmmph, this is just like UDP-Lite really but it
seems
like there is opposition to overloading UDP-Lite. Then the 64-
translators
would convert it
Hi Pekka,
On Jul 31, 2009, at 3:47 AM, Pekka Savola wrote:
On Thu, 30 Jul 2009, byzek wrote:
It's not about performance; a large percentage of the currently-
deployed
hardware can¹t do UDP checksum calculations during encapsulation
because it
doesn¹t have access to the entire packet. Most
On Aug 2, 2009, at 6:31 PM, Marshall Eubanks wrote:
http://tools.ietf.org/html/draft-eubanks-chimento-6man-00
We intend to rev this shortly and comments would be appreciated.
If you do rev this document, I would like to see:
(1) An explanation of the difference in applicability between this
On Aug 4, 2009, at 7:28 AM, Iljitsch van Beijnum wrote:
On 31 jul 2009, at 9:06, Rémi Denis-Courmont wrote:
Sounds like this would require a third datagram protocol number, that
is basically UDP except the checksum would only covering the IPv6 and
transport header. Hmmph, this is just like
Hi Byzek,
On Jul 30, 2009, at 8:31 PM, byzek wrote:
It's not about performance; a large percentage of the currently-
deployed
hardware can’t do UDP checksum calculations during encapsulation
because it
doesn’t have access to the entire packet. Most hardware is
streamlined to
only
Hi Noel,
On Jul 30, 2009, at 7:33 PM, Noel Chiappa wrote:
Dino, why don't we just drop the 'inside IPv6' encapsulations from
the spec?
I.e. keep only IPv4 in IPv4 and IPv6 in IPv4? The IPv6
encapsulations could be
documented in a short non-IETF note that's posted on a personal web
page
Hi Dino,
On Jul 30, 2009, at 4:25 PM, Dino Farinacci wrote:
Hi, Dino,
On 2009-7-29, at 14:02, Dino Farinacci wrote:
From a practical perspective, we prefer that a LISP encapsulator
(ITR
and PTR) not incurred additional work when encapsulating packets.
could you share some data on how
On Jul 29, 2009, at 8:02 AM, Dino Farinacci wrote:
This is a reminder that draft-fairhurst-6man-tsvwg-udptt and
http://tools.ietf.org/html/draft-eubanks-chimento-6man-00
are still open and will be discussed at the 6man meeting Wednesday.
Basically, one prescribes no checksum for the outer
On Jul 29, 2009, at 8:02 AM, Dino Farinacci wrote:
This is a reminder that draft-fairhurst-6man-tsvwg-udptt and
http://tools.ietf.org/html/draft-eubanks-chimento-6man-00
are still open and will be discussed at the 6man meeting Wednesday.
Basically, one prescribes no checksum for the outer
Hi Remi,
On Jul 27, 2009, at 4:27 PM, Rémi Després wrote:
Two constraints on IPv6 address formats appear to be unnecessary
while prohibiting some designs that are useful to enhance IPv6
benefits:
- One concerns addresses that never appear on any IPv6 link.
Since only purpose of these
Hi Remi,
On Jul 27, 2009, at 4:27 PM, Rémi Després wrote:
Two constraints on IPv6 address formats appear to be unnecessary
while prohibiting some designs that are useful to enhance IPv6
benefits:
- One concerns addresses that never appear on any IPv6 link.
Since only purpose of these
Hi Bob and Brian,
Could you tell me which drafts correspond the following agenda items:
- DSL Line Identification using Rtr. Sol.
- Ephemeral IPv6 Addresses
- IPv6 Address State Extension
- Domain name-based interface selection
- Load balancing on IPv6 anycast address
Thanks,
Margaret
On Nov
Has there been any resolution on how/if it will be possible to attend
this meeting remotely (conference bridge, web conference, jabber room,
etc.)?
I will not be able to travel to Montreal, but would like to attend all
or part of the meeting remotely, if possible.
Thanks,
Margaret
On Sep
-analysis-01
A new version of I-D, draft-mrw-6man-ulac-analysis-01.txt has been
successfuly submitted by Margaret Wasserman and posted to the IETF
repository.
Filename:draft-mrw-6man-ulac-analysis
Revision:01
Title: An Analysis of Centrally Assigned Unique Local
Message-
From: Margaret Wasserman [mailto:[EMAIL PROTECTED]
Sent: Monday, November 12, 2007 5:36 PM
To: Per Heldal
Cc: ipv6@ietf.org
Subject: Re: New Version Notification for
draft-mrw-6man-ulac-analysis-00
Hi Per,
Regardless of the listed arguments one may also question IETFs
role
Hi Per,
Regardless of the listed arguments one may also question IETFs role in
the definition of (any) ULA as there is no technical reason why
such an
address-block must be tagged 'special'.
Thanks for raising this point. Others have made a similar argument
in the past, and it should
: IETF I-D Submission Tool [EMAIL PROTECTED]
Date: November 11, 2007 10:16:15 PM EST
To: [EMAIL PROTECTED]
Subject: New Version Notification for draft-mrw-6man-ulac-analysis-00
A new version of I-D, draft-mrw-6man-ulac-analysis-00.txt has been
successfuly submitted by Margaret Wasserman and posted
, en
To: Margaret Wasserman [EMAIL PROTECTED],
Mark Townsley [EMAIL PROTECTED],
Robert Hinden [EMAIL PROTECTED],
Brian Haberman [EMAIL PROTECTED]
Subject: Fwd: IPR Notification
X-Spam: [F=0.0001020200; B=0.500(0); S=0.010(2005092001);
MH=0.500(2005102404); R=0.010(s3/n722
[This message is bcc:ed to all INT area WGs, the IESG and the IAB.]
Hi All,
We have created an Internet Area mailing list -- [EMAIL PROTECTED]
This list will be used to announce Internet area BOFs, to discuss
Internet area WG charter updates and to discuss other issues related
to the
Hi Suresh,
Thanks for the quick turnaround!
When the new draft comes out, I will send it to IETF LC. After we
make it through IETF LC, the document will be reviewed by the full
IESG. So, at this point, there are no further changes that need to
be made, but you may need to make changes
I have a process-related concern with draft-ietf-ipv6-ndproxy-02.txt
that I would like to discuss on this list to see what others think...
I haven't reached the point (yet) where I have a fully-formed
objection, but I have a strong enough concern that I thought it would
be worth some
Hi Jinmei,
At 2:57 AM +0900 5/14/05, JINMEI Tatuya /
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
I've asked related questions about this comment on the wg list two
times, including requested information at the Minneapolis meeting, but
I've not got any responses...if this comment does not
Hi All,
I have a few AD Review comments on
draft-ietf-ipv6-privacy-addrs-v2-03 that I would like to have
resolved before I send this document to IETF LC. I've included those
comments below.
Brian and Bob, the tracker indicates that this document is intended
for publication as a Draft
Hi All,
I have finished my AD review of
draft-ietf-ipv6-optimistic-dad-05.txt. I found no blocking issues,
and I have sent the document to IETF Last Call.
Margaret
IETF IPv6 working group mailing list
ipv6@ietf.org
Hi Bob,
Should there also be an upate to the IANA considerations section
asking IANA to list this allocation as deprecated?
Margaret
At 11:46 AM -0800 3/16/05, Bob Hinden wrote:
Hi,
At last weeks IPv6 session in Minneapolis, the working group reached
a consensus to deprecate the IPv4-compatible
This looks good to me, Bob.
Let me know when the IPv6 WG is comfortable with the text, and I will
put in an RFC Editor note and approve the document.
Thanks,
Margaret
At 5:58 PM -0800 3/10/05, Bob Hinden wrote:
Here is what I hope to be the final update.
Thanks,
Bob
---
Hi All,
During IESG review, Mark Andrews raised a significant operational
concern regarding the DNS section of the ULA document
(draft-ietf-ipv6-unique-local-addr-09.txt), and I am currently
delaying approval of the document until the issue can be resolved.
The concern, which is shared by
Hi Dave,
Point taken. How about:
A proxy MUST ensure that loops are prevented, either by running
the Spanning Tree Algorithm and Protocol defined in [BRIDGE] on all
proxy interfaces as described below, or by being deployable only in
an environment where physical loops cannot occur. For example,
On Wed, Dec 08, 2004 at 09:27:50AM -0500, Brian Haberman wrote:
I agree that it is a problem, but not one specific to ULAs.
Indeed, it's the dont-publish-unreachables's draft space... but that one
never reached consensus or thus publication.
Right. And, while I personally agree with the
Hi Mark,
Thats why I said the DNS section was a cop out. The DNS
information hadn't been collected, distilled and put on
paper. I attempted to do that.
* Don't publish ambigious addresses global.
* It is unwise (but not wrong) to publish unreachable
Hi Pekka,
There is a new version of this document available at:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-link-scoped-mcast-07.txt
Could you check if it addresses your substantial concerns?
Margaret
At 12:15 AM +0200 11/13/04, Pekka Savola wrote:
On Sat, 30 Oct 2004, The IESG wrote:
The
Hi Jinmei,
Sorry, but I seem to have failed to respond to this message...
At 5:26 AM +0900 11/5/04, JINMEI Tatuya /
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
I basically think we should publish 2461bis and 2462bis at the same
timing with consistent changes. So, it would make sense to hold
HI Jinmei,
Thank you for making these changes. The changes you've made do a
very good job of reflecting my feedback. I believe that the document
is much clearer and more concise with the changes you have made, and
the document with the changes is acceptable to me. Do you agree that
these
At 2:54 PM -0500 11/3/04, Dan Lanciani wrote:
Is this ARIN discussion archived somewhere?
The discussion I've seen happened on a mailing list archived at:
http://www.arin.net/mailing_lists/ppml/index.html
I'm not on the list, and the archives seem to end shortly after this
discussion was started
Hi All,
We're having a discussion on URIs and IRIs in the IESG that has led
me to realize that the URL literal IPv6 address format described in
RFC 2732 does not contain any provision for including a zone ID. I
don't think that we could simply add a %zone-id to the end of the
IP address,
PM -0600 10/29/04, JORDI PALET MARTINEZ wrote:
Hi Margaret,
Why not ? We are using the [] to enclose the IPv6 address, so then the %
will be also inside the square brackets, right ?
Regards,
Jordi
De: Margaret Wasserman [EMAIL PROTECTED]
Responder a: [EMAIL PROTECTED]
Fecha: Fri, 29 Oct 2004 15
At 12:56 PM +0200 3/23/04, Jari Arkko wrote:
I think it would be possible to detect loops if we wanted really
hard to do that. That might just
lead to reinvention of the spanning tree protocol, though.
This is a danger, yes.
Why is this a danger?
IMO, the ND proxy mechanism effectively does
Hi All,
I've completed my AD evaluation of
draft-ietf-ipv6-unique-local-addr-03.txt. My comments (attached
below) include a few substantive issues that I would like to discuss
with the WG before sending this draft to IETF last call. Thoughts?
I have also included a few non-blocking editorial
Apparently there are some people in the IETF who use mail readers
that cannot handle standard text attachments. For those people, here
is a resend of the e-mail I sent earlier with the attachment included
in-line. Sorry for the duplication.
Hi All,
I've completed my AD evaluation of
Hi Mukesh,
One of the issues raised was about rate limiting methods
suggested by the draft. The draft suggests Timer-based,
Bandwidth-based and Token-bucket based methods for limiting
the rate of the ICMP messages.
After going through the discussion about this in the archive
and thinking about
= In 6.2.7 :
Routers SHOULD inspect valid Router Advertisements sent by other
routers and verify that the routers are advertising consistent
information on a link. Detected inconsistencies indicate
that one or
more routers might be misconfigured and SHOULD be logged
to
Hi Eric,
I have been speaking to different
companies here in Israel, and the basic answer is that if I
can not have site locals and NAT then I will not move to IPv6.
If these people are happy with IPv4 NAT, why would they want
to move to IPv6? They couldn't need more address space (net
Hi Fred,
So in the general case I don't see a problem with deprecating
things under the right circumstances, but I do have a problem with
removing them outright. Deprecation doesn't prevent people from using
them, but outright removal can be dangerous. And in this case, the
assertion
Hi Scott,
Speaking only for myself, I would like to address a couple of the
points that you have made.
It is my opinion that there is a difference between a working group
deciding to adopt a technology and a working group deciding
to delete a technology from an existing IETF
71 matches
Mail list logo
