-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Scott
Brim
peer is also a nit - if you
want an unknown someone to be able to contact you, you need to make
yourself findable, whether the protocol design is p2p or not. Otherwise
you don't.
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Brian
E Carpenter
On 10/07/2013 05:28, RJ Atkinson wrote:
...
But for one problem: adaptation layer fragmentation is
*transparent*, so there is no way for an application
to do the equivalent of PMTUD to
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Fernando Gont
If you're going to deprecate something on the assumption that some
implementation does something stupid about it, then I wonder what we'd
be left with. -- for instance, you
Why not?
Actually, I was about to make that suggestion myself. We can stop this infinite
thread by simply saying, do whatever semantic tricks you want with the address
blocks allocated to you, but know that you won't get any more just so you can
play those semantic tricks.
What's wrong with
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
manning bill
Pragmatically, much of the IPv6 protocol/application development has
ignored half the 128bit space and treats IPv6 as a 64bit address platform.
Exactly.
It's time to
The kind of painfully obvious solution, especially when we consider the effects
of the much-ballyhooed Internet of Things, is that we have to allow for
prefixes /64.
It's not just home nets. What about automobile nets, or more generically,
vehicle nets? Are we going to try to rationalize why
-Original Message-
From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
Advertised where? Vehicle prefixes will need to be heavily aggregated anyway,
so you wouldn't see anything as long as a car's /48 in BGP.
Dark space is a fact of life when you have lots of address
-Original Message-
From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com]
Some applications involving the use of VIN may have been discussed.
One requirement may come from V2V communications when infrastructure is
not available: how to know the IP address of the seen
-Original Message-
From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com]
For one, homenets don't move or at least not as fast as cars. A
homenet
may change its attachment every year or so, whereas a car may change it
every 10 minutes or so.
Just as a side FYI, my homenet
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Alexandru Petrescu
Yes, the ULA prefix (RFC 4193 section 3.2.2) generates a 48bit prefix
randomly. That suggested algorithm is seeded by time, EUI-64 into a
key, and then SHA-1.
Anyway.. the idea is that you
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Michael Richardson
If I can derive the VIN from the prefix, I agree that it helps identify
the vehicle, but not really. If any of this stuff is going to be
useful, there will already be a
with an impending problem to be
shuttled off to the emergency lanes, to get out of the way of the moving
traffic.
Bert
-Original Message-
From: Scott Brim [mailto:s...@internet2.edu]
Sent: Monday, April 01, 2013 9:23 AM
To: Manfredi, Albert E
Cc: Alexandru Petrescu; fg...@si6networks.com; 6man
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Christian Huitema
There are two solutions today: multicast all the way, from the source
to the various destinations; and, unicast all the way. The multicast
solution suffers from very poor
Alexandru Petrescu wrote:
I meant to say that this VIN mapping to an IPv6 address may be useful
not only to newly manufactured vehicles, but also to old vehicles.
Honestly, I've never much liked any scheme that attempts to hardcode anything
about the interface into an IP address that way. And
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Alexandru Petrescu
Well they're different than Ethernet interfaces. One could have
several
Ethernet interfaces in a single car. And, cars have their globally
unique space of identifiers
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Randy Bush
[ULAs]
ahh. so this is really just another end-run around the registry
system. instead, fix the registries.
Of course, but what's wrong with that? I too would be in favor of using ULAs
for this in-vehicle
+1
If a better alternative is devised for 4rd, as Roland proposes here, then can
we deprecate the u/g bit usage? Seems to me that privacy addresses are
preferable anyway, if not DHCP or statically assigned ones, so any importance
assigned to u/g surely becomes a historical artifact?
Bert
-Original Message-
From: Ammar Salih [mailto:ammar.sa...@auis.edu.iq]
I remember few years ago when there were
sanctions on Iraq, people used to download software updates through
VSAT as
their IP address shows Germany or Netherlands.
But I'm suggesting to you that most people in
-Original Message-
From: Ammar Salih [mailto:ammar.sa...@auis.edu.iq]
It's not about supporting dictatorial regimes in isolating their
citizens
from the internet,
Interesting how politics manages to enter into everything.
It doesn't matter what the original intent might have been.
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 country, then it is certainly
possible to have whatever layer 3-7 filters implemented in that router, as just
such filters are implemented in firewalls. Or, if an
Brian E Carpenter wrote:
On 14/08/2012 18:16, Simon Perreault wrote:
Since privacy addresses are supposed to be configured alongside
regular
SLAAC addresses, there should be no need for an explicit fallback.
Just
enable both SLAAC and privacy simultaneously. If SLAAC fails, you
still
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 cards with the same MAC address was perfectly
sth...@nethelp.no wrote:
All I'm saying is that there is nothing wrong,
standards-wise, in having *one* globally unique MAC address per box.
But I'm disagreeing.
There is a lot wrong with having the same address on multiple ports of a box,
when those multiple ports share the same network.
Fred Baker (fred) wrote:
The work-around, I suggest, would be to have the station use a privacy
address instead of a MAC-based address when a duplicate MAC address is
detected.
Actually, I has the same thought when this subject came up. And DAD.
I gather nobody agrees with me.
FWIW, I
I'm sure that I'm remembering correctly that we had quite a few posts, back and
forth, about whether or not IPv6 addresses should be represented in lower case
hexadecimal. And as I recall, the WG consensus seemed to be that upper case hex
was a somewhat dated way of showing hex, and that
From: mboned-boun...@ietf.org [mailto:mboned-boun...@ietf.org] On
Behalf Of Brian Haberman
On 5/9/12 10:52 PM, Lee, Yiu wrote:
Hi Carsten,
Thanks very much for reviewing the document. I just want to add a
point to
your question about how applications decide when to use this
multicast
I don't know why IPv6 becomes more arcane with every new I-D. Why not work to
make it simpler, rather than more complex and confusing, with every new
iteration?
In this particular case, it is really confusing to change the location of this
new field, 64IX, depending whether it's ASM or SSM.
Maybe I missed it in the I-D, but this mechanism appears most useful for mobile
devices, which roam among different networks. The stable Interface ID is only
stable as long as the portable device stays connected to one access point,
which presumably would not be very long.
With that in mind,
Yes, that was also my reaction. Why one Internet? Because Internet means tying
together multiple separate networks. Of course you can have the same addresses
on the different networks. Nothing new there either. That's why we have NATs,
NAPTs, and IPv6 NPTs.
No one is forcing an ISP or an
Just obsessing over this:
In the ULA RFC and postings, people always use the fc00:: prefix as an example,
it seems. But according to RFC 4193, the 8th bit in the first octet must be set
to 1, to indicate local, at least until someone figures out how to use a
non-local ULA scheme.
So in fact,
Can we vote to have your interpretation pasted into RFC 4862bis?
Honestly, that I get, at least.
Bert
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Karl
Auer
Sent: Wednesday, April 04, 2012 6:42 PM
To: ipv6@ietf.org
Subject: Re: DHCPv6
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Karl Auer
Please state your preference for one of the following default
options :
A. Prefer public addresses over privacy addresses
B. Prefer privacy addresses over public addresses
B.
While I
Perhaps we should go back to what 576 bytes really was, in IPv4, and apply the
same rules to IPv6.
576 bytes is NOT the smallest MTU allowable in an IPv4 path. It refers to the
smallest packet that must be able to be de-fragmented, in IPv4. Why can't we
apply a similar rule to IPv6?
From RFC
Yes from me. Thanks.
Bert
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Brian E
Carpenter
Sent: Thursday, November 17, 2011 12:00 AM
To: 6man
Cc: Kerry Lynn
Subject: Re: Link-local IPv6 addresses in URIs
Dear 6man,
Kerry and I talked about
I dunno about automotive, but I'm with Roland on the requirement to keep the
internal controls strictly isolated from the Internet in other platforms. Yes,
there is remote condition monitoring going on, but NEVER directly from the
Internet to the internal devices, other than through proxies.
Dan Wing wrote:
ALGs are harmful and the NAT industry has over a decade experience
that shows ALGs are harmful. ALGs have prevented proper operation
of SIP, FTP, and a variety of other protocols.
Harmful in your sense of the word is good, in some circles. Remember, we are
only talking about
Ted Lemon wrote:
There probably is no single solution. But let's consider the solution
Mark proposed: use the fact that you control the infrastructure to
control the flow of packets on the network in such a way that rogue RAs
cannot reach leaf nodes. The reason I object to this solution,
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 control what networks the client connects to.
No, I think
Brian Haberman wrote:
In IPv6, what will the typical SOHO router look like, though? Same
NAT functionality as IPv4? And if not, is there an automatic way of
configuring this SOHO router for any possible DHCP relay function?
What about a situation where rather than using DHCP relay, a
Thomas Narten wrote:
Let me ask a question. In IPv4, for typical SOHO routers, do they
support DHCP relay agent functionality? (My guess is no.)
And what about configuring it? It is *not* plug and play, zeroconf
magic...
Since they are typically NAPTs, I'd say no. They are local DHCP
Mark Smith wrote:
3.2 If there are several ways of doing the same thing, choose one.
If a previous design, in the Internet context or elsewhere, has
successfully solved the same problem, choose the same solution
unless
there is a good technical reason not to. Duplication of the
George Michaelson wrote:
This document doesn't recognise the reality of how language and names
develop.
This area is something which is best left to be 'standardised' after
the fact, once the community has already decided what it calls the
address/parts.
We are not the 'Academie
Ed Jankiewicz wrote:
The comment from Tim that the DHCPv6 man not be of use in SOHO
deployments, I think SHOULD still leaves enough wiggle room for a
variety of implementations with different feature sets.
I support SHOULD for DHCPv6 as well.
But responding to the above, purely
Mark Smith wrote:
I think it would be reasonable to make DHCP a SHOULD, however
I've thought that one of the reasons SLAAC exists is to provide
simpler and lighter weight address configuration method for resource
constrained end-nodes such as embedded ones. So perhaps it could be
worth
Brian E Carpenter wrote:
Nodes MUST NOT change the flow label. But since you can't detect
whether
it's been changed, mechanisms using the flow label for some purpose
must
be robust against unanticipated changes.
If I may try to express what I perceive the problem to be, we have been told
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Richard Hartmann
Sent: Thursday, April 14, 2011 8:49 PM
To: ipv6@ietf.org
Cc: Scott Schmit
Subject: Re: Introducing draft-6man-addresspartnaming
On Fri, Apr 15, 2011 at 02:17, Scott Schmit
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Richard Hartmann
Sent: Friday, April 08, 2011 8:10 PM
To: Scott Brim
Cc: 6man List
Subject: Re: Introducing draft-6man-addresspartnaming
On Sat, Apr 9, 2011 at 01:01, Scott Brim
I guess I'm missing what the solution is.
As 3177-bis says, the IETF has no control over how service providers hand out
IPv6 address space. From what I've been reading in the past few years, it looks
like at least some providers are planning to give /64s to customers.
The way I see it, unless
On Mar 3, 2011, at 2:10 PM, TJ wrote:
Really? None of the ISPs I have spoken with, and certainly none of
the ones I have worked with, are following a /64 per client plan. I
have discussed /48s vs /56s vs /60s ... but never a /64.
James Woodyatt wrote:
Here is a Reddit commenter from
Brian E Carpenter wrote:
There is no way this is an erratum. There was a clear choice in the WG
to standardise on lower case.
Glad to hear this. I reacted very much like Jeroen Massar. That's SO last
century!
(Although I did check to see what ipconfig does in Windows. Upper case!)
Bert
Mikael Abrahamsson:
Why not? DHCP could populate the neighbour table with very
long lifetime?
The only change I see would be for the operation of DHCPv6 to
always run
if there isn't any response to RS and no RA is seen.
Perhaps some minor changes need to be made to allow for
Suresh Krishnan wrote:
You are absolutely right. The XP devices are SLAAC-only for IPv6 as I
said, but they are dual-stacked. So even in the absence of IPv6
connectivity they will still have IPv4 connectivity.
From my perspective, I find this situation to be fundamentally intolerable,
but
Mark Smith:
Possibly it will be surprising to a number of people on this list, but
some of the ideas in IPv6 are over 30 years old, such as single, fixed
size network and node portions, and using link layer
addresses as layer
3 node addresses -
Address Mappings, Jonathan B. Postel, 2 May
Hemant Singh:
Well, did folks get a chance to read this draft which
proposes normative changes to an existing RFC as follows. The text is
snipped from section 6 of draft-kohno...
[The [RFC4291]is to be revised to allow longer prefix than /64, and
state that Subnet-router anycast address
Jared Mauch:
The biggest feedback I hear from people about IPv6 (besides the extra
bits for addressses) is Security, but they generally don't know what
that is outside marketing speak.
+1, in spades. Nor do these folk seem to appreciate that it's not the network
that bears the greatest
Mark Smith:
Well, GPS was only one of the examples I used, and I was envisioning
one that is built into the dash. To continue with the
analogy, how many
people would buy and install after-market electric windows, anti-lock
brakes, electronic fuel injection etc.?
Analogies work both ways.
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On
Behalf Of Thomas Narten
I do like the idea of clarifying that network layer security is a good
general thing and that IPsec/IKE is the solution for that. But this
still begs the question in that
-Original Message-
From: Sean Siler [mailto:sean.si...@microsoft.com]
You are mixing engineering requirements and deployment
requirements. Yes , the hardware and software MUST support
IPsec. The customer doesn't *have* to do anything. They can
use Mickey's Secret Decoder Ring
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On
Behalf Of Brian Haberman
All,
This is a consensus call to determine if there is interest in
having 6MAN adopt the two RPL drafts (draft-hui-6man-rpl-option and
draft-hui-6man-rpl-routing-header).
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On
Behalf Of Brian E Carpenter
There appear to be two viable approaches:
1. Definitively forbid locally defined use of the flow label.
Strengthen RFC 3697 to say that hosts SHOULD set a
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On
Behalf Of Shane Amante
c) Declare the flow-label is _immutable_ and must be set by
all hosts and must only contain a 3- or 5-tuple hash of the
appropriate IPv6 headers. Further use cases for the
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On
If we can count on hosts setting the flow label with suitable
granularity, then we can use the flow label (plus src and dest IPv6
address) in our ECMP and LAG hashes without having to look
for
, Albert E
Sent: Thursday, April 15, 2010 1:08 PM
To: Joel M. Halpern
Cc: ipv6@ietf.org
Subject: RE: Extracting the 5-tuple from IPv6 packets
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On
If we can count on hosts setting the flow label with suitable
-Original Message-
From: Mikael Abrahamsson [mailto:swm...@swm.pp.se]
Here is the crux of my not understanding the problem:
And no, I haven't seen any residential rollout
plan where
IPv6 would be provisioned in the static way you describe,
DHCPv6-PD seems
to be the most
place!
- Wes
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Mikael Abrahamsson
Sent: Monday, November 09, 2009 12:40 PM
To: ipv6@ietf.org
Subject: RE: Liaison from BBF
On Mon, 9 Nov 2009, Manfredi, Albert E wrote:
Does not the ISP control, own
-Original Message-
From: Fred Baker [mailto:f...@cisco.com]
RIP is a router/router protocol and uses UDP...
SNMP is used to manage routers and uses UDP...
Yes, I wish UDP had never been invented so that people would write
transports that actually did what they intended, but
-Original Message-
From: Dino Farinacci [mailto:d...@cisco.com]
Sent: Thursday, July 30, 2009 4:30 PM
We also need to consider the possibility that a packet will be
received by a different LISP node than the one for which it was
intended, or that it will arrive at the
-Original Message-
From: Thomas Narten [mailto:nar...@us.ibm.com]
How's this to drive the point home further... 2461 (Neighbor
Discovery) is NOT mandated. It is only listed as a SHOULD. (This is
because some link layers might not need all parts of ND. But this has
turned out to be
-Original Message-
From: Seiichi Kawamura [mailto:kawamu...@mesh.ad.jp]
Maybe so.
If a difference in IPv4 has worked for us thus far,
we may be able to live with the difference in IPv6,
(although I myself would prefer []),
except for Dave's 2001:4860:b003::68:80 example.
As long
-Original Message-
From: Hemant Singh (shemant) [mailto:shem...@cisco.com]
Folks,
The issue related to the statement in our draft that says to
not issue an address resolution for an IPv6 address that is
not on-link has been addressed by the following new and
amended text in
-Original Message-
From: Hemant Singh (shemant) [mailto:shem...@cisco.com]
Please see a revised NEW paragraph below and let us know if
this is more
clear. Basically we meant to say that when sending an NA in
response to
an NS, the host does not use the Conceptual Sending
-Original Message-
From: Wes Beebee (wbeebee) [mailto:wbee...@cisco.com]
WB The fact that Redirects cannot signal that an address is
off-link derives from an extremely subtle and non-obvious
consequence of the application of the Redirect message
processing rules in section 8.1.
-Original Message-
From: Fred Baker [mailto:f...@cisco.com]
This note discusses a feature to support building Greynets for IPv4
and IPv6.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-baker-v6ops-greynet-00.txt
In the IPv6 case, I'm not sure I
-Original Message-
From: Thomas Narten [mailto:[EMAIL PROTECTED]
My understanding is that when clients invoke DHC, and there are no
DHCP servers, they backoff and retransmit, eventually stablizing as is
governed by the following (from RFC 3315):
MRT specifies an upper bound on
-Original Message-
From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
...
we would ideally also have corresponding IPv6 subnets that are
algorithmically derived from the IPv4 subnets.
I used to think that was a good way to design an initial
IPv6 addressing plan. But from
-Original Message-
From: Jeroen Massar [mailto:[EMAIL PROTECTED]
Sean Siler wrote:
Microsoft based Operating Systems join the All Nodes On
Link Multicast Group as specified by RFC 4291, but that
RFC does not mandate that nodes must reply to ICMP echo
requests. So while we do
-Original Message-
From: Suresh Krishnan [mailto:[EMAIL PROTECTED]
I agree with you that a receiver may process the EH's in any order
except the HBH EH.
No. The receiver MUST process the extension headers in the order they
appear. Please see the following text from RFC2460
-Original Message-
From: Suresh Krishnan [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 20, 2008 4:30 PM
To: Markku Savela
And, if you hit unknown header, there is *NO WAY* to skip
over it. You
have no idea whether it is an extension header (following
the standard
format),
-Original Message-
From: Suresh Krishnan [mailto:[EMAIL PROTECTED]
If this draft wants to bypass that rule:
The goal of the draft is not to make any recommendations to either
receiving end nodes or intermediate nodes. The goal of the
draft is to
propose a standard extension
-Original Message-
From: Suresh Krishnan [mailto:[EMAIL PROTECTED]
I do see what you mean. Is this the text you were referring
to that made
you uncomfortable?
This document proposes that all IPv6 extension headers be
encoded in
a consistent TLV format so that it is
-Original Message-
From: Markku Savela [mailto:[EMAIL PROTECTED]
The part of draft, that proposes new extension headers follow the TLV
format is OK. Although, I have always assumed that this was already
implicit or even specified. If not, the draft could be seen as an
emendation to
-Original Message-
From: Vishwas Manral [mailto:[EMAIL PROTECTED]
How can a node know it is a new Extension Header (which follows the
format as specified in the new draft) or another upper layer protocol?
There can be two unknowns - unknown upper layer protocol and unknown
EH.
-Original Message-
From: Dunn, Jeffrey H. [mailto:[EMAIL PROTECTED]
I believe that the real issue is the following:
1. Simply authenticating the message contents, as in the case of
ESP-NULL, does not authenticate the sender.
2. Since ESP-NULL does not provide confidentiality,
-Original Message-
From: Sean Lawless [mailto:[EMAIL PROTECTED]
Kevin and many others against mandating (MUST) for IPSec have a valid
point. Many sensors and other potential IPv6 nodes do not have the
hardware resources to support IPSec, or those resources are
better spent
at
-Original Message-
From: Bound, Jim [mailto:[EMAIL PROTECTED]
On the
issue of e2e encrypt/decrypt except the header there are
those for many reasons will not want to permit this for the
reasons you state is my experience.
I may we way off base, but when I read this, all I can
-Original Message-
From: Pekka Savola [mailto:[EMAIL PROTECTED]
NIST's goal was probably, some implementations on the field just
support static and maybe RIPng. We want to mandate something more
scalable, and OSPFv3 is as good an option as any.
I completely agree. And, if the
-Original Message-
From: Vishwas Manral [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 26, 2008 10:58 AM
To: Manfredi, Albert E
Cc: Pekka Savola; ipv6@ietf.org
Subject: Re: Updates to Node Requirements-bis (UNCLASSIFIED)
Hi Albert,
Instead of mandating every protocol, would
-Original Message-
From: Ed Jankiewicz [mailto:[EMAIL PROTECTED]
That is a good point, does IPsec depend on unanimous support? We
struggled with this in the DoD Profiles. Our rationale for
making IPsec
mandatory (except at the moment for some simple appliances)
was that for
-Original Message-
From: Duncan, Richard J CTR DISA JITC
John-
I can give you the 2 documents:
DoD IPv6 Standards Profile, Version 2:
http://jitc.fhu.disa.mil/apl/ipv6/pdf/disr_ipv6_product_profile_v2.pdf
US Government IPv6 Profile Version 1, Draft 2:
-Original Message-
From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
To: Manfredi, Albert E
I would agree that someone should reconcile, or at least
identify, all
the differences, although I don't know that it should be the IETF.
The IETF's job is to make the Internet work
]
Sent: Friday, February 01, 2008 8:09 AM
To: Manfredi, Albert E
Cc: ipv6@ietf.org
Subject: RE: Checksum in IPv6 header
I am not seeing the problem.
The non-secure IPv6 link you're mentioning is a virtual
link, over a real physical
From: Alex Conta [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 31, 2008 12:50 PM
To: 'Rahim Choudhary'; Templin, Fred L; 'Fred Baker'
Cc: ipv6@ietf.org
Subject: RE: Checksum in IPv6 header
-Original Message-
From: Suresh Krishnan [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 05, 2007 5:05 PM
To: Brian Dickson; Iljitsch van Beijnum
Cc: IETF IPv6 Mailing List
Subject: RE: Stupid ULA discussion
Hi Brian,
And to point out the existence of a suitable
Perhaps this was covered in the RH0 deprecation discussions and I missed
it. How will jumbograms be coded in the IPv6 header if RH0 is rejected,
at some point? Since both a length of 0 bytes and RH0 are expected in
the IPv6 header, to indicate jumbogram (RFC 2675).
Bert
-Original Message-
From: James Carlson [mailto:[EMAIL PROTECTED]
I don't agree that those OSes screw up royally. They are, in fact,
doing what their users *tell* them to do.
If an application binds the source address on Subnet B and then sends
a packet with a destination address
-Original Message-
From: Fred Baker [mailto:[EMAIL PROTECTED]
Sent: Monday, November 12, 2007 8:40 AM
To: marcelo bagnulo braun
Cc: IETF IPv6 Mailing List
Subject: Re:
draft-baker-6man-multiprefix-default-route-00.txt is a newdraft
On Nov 12, 2007, at 12:27 PM, marcelo bagnulo
-Original Message-
From: Jeroen Massar [mailto:[EMAIL PROTECTED]
Manfredi, Albert E wrote:
-Original Message-
From: Arnaud Ebalard [mailto:[EMAIL PROTECTED]
Can you please give me in one or two sentences (i.e.
little effort) the specific purpose/use those people
-Original Message-
From: Arnaud Ebalard [mailto:[EMAIL PROTECTED]
Can you please give me in one or two sentences (i.e.
little effort) the specific purpose/use those people have.
This is the only thing i keep asking for on the list and
no one has still answered with specific use.
-Original Message-
From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
On 2007-08-30 02:08, Thomas Narten wrote:
Sorry to interrupt, but I'd suggest that working on a new
RH design is
mostly a waste of time at this point.
Can we please _first_ identify a user/customer for a
-Original Message-
From: TJ [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 29, 2007 6:17 PM
To: IPv6 WG
Subject: RE: New Routing Header!!!
So why don't ISPs simply filter out any RH0 traffic
from their edge gateways, and leave it at that?
Rough guess - ISPs don't like the prospect
1 - 100 of 144 matches
Mail list logo
