Thanks for writing this down!
Wonder what it would take for a host to do router discovery using a different
AF.
Achieving the equivalent of "ip route add 0.0.0.0/0 via inet6 fe80::1 dev eth0”
O.
> On 22 Jan 2024, at 15:39, Warren Kumari wrote:
>
> Hi there all,
>
> I discovered that I'd
Rolf,
As a historical tidbit you may want to include in your draft. IPv6 supported
reverse traceroute out of the box. Using RH0 and sending a packet to yourself
via the destination. That code is probably still in stacks.
O.
> On 25 Nov 2022, at 13:56, Rolf Winter wrote:
>
> Dear Intarea
>> Taking "the IPsec approach" would be creating a new extension header
>> and code point that is unique to IPv4-- I don't see how that's any
>> better than just using an existing EH defined for IPv6.
>
> I'm not sure I agree with that.
>
> When we added IPsec to IPv4, a system that didn't
Fred,
> Ron, it is just a drop in the bucket compared with the amount of discussion
> since
> "Fragmentation Considered Harmful (1987)". But, I think we now clearly see a
> case where fragmentation is *required*.
Absolutely. As tunnels produce a new link-layer, that can (should) be a
function
>> 1) It introduces something new and undescribed in paragraph 2.
>> "unless they also include mechanisms to detect that IP fragmentation
>> isn't working
>> reliably."
>> That seems like hand-waving to me. Suggest deleting.
>
> Fragmentation success or failure is
> And of course encapsulation can also exacerbate the problem
> by increasing packet size.
>
> All this means is that the fragmentation layer needs to take into account the
> size of the outer encapsulation layers that will be added and make sure its
> fragments do not exceed 1280 bytes
Joe,
edited to focus on the two added "recommendation sentences".
1) It introduces something new and undescribed in paragraph 2.
"unless they also include mechanisms to detect that IP fragmentation isn't
working
reliably."
That seems like hand-waving to me. Suggest
Joe,
> Comments below.
>
>> On Sep 5, 2019, at 11:33 PM, Ole Troan wrote:
>>
>> Bob, et al,
>>
>> I have two issues with this text.
>>
>> 1) It introduces something new and undescribed in paragraph 2.
>> "unless they also include m
Bob, et al,
I have two issues with this text.
1) It introduces something new and undescribed in paragraph 2.
"unless they also include mechanisms to detect that IP fragmentation isn't
working
reliably."
That seems like hand-waving to me. Suggest deleting.
2) Paragraph 4:
"The risks
Fred,
>> Is that not the exact definition of outer fragmentation?
>
> No. I am talking about outer header (OH) followed by tunnel header (TH)
> followed
> by inner packet (IP). Recipe:
>
> 1) wrap the IP in a TH to create a tunnel packet (TP)
> 2) fragment the TP
> 3) encapsulate each
Fred,
I removed the IESG from this list, as we seem to have drifted into a more
general fragmentation discussion as opposed to discussing the exact changes to
this draft.
Why is that more useful than what is in 3.5? If it’s not making a
recommendation, why call this out in the
Fred,
>> Why is that more useful than what is in 3.5? If it’s not making a
>> recommendation, why call this out in the introduction. There are lot of
>> other things it doesn’t make recommendations about that aren’t in the
>> Introduction either.
>
> Because it sets a more appropriate tone
Tom,
> It does seem that Cisco configuration manuals and marketing materials
> are the best source of information on virtual reassembly.
>
> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_frre/configuration/xe-3s/frre-xe-3s-book/virt-frag-reassembly.html
> is a little more interesting
> On 30 Nov 2018, at 18:33, Joe Touch wrote:
>
>
>
>> On Nov 30, 2018, at 9:22 AM, Ole Troan wrote:
>>
>>
>>
>>> On 30 Nov 2018, at 16:49, Joe Touch wrote:
>>>
>>> 1) the lower down the fragmentation occurs, the less ov
> On 30 Nov 2018, at 16:49, Joe Touch wrote:
>
> 1) the lower down the fragmentation occurs, the less overhead is needed
> (i.e., when performance is an issue, it’s even more important to fragment as
> low as possible)
That sounds like an unfounded myth.
I would think it highly dependent
>
>> Of course you can pass non TCP/UDP through limited domains, but you cannot
>> expect that to work across the Internet anymore.
>
> You mean the IPv4nternet, I hope ;-).
I hope so too. ;-)
Ole
___
Int-area mailing list
Int-area@ietf.org
Joe,
>> For IPv4 part of the transport headers are now part of the network layer.
>> Forwarding is done one address and port.
>> I.e it's now part of 'normal' routing/forwarding. That's absolutely not the
>> case. In IPv6 packets are delivered to hosts based on longest match on
>> destination
Tom,
> I don't believe this can be true. Not all protocols even have port
> numbers (e.g. ICMP, ESP) and yet we still expect them to be
> deliverable. Maybe your referring to ECMP, which does route based on
> flow (e.g. port information)? But, ECMP is not required to make IP
> work either.
Joe,
>>> Again, this does nothing for middleboxes that can handle IPv6 fragments.
>>> Flow labels don’t fix DPI or NAT devices.
>>
>> It wasn’t meant to. If you read my post, I clearly stated the IPv4 Internet.
>>
>> There is much less justification to “encourage deprecation” of IPv6
>>
>> RFC7596 specifies destination unreachable, host unreachable for this.
> You have to be careful; that would cause the origin to cease sending all
> traffic to that IP address - which works for that RFC (which is L3 oriented),
> when in fact it is only the lack of the L4 info that makes it
> See my suggested text - I.e., if you can’t handle the fragments they way you
> WANT, then you need to forward them.
To where?
When the forwarding decision is based on L4 information, as it is inthe IPv4
Internet, the best we could do is to send an ICMP destination unreachable back.
>
> IMO,
> On 12 Nov 2018, at 11:11, Joe Touch wrote:
>
>
>
> On Nov 12, 2018, at 1:36 AM, Ole Troan wrote:
>
>>> And none of these update RFC1812.
>>>
>>> These things can be rolled out in any numbers you like - they are creating
>>> the p
> And none of these update RFC1812.
>
> These things can be rolled out in any numbers you like - they are creating
> the problem that only they can clean up. Killing capability in the rest of
> the Internet to make these mechanisms work isn’t a viable solution and never
> has been.
And if
ng the wg
with this.
But just as you know these mechanisms are rolled out in increasing numbers (of
course, since there is no choice until universal deployment of IPv6) and there
are millions of users behind them already.
Ole
>
>> On Nov 8, 2018, at 9:13 AM, Ole Troan wrote:
>>
>>
>&g
xtensions of a
host. Not even under same administrative control.
Ole
>
>> On Nov 8, 2018, at 8:43 AM, Ole Troan wrote:
>>
>>
>>
>>> On 8 Nov 2018, at 23:15, Joe Touch wrote:
>>>
>>>
>>> It always can forward based on IP info
> On 8 Nov 2018, at 23:15, Joe Touch wrote:
>
>
> It always can forward based on IP info alone. It is only the desire to alter
> packets in transit or forward based on transport info that gets in the way.
Joe, I have told you many times over that this is wrong for IPv4. Repeating it
does
>> We need compliance checks to fix this, or to find another way to put more
>> pain where the problem lies.
>
> I would like to hear from the vendors of the stateless devices whether
> they think this is feasible solution.
Implementations tend to live within the laws of physics, so demanding
We have scheduled a side meeting to discuss IPv6 Path MTU Discovery to continue
the discussion at today’s 6man session. It will be:
Fri, November 9, 10am – 12pm
Where: Thai Chitlada 2 room
The goal is to discuss the current and new Path MTU Discovery approaches.
Please let us know if you
Richard,
> As a side-note, is it really that challenging or slow to get a new
> DHCP option assigned? Perhaps I'm showing my naivety here.
Getting the DHCP option itself isn’t hard. But then you need to get it deployed
in DHCP servers, you need to get it deployed in DHCP clients.
And you need
>> I'm not sure DHCP configuration is really needed. It seems like overkill.
>
> Other reviewers/commenters previously felt that this was a useful
> addition. This would allow Network Operators to trigger or influence
> the connectivity check on CE routers that they are not in TR.069/etc.
>
Joe,
> On 27 Aug 2018, at 10:27, Joe Touch wrote:
>
>
>
>> On Aug 26, 2018, at 11:55 PM, Ole Troan wrote:
>>
>> Joe,
>>
>>>>
>>>>> On 26 Aug 2018, at 23:12, Joe Touch wrote:
>>>>>
>>>&g
Joe,
>>>
>>> On 26 Aug 2018, at 23:12, Joe Touch wrote:
>>>
>>> As I’ve mentioned, there are rules under which a NAT is a valid Internet
>>> device, but it is simply not just a router.
>>
>> If there really was, can you point to where those rules are? Describing the
>> behavior of the host
> On 26 Aug 2018, at 23:12, Joe Touch wrote:
>
> As I’ve mentioned, there are rules under which a NAT is a valid Internet
> device, but it is simply not just a router.
If there really was, can you point to where those rules are? Describing the
behavior of the host stack and applications?
> On 16 Aug 2018, at 20:10, Joe Touch wrote:
>
>
>
>> On Aug 16, 2018, at 10:02 AM, Ole Troan wrote:
>>
>> These are not NATs. They are specifically designed to be stateless
>
> I think we also can agree that this, while intended, is the point of failu
Joe,
> On 16 Aug 2018, at 15:58, Joe Touch wrote:
>
>
>
>> On Aug 16, 2018, at 5:47 AM, Ole Troan wrote:
>>
>> Joe,
>>
>>>> IPv4 fragments do have a higher drop probability than other packets. Just
>>>> from the fact that mu
Joe,
>> IPv4 fragments do have a higher drop probability than other packets. Just
>> from the fact that multiple end-users are sharing a 16 bit identifier space.
>
> It’s really the fact that NATs that process fragments don’t reassemble before
> translating and/or don’t rate limit fragments
>> Whether that automatically solves the problem depends on whether
>> PMTUD works, which is unpredictable. Therefore, if you want a protocol
>> *design* that is universal, it can't depend on PMTUD. Disabling
>> fragmentation on its own is not enough. (That isn't news.)
>>
>> The only universal
Joe,
>>> It also looks like (at first glance at least) these devices work only when
>>> there isn't multipath between the back and front side.
>>
>> The A+P routers are stateless and do support multipath. Including traffic
>> does not need to be symmetric.
>> That’s the main selling point for
Joe,
> I am not ignoring them; I'm claiming that they all have the same inherent
> deployment and implementation limitations.
>
> Just because operators/vendors "want" to do otherwise does not make it
> possible.
There was IETF consensus behind those documents
Joe,
>>> I am not ignoring them; I'm claiming that they all have the same inherent
>>> deployment and implementation limitations.
>>>
>>> Just because operators/vendors "want" to do otherwise does not make it
>>> possible.
>>
>> There was IETF consensus behind those documents (A+P).
>
>
Joe,
> I am not ignoring them; I’m claiming that they all have the same inherent
> deployment and implementation limitations.
>
> Just because operators/vendors “want” to do otherwise does not make it
> possible.
There was IETF consensus behind those documents (A+P).
In the _new_ IPv4
But only if you continue to ignore that there are other IPv4 sharing mechanisms
than NAT.
Ole
> On 1 Aug 2018, at 16:11, Joe Touch wrote:
>
> We all understand that many current NAT devices and their deployments are not
> compatible with IP fragmentation (v4 or v6).
>
> That leaves us with
Tom,
> How is this story going to be different for IPv6? How do we ensure that
> non-conformant implementation for IPv4 isn't just carried over so that
> fragmentation, alternative protocols, and extension headers are viable on the
> IPv6 Internet?
I don’t think the IPv4 implementations are
Joe,
>> The need for fragmentation cannot be completely
>> eliminated and we do need it to work. Devices that do things to
>> prevent correct operation still need to be fixed, and it would be
>> productive for the draft to include statements on how some of the
>> sub-problems problems can be
Joe,
> My model describes the rules under which translation devices can operate
> correctly and predictably in the Internet model.
>
> There are only a few alternatives for devices not explained by either model:
> 1- the Internet and my model are incomplete
> in that case,
Joe,
>> However much money you throw at it, you can't reassemble fragments
>> travelling on different paths, nor can you trivially make network layer
>> reassembly not be an attack vector on those boxes.
>
> Agreed, but here’s the other point:
>
> Any device that inspects L4 content can
Tom,
> On 28 Jul 2018, at 20:48, Tom Herbert wrote:
>
> On Sat, Jul 28, 2018 at 11:24 AM, Ole Troan wrote:
>>> Here’s the thing about fragmentation:
>>>
>>> 1. all links have a maximum packet size
>>> 2. all tunneling/encapsulation
> Here’s the thing about fragmentation:
>
> 1. all links have a maximum packet size
> 2. all tunneling/encapsulation/layering increases payload size
>
> 1+2 implies there is always the need for fragmentation at some layer:
1 implies that.
There is enough head room designed in 1 to
> On 27 Jul 2018, at 22:51, Fernando Gont wrote:
>
>> On 07/27/2018 10:28 PM, Ole Troan wrote:
>>
>>
>>> On 27 Jul 2018, at 22:12, Brian E Carpenter
>>> wrote:
>>>
>>> Fragmentation, (PL)PMTUD, extension headers, and innovati
> On 27 Jul 2018, at 22:12, Brian E Carpenter
> wrote:
>
> Fragmentation, (PL)PMTUD, extension headers, and innovative
> L4 protocols are very possibly not viable on the open Internet.
> At least, we can't assume that they will work on arbitrary paths.
> Sad but apparently true.
Hasn’t this
> On 27 Jul 2018, at 19:20, Tom Herbert wrote:
>
> Right, but I still think that we should be more clear about the root
> origin of problems and blunt in requesting that non-conformant
> implementations get fixed.
Barring bugs, implementations work the way they do because customers have
Joe,
> I still think it would be useful for this doc to describe how tunnels
> interact with fragmentation (per draft-ietf-intarea-tunnels), which seems to
> be something I’ve noted several times before.
There's nothing intrinsic in tunnels that require network layer fragmentation.
The
Joe,
> Agreed but note that draft tunnels will update that RFC in some important
> ways.
With other concerns than those raised in e.g. 4459 and 7597?
Unfortunately there are cases where there are no other choice than to do
fragmentation/reassembly on tunnel endpoints, but still the
Joe,
an IPv6 router compliant with RFC2460 does not inspect the header chain.
That cannot be true; there are headers after IPv6 but before fragmentation
that are hop-by-hop.
with the exception of the HBH header, correct. I got tired of writing that each
time I was repeating myself.
the
Fernando,
However, anything that says if the chain is X, then drop is broken,
period. At some point, if you want to play IPv6 router, you need to earn
the title.
an IPv6 router compliant with RFC2460 does not inspect the header chain.
I'm not aware of any router that drop packets with
Thanks, Tony.
Let me comment on one point in your review.
On Aug 20, 2010, at 11:47 AM, Tony Li wrote:
5) The draft misses the opportunity to call for work in v6 renumbering. The
fact of the matter is that sooner or later, sites will need to renumber.
Even given adequate address
56 matches
Mail list logo
