https://labs.ripe.net/Members/emileaben/ripe-atlas-packet-size-matters
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> I don't quite understand what he is testing?
> just sending large packets?
> or as the subject says, fragmented packets?
> or path MTU discovery?
>> This is what I see for various IPv6 payloads (large ICMPv6 echo
>> requests)
beyond that, emile would have to speak for himself
randy
---
---
Message-ID: <5223a4ce.9090...@ripe.net>
Date: Sun, 01 Sep 2013 22:34:22 +0200
From: Emile Aben
To: Randy Bush
CC: na...@nanog.org
Subject: Re: IP Fragmentation - Not reliable over the Internet?
On 31/08/2013 13:13, Randy Bush wrote:
> could you please test with ipv6?
This is what
http://mailman.nanog.org/pipermail/nanog/2013-August/060709.html
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--
>> (I would actually suggest that in a pseudo-random method, now that we
>> are clear that the bits have no meaning, it would be best to use them to
>> provide two more bits of entropy rather than giving them fixed values.)
>
> Good grief. If the bits don't mean anything - and they never did,
> si
> There are still many places where I come from where operators do not
> support native IPv6 and people need to rely in tunnels to start trying
> IPv6.
in this case. ipv6 is *inside* the tunnel
so, unless you are one of the sickies who think ipv4 inside mpls inside
ipv6 inside ipv4 inside gre in
> I think the draft (especially since is headed toward BCP) should also
> include a message that PMTUD is useful and should not be blocked by
> routers/firewalls/middleboxes/etc.
i might say SHOULD NOT
but i would also be clear that the operator/user will find that it is
often the case that PMTUD
> How about "IPv6 Fragmentation Considered Ineffective for End-to-end
> Transport"?
ipv6 fragmentation does not work reliably on the internet and is highly
unlikely to do so in your career's lifetime.
yes, pmtud is the right thing, but it can not be relied on. get over
it.
> Thinking a little m
> A example of deprecation that is close to what we are discussing
> regarding fragmentation can be found in:
>
>This document formally deprecates the IPv6 site-local unicast prefix
>defined in [RFC3513], i.e., 111011 binary or FEC0::/10. The
>special behavior of this prefix MUST
> At the mike a moment ago, I referred to an existing formal definition
> of "deprecate".
welll, you keep saying it is a formal definition, implying that it
applies to all uses of the term. but, in fact, the reference is merely
how it is used in some snmp glorp.
otoh, the draft under abuse, coul
> This message starts a two week 6MAN Working Group on advancing:
>
> Title : Significance of IPv6 Interface Identifiers
> Author(s) : Brian Carpenter
> Sheng Jiang
> Filename: draft-ietf-6man-ug-01.txt
> Pages : 1
> Not all deployed links are built out of wired/wireless
> Ethernet or SONET. The assumption that everything is either
> Ethernet or SONET (or perhaps WDM) is a bit of a "First
> World" assumption and puts lesser-developed countries/regions
> at a significant disadvantage for Internet access.
m
>> in reality, you can not count on pmtud working
>
> In reality, you can not count on the Internet working. Despite that,
> it mostly works, most everywhere you need it to work, most of the
> time. Only occasionally, does one encounter failure.
unlike pmtud
> One of these days, I'll understan
>> 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.
router code has also been problematic. a mess. but i do not harbor the
fantasy that it will be fixed. i might wish it, but i don't expect it.
randy
> while the practical global MTU for IPv4 remains larger, then I would
> say that pretty much serves as a guarantee that the transition from
> IPv4 to IPv6 cannot ever be successful.
i had a semi-discussion with olaf kolkman, who was saying dnssec and
ipv6 were slow and steady transitions. i poin
> with my user hat on, I'm not paying my ISP to drop my packets. ;-)
then you don't believe in qos, eh? 's ok. neither do i. :)
> I understand why an ISP would filter ISPs towards its own
> infrastructure, but what would be the reasoning for filtering
> fragments that it transits?
reasoning?
>>> If it's a statement of fact, it shouldn't use RFC 2119 language. It
>>> should simply state the truth: "Network operators might filter IPv6
>>> fragments."
>> s/might/do/
> would you be able to answer why and where?
perceived, rightly or wrongly, as an attack vector. they do similarly
for v4.
> If it's a statement of fact, it shouldn't use RFC 2119 language. It
> should simply state the truth: "Network operators might filter IPv6
> fragments."
s/might/do/
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrati
> FWIW, I don't think anyone has proposed "if the chain is larger than X,
> then drop".
i am saying that i am telling my neighbor that, if the header length is
larger than X, it is likely that their packet will not propagate. it's
an ops bcp statement, not a statement of ipv6 protocol definition.
> it takes a while for equipment to get upgraded everywhere.
it's pretty quick, no more than a decade or two
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo
> 2008? RH0?
> Dudes, have we not moved beyond this?
Jun 10 15:03:54 psg kernel: IPFW2: IPV6 - Unknown Extension Header(64), ext_hd=0
welcome to the operational internet
randy
IETF IPv6 working group mailing list
ipv6@ietf
> 53 = not good. Just because some people are re-using old hardware
> cards they had hanging around does not mean everyone has to go along
> with it.
you are completely correct. you are welcome to send 10gb of headers.
just do not be surprised when they do not make it to the destination.
welcome
i think of it as a somewhat arbitrary operational (not protocol, i.e.
does not belong in this wg) best common practice. just as i warn my
customer that they can announce a /64 to me, and can pay me to announce
it to my peers, that my peers will not listen to it or propagate it.
similarly, you mig
> I too would be in favor of using ULAs for this in-vehicle purpose.
it would be very appropriate, as in vehicles, there is always a
probability of collision.
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrati
>> for more assurance of such wonderful properties, and no
>> probabilities, you may want to check out ipv6 global address space
> Agreed, this is probably even a better choice, however,
> some manufacturers do not want to pay for non-routable
> IPv6 global address space and depending on the number
> Yes, I know in practice they do leak, that's why I wrote "should". My
> statement was a little bit imprecise - I apologize. No leakage wasn't
> actually my point rather than internal use only. So no matter which
> kind of addresses you employ for "internal use" only, they may
> accidentally le
> This is sufficient for the onboard communication network, which was
> the problem we addressed. ULAs are a good match, since these addresses
> should not leak.
and rfc1918 should not leak
randy
IETF IPv6 working group mailing
folk, can we stop beating the horse? everyone but the horse knows it is
dead. and the bits of spattered horse are consuming significant energy
better spent on productive work.
randy
IETF IPv6 working group mailing list
ipv6@iet
> In scenarios where privacy matters a lot, if our default policy is
> "no privacy", those users "opting in" for privacy would be flagged
> as "suspicious" just for the act of "opting in".
and 82.3% would not realize they needed to opt out.
i would think that, in general, across the ietf protocol
>> i know. ipv6 is perfect, widely deployed, and unchangable. i hope
>> we all like v4 nat.
> I can find many reasons to remove the magic from the U and G bits. I
> personally ran into the U/G bit issues in RFC 4380 (Teredo) and RFC
> 6052 (IPv4-embedded IPv6 addresses). In both cases, the design
> To a significant degree Randy, I agree with you in your comment about
> magic bits. If I were designing IPv6 from scratch (counter-factual in
> so may ways at once) I would not do it that way.
>
> But, unless there is an actual problem with the design the IETF has
> adopted, I am reluctant t
>> I am not clear what aspect of the semantics of u==1 and the
>> relationship to EUI-64 is a dead duck. Currently, if you see
>> something with u==1, you know it was made from an EUI-64.
>
> Actually, you don't. You know that it looks as if it was made in
> Modified EUI-64 format, but you don't
> should the interface-id have any encoded meaning?
having spent a decade+ fighting to throw magic bits out of ipv6
addressing (remember tla?), i find this disturbing.
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
Adm
>> "The IID consists of N bits that have no meaning; the only constraint
>
> Hmm.. how would this work with RFC5453 reserved IID space we already
> have for anycast addresses?
is anyone aware of any deployment of the ipv6 invented anycast?
like most ipv6 magic, i think it is ignored and regular
> What, on an IPv6 host or router, cares about the g bit apart from the
> code that uses an EUI-48 or EUI-64 to create an EID? What starts from
> an EID and extracts from it an EUI-64/48 address, or in any other way
> interprets the g flag in an EID?
>
> u and g are a recurring theme. Apart from t
all emailers beware, kohno san is at cisco not juniper these years.
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> Original Text
> -
>(b) Addresses in which the rightmost 64 bits are assigned the
> highest 128 values (i.e., :::ff7f to :::
> ) SHOULD NOT be used as unicast addresses, to avoid
> colliding with reserved subnet anycast addresses
> Sorry i didn't realize that you own this list - my apologies
> If you really have work to do pls disregard my emails instead of
> responding with meaningless emails that are not helping either of
> us...
IETF IPv6 working grou
> If you have links to any previous discussions / blogs on this long
> cold pot, pls point me to them so I can convince myself that both 5375
> and 6164 have same recommendations for /127 (and /128)
go read the discussion on 6164
we do not care what you do in your network. we do care that you bl
> There is clearly two set of recommendations over the same addressing
> scenario which I am only trying to clarify with the IETF community.
no. but please go do whatever you want in your network and stop trying
to stir a long cold pot
randy
--
perhaps we learned some things over time?
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--
have read. support.
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> For example, has any seen any actual duplicate MAC addresses?
they have been rife. discussed on ops lists.
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinf
i have slogged through it and support publication as ps
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> Consider a topology where two routers are connected back to
> back. these link have only a IPv6 link local address.
q: doctor, it hurts when i do that
a: don't do that.
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
> Obviously. An erratum that attempts to reverse a clear WG consensus
> that the person doesn't like is a misuse of the errata system.
that is not exactly what occurred. and blame is not very interesting
anyway. i have asked the rfced if they can do a derattum. others migh
support this if it is
> Next thing you know, I'm going along based on this recollection, I
> look up RFC 5952, and I notice there's now an "errata" associated with
> it. Would that errata be about some grammatical minutiae? Nope. It's
> specifically to switch back to upper case hex representation!
there is a lesson her
>> i beg to differ. i have used the restrictive clause for years exactly
>> as fernando states. if the wg does not adopt, then i may take *my*
>> marbles and go home.
> Thanks for saying it so clearly. I choose to not do that as do many
> others. I allow my contributions to be used by others in
i have scanned and support adoption of the draft as a wg item.
>> My understanding is that this is perfectly compatible with the IETF
>> standards process, as long as this restriction is removed before posting
>> as draft-ietf (for instance, I guess that's why it's allowed in the
>> first place).
> Why me?
because you are the nut case who proposed it
>
> On Tue, Apr 10, 2012 at 4:50 PM, Randy Bush wrote:
>
> > > In my opinion, we can add one more Internet when necessary, then another
> > > one etc.
> > >
> > > We can
> In my opinion, we can add one more Internet when necessary, then another
> one etc.
>
> We can have as many Internets as we need, all different.
> ...
in the words of vince perriello, send code
randy
IETF IPv6 working group m
i scanned draft-hsingh-6man-enhanced-dad-04.txt and it certainly looks
like 6man fodder to me. i would have suggested v6ops until i got to
section 3, which proposes protocol change.
randy
IETF IPv6 working group mailing list
ipv
> This message starts a two week 6MAN Working Group on advancing:
> Title : RFC3627 to Historic status
> as Informational.
support
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www
> Maybe we can start with new names;
>
> ULA-S (Self-assigned) - Statistically unique prefix with local
> algorithmic assignment at no cost, you assign a prefix yourself.
> ULA-R (Registered) - Unique Prefix registered to an Organizations
> through the RIRs, a prefix is assigned to you.
> ULA-M
>> 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 zeros, so :: will
> always be the last element according to RFC 5952. (Unless
it's getting late evening here, and the -00 dreadline approaches. so i
have submitted so that we have something concrete to discuss.
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.i
> There are definitely cases where it can be useful to have a group of
> anycast hosts inside a subnet, e.g., in order to increase robustness
> of services etc.
do you use this in production or test?
randy
IETF IPv6 working grou
could you explain to my why i would want to reach any random router on a
lan? some mey go to florida, others to shinjuku, and one goes to hell
in a handbasket.
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrat
> On Mon, 2011-07-04 at 13:28 +0930, Mark Smith wrote:
>> Perhaps we should wait until IPv6 traffic exceeds IPv4's before
>> deciding. With the trivial amount of use that IPv6 currently has, it
>> makes no sense to say history shows it hasn't been useful and should be
>> deprecated.
rofl. these a
> I'd agree wholeheartedly with deprecating them both! But this draft
> expired some months ago - what are its chances?
i was discouraged by bob from submitting it. dreadine approacheth.
should i?
randy
IETF IPv6 working group
]
Internet-Draft IPv6 Subnet Anycast Deprecated August 2010
Services", BCP 126, RFC 4786, December 2006.
Author's Address
Randy Bush
Internet Initiative Japan, Inc.
5147 Crystal Springs
Bainbridge Island, Washington
>> This starts a 2-week consensus call on adopting:
>> Title : Naming IPv6 address parts
>> Author(s) : L. Donnerhacke, et al.
>> Filename : draft-hartmann-6man-addresspartnaming-01.txt
to be my usual tactful self, i find this an embarrassment. it ranks
right up there with
> Per a previous thread, there are indications that the WG may now be
> willing to recommend that DHCPv6 be a SHOULD for all hosts.
fwiw, there are large broadband providers that provision using dhcpv4
today.
randy
IETF IPv6 w
> I personally would support having DHCP be a SHOULD rather than a
> MAY.
thank you
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
---
> And, keep in mind, one can use abitrary prefixes by turning off
> stateless address autoconfiguration and using DHCPv6.
we wish. there is still the exciting mess of ra.
randy
IETF IPv6 working group mailing list
ipv6@ietf.or
> No. EUI-64 requires 64 bit host id's. 48 bits is from the MAC. How
> would you plan to squeeze blood out of the proverbial turnip?
perhaps going back and reading thomas's message would help dispel this
odd religion.
http://www.ietf.org/mail-archive/web/ipv6/current/msg13461.html
randy
--
> I'd rather get IPv6 deployed in a uniform way first.
try cidr
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--
>>
>> Link local is orthogonal in this topic. This document does not address
>> it.
>
> [WES] Then my recommendation would be to explicitly state this in the
> document. Perhaps something specifying that this document only discusses use
> of /127 for global scope IPv6 space, and link-local /127 l
excuse bad email form. this is an ipad.
randy
On Nov 22, 2010, at 9:27, "George, Wes E [NTK]"
wrote:
> In general, I support advancement of this draft, since it is largely
> documenting an existing practice, but I think that Mark brings up a few
> points that should be incorporated as clarif
excuse bad email form. this is an ipad.
randy
On Nov 22, 2010, at 9:27, "George, Wes E [NTK]"
wrote:
> In general, I support advancement of this draft, since it is largely
> documenting an existing practice, but I think that Mark brings up a few
> points that should be incorporated as clarif
> I agree with the prior comment that the document should explicitly
> state that it obsoletes RFC 3627 and updates RFC 4291.
you missed the discussion about that?
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
Adminis
as a confessed co-author, i susppor this document advancing. i mention
this because there are documents which i have co-authoeed which i did
not support.
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Re
> However, I believe that as far as routing is concerned, IPv6 continues
> to be based on CIDR. There is nothing special about the 64 boundary
> from a routing perspective.
and, to be pedantic but very purposfully specific, a forwarding
perspective
> I'd like to hear from operators as to whether
>> It is not clear to me what your option 2 means (What do you actually
>> mean by "a completion at last").
> It refers to the fact that, as long as the spec of FL's is under a
> menace of being deprecated or changed, no one can reliably plan to use
> it, including for load balancing.
we've gotten
>>> I doubt that any new use of the flow label will be backward
>>> compatible.
>> ok. i give. backward compatible to what?
> With the usage of the flow label as defined by RFC3697.
i have never seen anyone move a packet over an rfc or powerpoint
randy
-
> I doubt that any new use of the flow label will be backward
> compatible.
ok. i give. backward compatible to what?
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailm
> Maybe. But then, waiting for the traffic to increase and the load
> balancing needs to materialize also makes a lot of sense. I am pretty
> sure that 5 or 10 years from now someone will be glad that there are
> unused bits in the header...
folk have been trying to agree/find a use for flow label
> 1. I do think that the justification in the draft for such a major
> change, after 12 years work based on RFC 2460, is weak.
how much do you want for hacking on an unused field, another glorious
pile of second system syndrome, for which dozens of people have tried to
find a use for over a decade
> I think the title should be changed to something like "Line
> Identification Destination Option" as it is proposing to create a new
> destination option and uses tunneling. In other words, it is no
> longer adding line identification to RS messages.
makes sense. but should not be a prereq for
yes
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> e.g., would FreeBSD (developers?) need a license to ship the OS with a
> SEND implementation?
>
> -- does it really change the state of affairs if the product is sold vs.
> given away for free?
you really need to ask your lawyer.
though i am sure you will get plenty of advice here. if not,
>> also, do not underestimate the co$t of the of operational change to move
>> from dhcp4 to nd/ra. folk who want to keep dns and ip audit may have to
>> go static without dhcp6. another non-trivial barrier to ipv6 deployment.
> Randy, could you elaborate please? Not sure I see what you are getti
> But you're saying that as an operator need, when in fact your
> rationale is to reduce vendor code. Is any vendor complaining about
> this?
your monotonically increasing bug count results in my operational need.
randy
IETF IPv
>> no one is arguing nd/ra be removed entirely, as subnet anycast should be.
>> the argument is that there are environments where it is not needed and
>> dhcp should be able to be used in its place.
> That's reasonable. There are cases where auto configuration does not
> work well. A centrally c
> I'm not against new-and-better, and I have some spare Token Ring PCMCIA
> cards if you need them, but we already have an IPv6 legacy. Mikael
> is arguing for a mode in which there is no ND/RA traffic whatever,
> so that layer-violation code in layer 2 doesn't have to watch out
> for it. That isn'
>> Well, I think what would help is to be able to run a DHCPv6 only
>> environment without RA/RS, it would also help if one didn't need NS
>> either. The whole L2 environment would need a lot less code, it
>> basically would only need to be able to filter the above mechanisms, not
>> inspect them.
> XP has limitations but is still usable if IPv6 is enabled.
on a dual-stack lan, or one with a specific dns-over-v4 crutch for xp
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.iet
>> 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 practice, deliver packets, and charge the customers.
and it i
>> So, back to:
>> 1) should implement redirect
>> 2) should NOT enable by default
>>
>> right?
>
> This is what I'm after.
for juniper's internal network?
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrativ
> The SP's from Japan I spoke with at the IETF 78 told me they want
please do not speak for operators
> to future-proof their network.
future-proof == adding crap we do not understand or need
> they say, what if router vendors in future change their code to start
> anycast processing with a /12
>> That's not the point. With such a /127 setup between two directly
>> connected routers, one does not want any router to invoke anycast
>> forwarding functionality because /127 is provisioned. To prevent any
>> anycast processing on a router, the ND off-link model is proposed by
>> Dave Thaler
> I don't claim to represent all views on IPv6. I *do* claim that a view
> that "more addresses" is the only justification for IPv6 is reasonably
> widespread.
you don't want mandatory ipsec, longer battery life, ...? :)
96 more bits, no magic -- gaurab
the problems existing operators (who just
>> The IPv6 standards community can of course continue to pretend a
>> belief in universal 64 bit IIDs - thus ensuring that they are out of
>> touch with IPv6 reality...
>
> Maybe that's your reality, but it isn't everybody's.
as you demonstrate so clearly
but those of us who are operators and a
> If the /127 draft is a rebuttal of RFC3627
and if it isn't? maybe it's just a bug report on one bit?
> Other examples - there are probably more - of things I think that should
> be discussed, beyond what is in RFC3627 -
where is that darned immersion heater?
randy
---
> 1. We don't have any experience with MIPv6 RO, I agree. But, if we
>don't enable this function in every IPv6 node, we will never ever
>have the opportunity to turn this feature on.
for all values of X. when we don't even have basics working and
deployed and actually used. full employme
> yes. this seems like a case of something that looked like a great idea
> 12+ years ago (rfc2461 was published in 1998, LOTS of things have
> changed since that time) but is upon reflection maybe not a great
> idea.
>
> Directed Broadcast is a super example of this same thing (perhaps not
> rfc
> For the 4th time to this mailer. What do you do with shipping routers
> as of 10 years back that have Redirect enabled by default because of
> the SHOULD in RFC 2461 and RFC 4861?
standards work != archeology
IETF IPv6 working
> So, to sum up: yes, we know that the IPv6 link local addresses exist
> on our routers, no we don't normally "deal" with these addresses in
> any way.
and hope we don't have to, because they are not reachable, not uniqie,
have no mapping to the way we think of and name the interfaces, ...
and ye
>> because my routers don't operate via telekinesis or redirects. my
>> hosts don't listen to redirects as the information may be forged or
>> improper.
>
> So why can't you disable redirects? If they are configured on by default,
> it will be possible to configure them off.
>
> I understand tha
> link-local addresses have a very-limited use (and in some cases no use
> at all in the backbone that we operate).
i fear we are talking to people who don't go past the head end. cisco
is big, and folk can get tunnel vision.
randy
1 - 100 of 117 matches
Mail list logo
