I thought we had been over this ground and come up with text you found
acceptable? Did I inadvertently change it, or are you just bringing up the
topic again?
On Sep 2, 2013, at 5:16 PM, Brian E Carpenter
wrote:
> Hi,
>
> The IPv6 flow label is defined by RFC 6437. This isn't just an editori
On Aug 14, 2013, at 2:27 PM, Brian E Carpenter
wrote:
>> * Section 3:
>>> To the extent that each method of IID creation specifies the values
>>> of the "u" and "g" bits, and that each new method is carefully
>>> designed in the light of its predecessors, these bits tend to reduce
>>> the ch
I mostly agree. Some fuzz.
On Jul 30, 2013, at 10:34 AM, Ronald Bonica
wrote:
> Folks,
>
> I think that we heard the following at yesterday's meeting:
>
> Title
> =
> The document should be renamed "IPv6 Fragmentation Considered Ineffective"
"Ineffective" has to be modified by "for some
At the mike a moment ago, I referred to an existing formal definition of
"deprecate". For the record, the reference is to RFC 1158, which reads:
3.1. Deprecated Objects
In order to better prepare implementors for future changes in the
MIB, a new term "deprecated" may be used when describi
On Jun 26, 2013, at 11:39 PM, Marc Lampo
mailto:marc.lampo.i...@gmail.com>> wrote:
Would we think about deprecating the use of fragmentation fields in the IPv4
header and recommending they MUST always be set to 0 ?
I would say "no", for the same reasons that I think it's a poor idea in IPv6.
On Jun 26, 2013, at 4:52 PM, Fernando Gont
wrote:
> On 06/26/2013 12:56 PM, Mark ZZZ Smith wrote:
>>
>> One of the issues with conventional ICMP PTB based PMTUD is the
>> default rate limits on ICMP messages on broadband routers with PPPoE
>> subscribers i.e. dumbell [1500][1492][1500] MTUs, s
On Jun 26, 2013, at 3:56 AM, Mark ZZZ Smith wrote:
> - Original Message -
>> From: Fred Baker (fred)
>> To: Randy Bush
>> Cc: IPv6 Deployment Prevention
>> Sent: Wednesday, 26 June 2013 1:30 PM
>> Subject: Re: New Version Notification for
>>
On Jun 25, 2013, at 12:42 PM, Randy Bush wrote:
> in reality, you can not count on pmtud working
One of these days, I'll understand why Linux/FreeBSD/Windows/Apple don't
implement RFC 4821.
IETF IPv6 working group mailing li
The case usually mentioned is in firewalls, under a policy that targets
reassembly attacks. If system A sends a fragment but not all fragments of a
message to system B, some of system B's resources are consumed until a
timeout-or-something occurs. Dropping fragments prevents that.
Personally, I
On Jun 24, 2013, at 5:49 PM, Sheng Jiang wrote:
> However, I personally think we would found deprecating fragmentation in whole
> IPv6 protocol might be too dramatic and had too many incompatible issues
> after carefully and neutral analysis.
That is consistent with my view, for reasons I hav
On Jun 24, 2013, at 12:45 AM, Tore Anderson wrote:
> * Fred Baker (fred)
>
>> On Jun 22, 2013, at 2:29 AM, Tore Anderson wrote:
>>> - When a SIIT translator receives an IPv4 packet with DF=0 that
>>> would result in an IPv6 packet that would exceed the IPv6 l
On Jun 22, 2013, at 2:29 AM, Tore Anderson wrote:
> - When a SIIT translator receives an IPv4 packet with DF=0 that would
> result in an IPv6 packet that would exceed the IPv6 link MTU, it will
> split the original packet into IPv6 fragments.
It *could* fragment the IPv4 packet and send it in tw
I suppose I'm the contrarian, but this draft gives me some heartburn
surrounding the robustness principle. Yes, TCP MSS generally limits the use of
fragmentation for IPv6. We don't have a counterpart to MSS for UDP, and others
have noted that OSPF etc may have issues.
Thinking hypothetically,
that and say that this is a different use case.
> Regards
> Brian
>
> On 03/05/2013 09:24, Fred Baker (fred) wrote:
>> On May 2, 2013, at 2:17 PM, Brian E Carpenter
>> wrote:
>>
>>> That's why I think the way out is to use the wiggle room mentione
On May 2, 2013, at 2:17 PM, Brian E Carpenter
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
new flow - every new TCP session, in the most extreme reading of that
On May 2, 2013, at 1:12 PM, Brian E Carpenter
wrote:
>> Any such method MUST
>> NOT disturb nodes taking part in the stateless scenario just
>> described. Thus, any node that sets flow label values according to a
>> stateful scheme MUST choose labels that conform to Section 3 of this
>>
On Dec 20, 2012, at 9:35 AM, Rémi Després wrote:
>> The comment Brian is making refers to IP's requirements, which are that the
>> IID used in a subnet by an interface must be unique within that subnet.
>
> This is a clear requirement, on which I think we all agree.
>
> It is worth noting here
On Dec 20, 2012, at 12:54 AM, Rémi Després wrote:
> Interface addresses at the link layer are specified by IEEE to be universally
> unique.
Yes, and EIU-64 is one of several seeds from which an IID can be derived. It's
not the only one. The fact that an underlying technology provides an
inte
On Dec 19, 2012, at 1:24 AM, Rémi Després wrote:
> (c) In the Identifier-Locator Network Protocol of RFC 6741 (ILNP), the IEEE
> semantic of g=0 applies to unicast addresses (section 3). Besides, "ILNP uses
> IPv6 multicast for ILNPv6", which implies that addresses are not concerned
> with IID
defined, U=1, G=1 can not occur in the normal course of events.
> We can ignore it. we can define it. We can reserve it and thn sit on our
> hands. But given taht we have text already, and that text is ambiguous, it
> seems like we should at least clear up the ambiguity.
>
>
Why do we care about u and g in the first place? Is there code in an IPv6
router or host that interprets them?
On Dec 18, 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 amb
You may certainly file an internet draft with your ideas. You will want to read
about what an Internet Draft is and how to file one.
http://www.ietf.org/id-info/
Filing an Internet Draft does not imply consensus around the specification, and
you will need to build that consensus. You will want
On Aug 14, 2012, at 4:41 AM, Francis Dupont wrote:
> I remember (perhaps the first detected duplicate?) a very early occurrence
> before 1995 with a DEC box using a cloned full config. Same Decnet address
> so same MAC address so same IPv6 link-local address…
Where I'm coming from in this is an
On Aug 11, 2012, at 12:04 PM, Ole Trøan wrote:
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 autoconfiguration,
and uses RFC
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 autoconfiguration, and
>> uses RFC
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 autoconfiguration, and uses
RFC 4861's duplicate address detection mechanism.
My question is: what happen
On Jul 18, 2012, at 1:36 PM, Fernando Gont wrote:
> Folks,
>
> There's one issue that came up during my recent exchange with Suresh on
> which I'd like others (including Suresh) to weigh in:
>
> Since first-fragments that fail to include the entire header chain will
> be illegal, I think it wou
On Apr 14, 2012, at 7:23 PM, Fernando Gont wrote:
> That said, a more general question would be: should we include the (numeric)
> interface index rather than e.g. a hardware-specific I-D?
Hmmm. I would tend to think that's a small positive integer, which isn't all
that unique. Are you thinkin
On Apr 14, 2012, at 5:07 PM, Christian Huitema wrote:
>> As I read it, section three item one calls for the use of the EUI-64 in use
>> on the interface, which presumes that the
>> interface is an IEEE 802 LAN. There are other interface types. I'd like to
>> see that widened to a number *such*
On Apr 14, 2012, at 4:20 PM, Christian Huitema wrote:
> 3) Privacy: the number should vary over time, to make it harder for Internet
> services to correlate sessions started by the same host.
> 4) Stability: the number should remain stable over time, so administrators
> can more easily manage wh
Speaking for myself, I don't understand the fixation on MAC addresses. Yes,
Ethernet and other IEEE standards are widely used. They are not used on serial
links (we seem to mostly use /127 prefixes for that), they are not used on the
air side of 3G etc, and so on. And as a matter of fact, for al
On Mar 30, 2012, at 9:20 PM, Fernando Gont wrote:
> If the regime controls the local-link, then as far as address-tracking is
> concerned, you're toast. -- They could sniff the network and log the
> address->MAC mappings, have RAs require you to do DHCPv6 and then have DHCPv6
> assign you a co
On Mar 29, 2012, at 2:52 PM, Iljitsch van Beijnum wrote:
> On 29 Mar 2012, at 14:15 , Brian Haberman wrote:
>
>> It is not an assumption, it is stately quite clearly in the Scoped
>> Addressing Architecture (RFC 4007). From Section 5 :
>
>> A zone of a given scope (less than global) falls
On Mar 29, 2012, at 12:02 PM, Iljitsch van Beijnum wrote:
> On 28 Mar 2012, at 12:08 , Fred Baker wrote:
>
>>> I haven't read the spec yet, but isn't PCP supposed to work in the service
>>> provider run NAT64/CGN case, too? In that case, the multicasts need
On Mar 22, 2012, at 11:00 AM, Anders Brandt wrote:
> As a branch of the discussion [homenet] ULA scope
> [draft-ietf-6man-rfc3484-revise-05.txt],
> I would like some clear explanation of the actual issues related to routing
> between hosts in ULA subnets.
> Some people seems to be concerned for
On Jan 6, 2012, at 8:26 PM, Fernando Gont wrote:
> I just said that PLPMTU has a long convergence time
Frankly, that sounds like an implementation issue. If we're willing to set
IW=10, it seems like one should be able to send the initial burst, or at least
the first retransmission, with messag
Just so everyone's on the same page, although this draft originally targets
v6ops, it is going to be looked at in 6man (per the 6man chairs). That's a
discussion you may want to have in 6man.
On Oct 11, 2011, at 11:39 AM, Hemant Singh (shemant) wrote:
> Lorenzo,
>
> I realized that the loopin
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, i.e.
> watch the DHCPv6 messages go past and pre
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 advantage
>> of IPv6's large address space and tha
On Jul 15, 2011, at 10:35 AM, Philip Homburg wrote:
> I could be wrong, but the impression I got from the various ops lists is that
> the way you deal with this attack is to avoid using RFC-4862 and/or RFC-4861.
I can imagine using DHCPv6 instead of SLAAC (RFC 4862 and the RS/RA component
of RF
On Jul 15, 2011, at 6:31 AM, RJ Atkinson wrote:
> I apologise for being unclear. The document I was trying to propose in the
> quoted text above was NOT about protocol changes, but instead would focus on
> extant mitigations -- so the document I was proposing would more obviously
> seem to fi
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 in the wild?
---
On Jun 22, 2011, at 4:15 AM, Mikael Abrahamsson wrote:
> Just the same way that it's "obvious" that anyone can spoof RAs on a flat L2
> lan, it's "obvious" that fragmentation and headers can make parsing actual
> payload harder and needs to be handled. These two "obvious" have historically
> b
On Jun 14, 2011, at 8:30 AM, Suresh Krishnan wrote:
> RFC5157 IPv6 Implications for Network Scanning
Personally, I think that RFC has been overtaken by events. Network scans have
been reported in the wild.
IETF IPv6 working gr
BTW, in case it wasn't clear, I think the IETF should do that architecture.
On Jun 4, 2011, at 11:10 PM, Fred Baker wrote:
>
> On Jun 4, 2011, at 9:53 AM, Stephen Farrell wrote:
>
>> I think we'd like to respond to them that that's great,
>> and we'l
On Jun 4, 2011, at 9:53 AM, Stephen Farrell wrote:
> I think we'd like to respond to them that that's great,
> and we'll be interested in their results, but can they
> *please* come back to us before saying something should
> be changed so's we can talk about it.
That seems like a reasonable pro
On May 30, 2011, at 3:57 PM, Ray Hunter wrote:
> This is danger of going off topic I know (maybe it should go in v6ops), but
> it's important to me to be able to understand the consequences of the
> discussion, so please bear with me. It's definitely going to become an
> operational FAQ, unles
On May 30, 2011, at 2:12 PM, Brian E Carpenter wrote:
> For example, setting the DSCP *as a function of
> the source address* makes me cringe. We're going to have to get used to
> the fact that IP addresses are not constants.
good grief. The only reasonable use of a DSCP is to identify the set o
On May 9, 2011, at 5:15 PM, Thomas Narten wrote:
> When are we going to start counting cell phones, tablets and other electronic
> devices?
When they start implementing IPv6 at all...
IETF IPv6 working group mailing list
ipv6@
Dumb question. Is there an attack in your proposal? For example, if I were to
mis-identify my RA as coming from an end-host, could I now bypass RA-Guard?
On Mar 5, 2011, at 2:56 PM, Mark Smith wrote:
> On Sun, 06 Mar 2011 08:40:40 +1300
> Brian E Carpenter wrote:
>
>> Any router that forwards
On Mar 4, 2011, at 6:59 PM, Yu Hua bing wrote:
>>RFC4291
> > Link-Local addresses are for use on a single link. Link-Local
> > addresses have the following format:
>
>| 10 |
>| bits| 54 bits | 64 bits |
>+--+-
On Jan 21, 2011, at 11:25 AM, Brian E Carpenter wrote:
> We seem to have agreed that the primary purpose of the flow label is
> to facilitate load balancing, which is a statistical process.
except when it is not a statistical process.
---
On Jan 11, 2011, at 10:14 AM, Shane Amante wrote:
> What causes pain and/or worry to us operators is when someone launches a
> large *individual* "macro-flow"[1] at the network that start to represent a
> decent fraction of the overall capacity of a physical component-link
> underlying a LAG an
On Jan 11, 2011, at 9:10 AM, Shane Amante wrote:
> It's probably better to say that a hash algorithm works well where
> individual, long-lived flows (regardless of traffic type) are a small-ish
> fraction of the physical BW of any individual component-link in a LAG or ECMP
> group. It's when
On Jan 10, 2011, at 11:26 AM, Christian Huitema wrote:
> Fred wrote:
>
>> Note that I am in favor of suggesting that the Flow Label be included in the
>> hash when doing load balancing. It is a no brainer. At worst, it is a no op.
>> But it certainly is never better to exclude it.
>
> Have yo
On Jan 9, 2011, at 7:05 PM, Steven Blake wrote:
> The network doesn't control port numbers, so his argument obviously doesn't
> apply to ECMP or LAG.
There are more than two common uses of load balancing. ECMP is a side effect of
routing; we decide to multipath route when we know of two next h
On Jan 9, 2011, at 5:45 PM, Brian E Carpenter wrote:
> I'm confused. We've been talking for months about recommending
> pseudo-random flow label values as inputs to hash functions,
> precisely to allow scaleable and stateless load balancing and ECMP.
>
> I completely agree that per-flow state do
this time around. Of course, the WG can decide otherwise, but
>> embedding the use case(s) in the protocol spec does lengthen
>> the discussion considerably.
>>
>> Regards
>> Brian
>>
>> On 2010-12-15 14:26, Fred Baker wrote:
>>> So you'
On Dec 17, 2010, at 4:41 AM, Thomas Narten wrote:
> Fred Baker writes:
>
>> When we advance a routing protocol to Proposed Standard, for reasons
>> related to ancient IESG history related to routing, we generally
>> require a test report that shows interoperable i
orts and
> just need to recast them as a draft and highlight the v6man draft tests)
>
> Don
>
>
> -----Original Message-
> From: Fred Baker [mailto:f...@cisco.com]
> Sent: Thursday, December 16, 2010 3:56 PM
> To: d.stu...@att.net
> Cc: 'Brian Haberman&#x
move forward in the WG. We
> think they are essential to implementing non-storing ROLL RPL. By the way,
> our target deployment is for Smart Metering applications in the home area
> network. I added Fred Baker who chairs the Smart Power group who is aware
> of our work.
>
&
So you're really really not interested in discussing the one use case that
people have actually talked about wanting, which has to do with load sharing?
What use case are you addressing?
On Dec 14, 2010, at 5:14 PM, Brian E Carpenter wrote:
> Hi,
>
> The authors have received one off-list comm
On Oct 23, 2010, at 3:23 PM, Brian E Carpenter wrote:
> Lower, at the moment, since we have people very interested in the flow label
> for ECMP/LAG.
well, yes, but 6man does everything in its power to prevent it from being
useful for that. You said that after 15-20 years of history with IPv6 t
On Oct 15, 2010, at 3:40 PM, Brian E Carpenter wrote:
>> I'd think that recommending having an option that disables unattended
>> automatic update would address this concern. Managed service providers,
>> since they'd be controlling the CPE, could go in and disable unattended
>> automatic upd
So that might use the mesh network header part of the 6lowpan header?
On Sep 15, 2010, at 12:06 AM, Carsten Bormann wrote:
>> Has anybody discussed adding a header with just the 3 bytes you need
>> *before* the IP header?
>
> Yes. Ever since you proposed pretty much that at a previous IETF mee
On Sep 12, 2010, at 4:01 AM, Mark Smith wrote:
> What I said was, and I'll highlight the key word,
>
> "Layer 2 devices inspecting traffic isn't *architecturally* acceptable
> because it's a layer violation"
>
> The best place to fix IPv6 issues in in IPv6.
well, yes, but...
let me give you
On Sep 11, 2010, at 3:06 PM, Mikael Abrahamsson wrote:
> On Sat, 11 Sep 2010, Mark Smith wrote:
>
>> How would you solve the problem? If you give end-nodes the ability to
>
> Exactly the way it has been done for IPv4 with the mechanisms I've given
> examples of before. L2 devices look at DHCPv
On Sep 11, 2010, at 2:00 PM, Randy Bush wrote:
>>> So the onus is on operators to turn their good business reasons into
>>> engineering problems, eg as a requirements RFC, that the IETF will
>>> then solve.
>
> no. it is the duty of operators to turn their business plans into
> operational prac
On Sep 11, 2010, at 1:06 AM, t.petch wrote:
> So the onus is on operators to turn their good business reasons into
> engineering problems, eg as a requirements RFC, that the IETF will then solve.
Thanks. I gather the operators have gotten a lot of bashing from IETF
participants in the past; I'm
On Sep 10, 2010, at 6:44 AM, Brian E Carpenter wrote:
>> SLAAC is fine for home networks (and some enterprise networks).
>
> That's exactly what (IMHO) we need to preserve, which has the side effect
> that it's going to be the default mechanism for IPv6 nodes shipped out into
> the SOHO marke
On Sep 9, 2010, at 9:48 PM, Mikael Abrahamsson wrote:
> On Thu, 9 Sep 2010, Fred Baker wrote:
>
>> Does that solve all problems? obviously not. It does limit the impact of
>> certain classes of attacks. IP Source Guard, a feature from my company and
>> also from som
On Sep 9, 2010, at 9:48 PM, Mikael Abrahamsson wrote:
> On Thu, 9 Sep 2010, Fred Baker wrote:
>> Does that solve all problems? obviously not. It does limit the impact of
>> certain classes of attacks. IP Source Guard, a feature from my company and
>> also from some other
On Sep 9, 2010, at 7:29 PM, Mark Smith wrote:
> SAVI and things like SeND are beneficial halfway measures, avoiding full
> quarantining.
I would generally agree.
Just like being at a cocktail party, there is no way to know just how looped a
neighbor is or how it will behave in that condition.
Brian:
Joel reminds me, in private email, that nobody seems to be commenting on you
original question, which has to do with covert channels and whether that should
affect the discussion of flow labels.
Here's a covert channel for you. I was at an agency last year that uses
specialized mail ser
On Sep 8, 2010, at 1:02 PM, Christopher Morrow wrote:
> this all gets 'crazy', I suppose if we wanted to route on flow-label
> not destination-ip-address this might happen, but ... that seems
> 'crazy' as I said before :) since not everyone would be using the
> flow-label (maybe) and inconsistent
On Sep 8, 2010, at 12:38 PM, Brian E Carpenter wrote:
> The idea is that someone
> figures out what flow label values will screw you
In the model I proposed, the network the packet is in, as with the DSCP, is in
control of the flow label value.
--
On Sep 8, 2010, at 11:44 AM, Christopher Morrow wrote:
> On Tue, Sep 7, 2010 at 9:18 PM, Brian E Carpenter
>> If this is correct, it is futile to assert that the flow label
>> MUST be delivered unchanged to the destination, because we
>> cannot rely on this in the real world.
>>
Anything that c
On Aug 23, 2010, at 2:53 PM, Manfredi, Albert E wrote:
> 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 see
On Aug 23, 2010, at 1:15 PM, Joel Jaeggli wrote:
> 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 probl
On Aug 13, 2010, at 3:59 PM, Hemant Singh (shemant) wrote:
> So what text do we add to the Sri document to exclude MLDv2 protocol
> from their proposal?
I would recommend that you explain the point (why would it be inappropriate for
an MLDv2 multicast to be sent to a unicast MAC address if th
On Aug 10, 2010, at 11:21 AM, Carsten Bormann wrote:
> OK, I'm not talking of "host" as in originates or terminates traffic, but
> "host" in the sense of "does not participate in routing".
> It appears there is no such thing inside a RPL world then.
A RPL or Manet world doesn't have the 1970's-
I would find that surprising. There are ample cases where the originator of a
high data rate flow (sensor data from a radio telescope to a number cruncher,
to pick one example) might want to use the flow label to send data from one
session down multiple paths. Multi-path TCP would be another exa
On Aug 4, 2010, at 5:56 PM, Juergen Schoenwaelder wrote:
> On Wed, Aug 04, 2010 at 05:34:39PM +0200, Fred Baker wrote:
>
>> I think this is a mis-use of AUTH48; the working group has
>> considered the draft and said what it wanted to say, and at this
>> point the
I think this is a mis-use of AUTH48; the working group has considered the draft
and said what it wanted to say, and at this point the RFC Editor is asking you
whether they changed the intent of the draft in the editing process or whether
perhaps your address has changed. Changing the draft in a
intellectually, end to end signaling might make sense. If so, it belongs in the
end-to-end headers. More importantly, who's using it?
If using it end to end or end-to-network isn't being useful, either find a use,
or deprecate it.
On Aug 4, 2010, at 10:00 AM, Randy Bush wrote:
> The flow-l
On Aug 4, 2010, at 5:48 AM, Brian E Carpenter wrote:
>>> The flow-label can belong either to the network -or- to the host(s): pick
>>> one[1].
++
Frankly, much of this discussion has been about dividing the flow label into
two parts, one for the host to use to instruct the network on what it
essage. One may also note
> that MLD is used by ND as specified in RFC 4862 and RFC 4861.
>
> So what text do we add to the Sri document to exclude MLDv2 protocol
> from their proposal?
>
> Hemant
>
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:i
The other truly obvious use case, standard in IPv4 ARP, is when refreshing an
ARP/ND entry. You already know the MAC address, the question is whether the guy
is still there or not. In IPv4, we (pretty much everybody) unicast the ARP
request to the most recent MAC address; it either responds or d
e link-layer
> header, withstanding all other validity considerations as
> specified in the relevant IPv6 standards specifications.”
>
> “An IPv6 sender node MAY choose to transmit an IPv6 multicast
> message as a link-layer unicast message.”
>
> - Wes
>
> On 7/31/10 1:5
This is to initiate a two week working group last call of
draft-gundavelli-v6ops-l2-unicast. Please read it now. If you find nits
(spelling errors, minor suggested wording changes, etc), comment to the
authors; if you find greater issues, such as disagreeing with a statement or
finding addition
On Jul 28, 2010, at 1:58 PM, Yong Lucy wrote:
> What is flow label usage?
>
> IMO: it enforces that a set of packets with the same flow label has to be
> carried through the networks in the same path or belong to the same
> application at host. Is that correct? Is there other usage of flow labe
draft-troan-multihoming-without-nat66 will be discussed in v6ops at the IETF
meeting, but is in my opinion also relevant to 6man. I would invite 6man
attendance at the discussion.
IETF IPv6 working group mailing list
ipv6@ietf.
On May 5, 2010, at 2:18 AM, Tina TSOU wrote:
> [Tina: How about keeping the previous flow label in the option of IPv6 Header
> for restoral? When the exit router receives the packet, it uses the previous
> option to replace the existing one to implement restoral.]
Yes, one could do that. It lo
s.
>
> yours,
> Joel
>
> Fred Baker wrote:
>> On Apr 22, 2010, at 2:40 PM, Brian E Carpenter wrote:
>>> However, consider that the flow label is a forgeable field, not
>>> protected by any checksum (including IPSEC).
>>> So maybe mutability is in
On Apr 22, 2010, at 2:40 PM, Brian E Carpenter wrote:
> However, consider that the flow label is a forgeable field, not
> protected by any checksum (including IPSEC).
> So maybe mutability is in fact the only way to make it safe to
> use across domain boundaries?
Interesting. I had it in my he
personally, I would prefer to see it *mutable*, and undefined. Given that there
are many host implementations out there, I could imagine difficulties getting
any specific specification (such as a hash) widely deployed in a finite amount
of time. However, if a network could use it to identify an
"we didn't pay enough attention" is a very kind way to put it. The entire SNMP
exercise was about monitoring; those like me who tried to make things writable
pushed rocks uphill politically. That, and the experience of trying to make
event triggered management rather than poll-driven management,
he RFC 3972 doesn't apply to the 64-bits of the Link-local addresses, but it
> applies to 64-bit of the addresses configured via DHCPv6
> and/or stateless auto-conf RFCs 3315, 4862?
>
> Regards,
> Parav Pandit
>
> --- On Thu, 4/15/10, Fred Baker wrote:
>
>>
There has been some water that passed under that bridge. They not only come
from MAC addresses, but from random number generators and cryptographic
algorithms - and can simply be numbers assigned by administrators.
In addition to
2464 Transmission of IPv6 Packets over Ethernet Networks. M. Craw
On Jan 15, 2010, at 8:07 AM, Dan Wing wrote:
Missing a Pro that I consider significant:
- Users will no longer experience multi-second connection delays due
to IPv6's address selection. This means more users will
leave IPv6 enabled.
To me, that's the big issue. The point is to find
1 - 100 of 196 matches
Mail list logo
