Erik: About draft-ietf-6man-eh-limits. If every comment is
addressed, whether there is much of a document left by the time
everybody has had their cut at the text. Inclined at this point, to
send it back to the WG, whereupon, if we can't find someone to try
to turn it into something that could get passed with all the
comments received the first time it came to the Telechat, it might
be best to declare the document dead for now.
Michael: if we can't put the limit on it then no one can effectively
deploy the extension header because people aren't going to do their
hardware right. Don't think killing it is an option for the
successful universal deployment of IPv6.
Erik: Maybe we don't need to drop it, but it will take new eyes to
figure out how we go from where it is now to something that could
get published. There's been time between the last time the IPv6
headers across the Internet was done and now for new router silicon
to be deployed. Maybe there isn't actually a need to put a limit on
it if things are sort of getting themselves fixed. But we don't know
that at the moment.
Michael: I'll read the discusses and then decide whether/how to help
with the document.
Bob: It would be good to bring it back to the working group and we
can see what we can do going forward.
Tim: This draft conflated the protection of the node itself from the
extension header options with some good guidelines for what it
should and should not process, with the whole "you shall not send an
extension headlonger than 64 bits", if we separate those two apart,
we might have some success. And there was a paper I posted to the
list several months ago that showed that it is not a silicon issue,
but more policy issue. Separate out the node protection from the
maximum length.
Erik: In the end, the draft might be significantly smaller and more
targeted than it grew to be.
Erik: On draft-ietf-6man-rfc6724-update, it is ready to go, but
in the last revision, some text crept in and Nick and others have
been fixing it, so I just need to get back around to looking at the
final diff and then we can send it to the RFC Editor.
Nick: I fixed those, should be good now.
Lorenzo: I'm just going through with a fine-tooth code. Since I had
to look at the requirement anyway, I'll send them to the list. None
are these are important, but I'll send some sort of suggestions and
we can take them or leave them. I don't think they are critical.
Lorenzo: About 6724 update, the only thing we want to discuss is the
text says that, the host should not consider anything local anymore
when it's deprecated. I think should say when it's removed. Just
because something got deprecated doesn't mean it's no longer local,
it's still local, just deprecated.
Tim Chown: We will fix that very quickly. I didn't notice Tim
mentioned SNAC and how far we want to go with 8504 bis. The section
currently about IoT-type stuff is minimal. Do we want go there at
all? And if so, how far do we go?
Lorenzo: The whole point about SNAC is an unmodified host should
work. It was designed for that. So hopefully, we don't need new host
requirements to make SNAC work. My assertion is that if we need new
node requirements to make SNAC work, we should retroactively cancel
the existence of SNAC. The whole point is it should work on
unmodified hosts.
Ted: Lorenzo is correct if the hosts implement the requirements. Or
even if they don't to some extent because it's working now.
Jen: There was a YANG model for IPv6 Neighbor Discovery in RTGWG.
This document would be better suited to be in 6MAN. We are expecting
it to appear here. So you'll see more about it on the list.
Lorenzo: What can we do with 5.5 and without 8028?
David: The steady state works properly. 8028 is most important when the
topology changes and we need to stay on a router that is no longer
preferred. can do multi-homing as long as both streams are alive. We'll
choose one by whatever router is preferred and we need 5.5 to ensure we
use the proper source process for the one IP in operation. Without 5.5
even that doesn't work we may pick the wrong source and nothing works.
It is valuable in itself, but 8028 is needed to make this complete.
Lorenzo: What qualifies as the topology, would cause the router stuck,
that depends on the implementation. It is not clear even in steady
state, whether this will work. Our observed behavior of these
implementations in these scenarios is that it does work, but we
shouldn't declare victory, necessarily. I think in 6726bis update, we
were requiring 5.5, which makes sense, maybe put 8028 in node
requirements.
Tim: Network Manager with ECMP, there is no way they should be doing
that. And, what's the plane for the Linux patch
David: The plan is to upstream it.
Jen: The ECMP is harmful. We might want to clarify it. Secondly, Android
at least in case of renumbering or topology changes, might survive
because it disconnects when gateway disappears so a new session neeed to
say it would be okay for topology changes.thirdly, about Rule 5.5
without 8028, it depends on use case.For phones and laptops, Rule 5.5
solves more of the problem because we're picking up new source address
for new session and it works, unless there is topology change. For
servers, when it could be in connection to a specific address an you
need to respond from that address, then it is a problem. To get a full
solution we need both, but low-hanging fruit is 5.5.
Lorenzo: Android doesn't disconnect with topology changes. It
disconnects when all routers have gone away. I don't think anyone really
understands from the people writing those implementations, maybe we
should try harder to break the implementations and see if we can break
them.
Jen: Do we need to define the test cases and somehow standardize them?
David: IETF doesn't normally define test cases. If we can just collect
test cases, that is probably quite valuable.
Tim Winters: There are a bunch of test cases for US government that test
Rule 5.5 so I strongly recommend starting with those test cases.
David: The ECMP thing, I absolutely agree this should not happen and we
need to communicate that.
Jen: 8028 say "should", but Rule 5.5 and 8028 is crucial for preventing
connectivity issues, so it is kind of a "must".
Lorenzo: It should be "must", because if we are okay with 5.5 being
"must", the two come together and it is a fundamental piece.
David: 8028 is not a good pointer for this behavior. The dst source
routing is a better description of the same thing. 8028 is a subset of
dst-source routing.
Ted: PD per client is very important. We need to have normative language
about it. Not sure it has to be a "must" because there are constrained
devices for which it might be too much, but it should definitely be a
"should" and the exception should be clear and limited. PCP should be a
must. And 8028 must implemented seems right.
Jen: +1 to David. Maybe we can take very specific requirement from 8028
and put it there. Maybe instead of update 8028，we can sneak it into host
requirements.
Philip : Making it either a "must" or at least a "should" with a clear
exception. Whether 8028 is referenced is questionable. David's solution
is the best we can do at the moment.
Tim: I can take that back to the group, clean up texts.
Nick: +1 to Phillip
Lorenzo:I'd love to see a document explaining how IPv6 multi-homing
would work. A lot of existing documents suppose presence of legacy host
and things like that. If we add more scenarios to that document saying,
here is how this would work, some of the test cases we were talking
about would fall out of there, but that would help.
Jen: About test cases, if you define the behavior, it is kind of test
case. Let's talk offline about writing that.
Lorenzo: It would serve as a demonstration to show people who are
skeptical about this and even some of the MP6 community is very
skeptical this will work. There is one thing that we still don't know
how to do, which is to have the network elements choose your source
address. That is not done compared to IPv4 multi-homing. Writing that
statement down saying here is how IPv6 multi-homing works, would be
great.
Lorenzo: DNS 64, what is that?
Tim: 7050.
Lorenzo: Pref64 option is yes.If you deploy the green field network, you
don't want the extra RTT. I think saying, if you want to support
IPv6-only networks, you must do all these. You can say okay, your
thermostat doesn't need to do this, but if you want to do IPv6 only, you
must do these.
Nick: second Pref64. That is important to be noted for clients.
Florain: For DNS 64, you want to say must not?
Tim: We'll try to say the right words an avoid that problem.
Jen : It's been mentioned currently in IETF Last Call, there is a
document that says you should not. DNS64 is normal DNS, So I don't think
we need to explicitly mention that, but local synthesis, yes.
Ondrej:+1 to Jen. For apple devices, the application is doing the thing
it was doing before, but the operating system is doing IPv6, similar to
the bump-in-the-stack RFC. This should be referred, but there should be
something to refer to that is better than a variant of bumping the stack
.
Jordi:I think we should say something like, you must do something
otherwise do DNS64.
Tim: I don't know if Node Requirements would be the place to put that
in. I think there are a lot of things we can tell people about local
synthesis and v6 network. I don't think we want to wade into DNS64 and
whether it should be there or not.
Mark Andrews: Doing IPv6 synthesis will lose the routing table.
Synthesizing is a bad idea. Let the client do the job. The application
doesn't need to know how to do it.
Ted: The thread spec requires that all thread devices do their own
synthesis. And nobody has objected to that, and that code exists in
every thread device that you can buy on the market right now. Not that
hard.
Mark: Bind alreay does prefer ipv6 to ipv4 service with DNS. It biases
it by 60 milliseconds or something like that. It measures the router
time but gives IPv6 addresses 60 milliseconds advantage.
Ted: The thread stuff, if there's a quad record, we don't even
synthesize.
Erik Nygren: A challenge, that at least some OSS like Linux only allow
you to have 3 resovlers in the actual working set. So it's a challenge
for operators who want to provide more than one v4 and more than one v6
resolver. There might be operational things on how do people work around
that limitation.
Lorenzo: We need to update 4861.
Tim: Happy to write a small draft that says here's the reasons you
should send these energy efficiency. If you're not sending RAs and
waiting for a blasted RA, you could be in pain. Jeremy was suggesting
opening all of neighbor discovery.
Lorenzo: We should absolutely not remove it.
Tim: We won't remove it from node requirements. There's a separate item
about a new draft to fix the RAS transmission issue separate from that.
Zafar: There is an existing method RFC3022 that says that the NAT box,
can go inside the packet and look at the ICMP error payload and can do
the translation on the addresses. But the RFC also said this is done for
privacy reasons. This is done so that the internals of that particular
network are not exposed to outside.Now you have a new way to export
internals of the network. How did this satisfy the privacy concern which
was the 3022 was written for?
Ron: This is actually for more than privacy concerns. If TCP originates
a send segment to open a connection. That packet reaches the middlebox
and the middlebox changes the IP addresses and the port. That's what
NATs do. It hits the ultimately destination and something goes wrong.
The destination sends back an ICMP message and embedded in that ICMP
message is exactly the packet, as it was when it arrived at the
destination, with the translated address and the translated port number.
If the NAT box allowed that ICMP message through, the sending TCP would
receive that ICMP message, look at the embedded IP message, and try to
match that embedded IP message with one of the things that it sent. It
would look eight and say, I can't do that, I never sent a packet to this
address or this port. The middlebox that translated the address in one
direction needs to translate it back in the other direction. It's not so
much a security problem. It's what you need to do so you can match the
outgoing packet with the embedded packet in the ICMP destination
unreachable.
Zafar: Discuss more offline.
Jen: Your draft probably needs to say that intermediate boxes must not
modify the content.
Bob: It seems what it's doing very complicated opposed to just saying,
send me the packet back. Why have all the complexity?
Ron: We would be glad to take away the other ones if the WG wants that.
In some cases, it may be a violation of the reflecting node security
policy to show everything. Maybe there's some things I don't want to
show you about how the packet has changed en route to me.
Bob: But then the sender has no control over it anyway.
Ron: That's true. If it helps, we can remove everything except reflect
all.
Tal Mizrahi: Regarding the normative language must not modify the
reflection object. So at some point, this was actually the language in
the document. And then there was one of the comments we received in or
after Last Call is we probably shouldn't use normative language with
regards to middleboxes. And we removed that normative language.
Jen: It's actually strange because vendors need to know how to process
the new message. So document defines the new message, it would be really
nice to describe for both sender, receiver, and intermediate nodes what
to do with it. Otherwise, they will get confused and start modifying it
and it will defeat the whole purpose. For this to be useful, we must say
they must not modify it.
Tal: If there's an agreement we can use normative language here, I agree
with that.
Zafar: I agree with the comment that Bob mentioned. This is really
receiver driven. Receiver decides what it wants to expose and what
doesn't want to expose. If receiver doesn't want to expose something, it
will filter it out. For sender to say give me this and that, it adds
complexity.
Ron: Sounds like we have consensus to leave only the "reflect all" and
get rid of all the other objects.
Jen: Section 8.1 of 4861 explicitly said the host must drop redirects
coming from non-link local address, redirect are supposed to come from
link local addresses always. So I don't see why it's an issue at all.
Ondřej: That is correct.
Jen: From link local.
Ondřej: This is normal direct message because this is a message emitted
by the route if the router sends the packet to the same interface it was
received. So it's proper redirected by the protocol.
Jen: It's a policy decision, right? Router would route the packtet in
addition to sending redirects. So if you allow a host to talk to each
other, you probably shouldn't be redirected.
Ondřej: It's a policy decision. But there is no room for a policy. There
is nothing saying in the neighbor discovery RFC that it should be
controlled by policy whether the router redirects or not. Just say
router should emit redirect.
David: Slide No.2. You have there on the interface the address of the
host with the 128 prefix. That is not what I get when I set this up. I
do get a 64 address. But no route on Linux. And then it actually works.
I don't know if this is a Linux invention. I don't think this is
described anywhere. Maybe off-link is underspecified in this regard.
Ondřej: I didn't check it. But my understanding is that the only meaning
of the number after slash in the address config is actually the
connected route. So if there's no connected route, judging by the
behavior I'm seeing that mask length is also used to check whether you
should send the ND reply or whether you should accept the source for
neighbor solicitation. Linux hosts and Window hosts are okay with
talking to the off-link router but not Apple devices.
Lorenzo: Your first issue is an operational issue. The standard already
says if the router should only do this if there is a better first top
node. It is a policy decision.You have to tell the router that the
network isolation is involved.Normally, it is better. But if you drop
the packet when they try to talk device to device, it's not better. So
you need a way to teach it that it's better. This text doesn't need to
change. 4861 is fine because the router needs to figure out what better
means.
About the Apple device, I think it's wrong. It should reply. RFC4861
says you ought to do this. And at the time it's written, we had weird
multi-link networks and off-link and on-link which are different from
IPv4. But the RFC says you need to send NA even if it's not on link in
any way to you. If you look at the code that says here's how I process
NS, it doesn't check that there's a route pointing to it. It basically
says you have to add the neighbor cache entry and then you need reply.
Because it was written for the links.
Tim Winters: Solve this by policy-wise or config-wise, configuring the
router to disable sending redirects which most routers support minus
zero config ones which most of time home gateways will not send
redirects.
Agree with Lorenzo, I don't think 4861 has a mistake. You need to write
a new draft that says when you're isolating, you should configure that.
Most enterprise routers have this knob. So I don't think this is a
controversial thing. There are lots of things that people have access to
and routers that aren't specified in 4861. So Linux has a redirect
enable flag in control.
Ondřej: Not really for IPv6.
Tim Winters: You should write a small draft, probably give some people
some advice. You should say, if you're doing device isolation, routers
need to support disabling redirects.
No comments.
Sasha: This draft describes exactly what some existing implementations
have been doing for years in MPLS networks. This behavior has never been
standardized by the MPLS or BESS.
Do you plan to present this to bess as well? The draft is standard
track. Since there is no standard in the MPLS case, informational would
be better for this draft.
Zafar: No strong option on standard track or informational. It's up to
chairs and AD to guide how they would like to proceed.
Greg: How this mechanism is different from a individual draft on
transcending traceroute that was discussed in NOV3 group years ago?
(https://datatracker.ietf.org/doc/html/draft-nordmark-nvo3-transcending-traceroute-03)
Zafar: Will read it.
Ted: Sounds like a good idea. There are people that are more clear on
it. So we should probably get it through to them.
Another option in addition to Wi-Fi alliance would be to push it through
matter. The problem with Wi-Fi alliance, it's the lowest common
denominator. Matter is more high end, at least we can create some market
pressure that might mote strait Wi-Fi alliance to move, even if they
don't move initially.
Jordi:We should push for that.
Lorenzo: This looks complicated. We don't even if it's implementable.
David: We know it's not implemented. None of the enterprise solutions do
the AP side of it. So it cannot be in use for lack of network side.
Lorenzo: So we don't have existence proof, which means it might be
impossible to do correctly. e.g, it may be impossible to do the right
thing in the presence of different clients with different requests.
David: The AP decides the interval. The request has a maximum field and
the AP can change interval to something lower. It's lower because this
causes delay and the idea was that kind wants to place maximum on the
delay.
Lorenzo: So if someone asks for one, everyone pays more power?
David: Presumably.
Lorenzo: We should try to see who wrote this and see if it should be
used for this.
David: It's in 11v. And it does say in the text that it's intended for
power safe. At least the goal was this.
Ted: Is this something we can implement in openWRT?
David: You need firmware support from the WIFI chip. Maybe could do it
on Meida Tek chips, because they have relatively low firmware to host
barrier.
Bob: I think that would be a little more discussion on the list and then
request that we adopt it and then we can do an adoption call. And then
we can see if there's legs behind it.
David: This is not intended to ever be an RFC, but I just needed
something written down.
Jen: We need to get consensus in the WG, is it a good idea, is it
something we want to do? And who is doing this is a different story.