platforms in live networks have
default settings that slow-path packets with fragmentation header
regardless of size. It would be interesting to actually see data of this.
The comment part seems to be moderated so my posting hasn't made it out
yet.
--
Mikael Abrahamssonemail: s
ee more SAVI WG documents referenced not only by this
document :)
Apart from that, nothing I read stood out and document looks good.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.or
ter the above config kicked in.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
ortunately there has been too little atention on SAVI lately.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
SID, and not the router's MAC
address or the like.
If it's tricky, doesn't that specifically warrant more text on the
subject?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group maili
new network as well? I think some text on
this would be good guidance for implementors.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://
t the client's zoneid, then the client will be
unable to use said uri because it won't know which interface to use. Yes
the server doesn't care but the client depends on it (for link local
anyways).
How would the server know the clients zoneid? It derives this from the
initial
l get much enthusiasm there to fault find a
kernel that was released in october 2008.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.iet
say it's an absolute requirement that any proposal do not break
existing implementations.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.
we should focus on
keeping IPv6 stable when it comes to how it works, and get implementations
going, not new standards.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
ppy to take part if it happens.
For me, this is that discussion.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
was
"DHCPv6-PD might not be available".
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
ad of implementing a new standard?
Isn't ND handled by the kernel in a lot of OSes? Does prefix delegation
really belong there?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv
assigned by
default to their NAT boxes and then added an option to "clone" an inside
PC address if one wanted to change the WAN facing address.
MAC addresses being non-unique is happening a lot more commonly than it
should, and needs to be taken in account.
--
Mikael Abrahamsson
to change) who in
presence of telling the router to advertise the M-flag, automatically
removes the A flag and prefix from its outgoing RAs. I do not agree with
their interpretation of the standard (that in the presence of M flag,
clients must not do SLAAC).
--
Mikael Abrahamsson
behaviour somewhere, what would this
feature be called that I can ask vendors if they have in their equipment?
Just to be sure, we're now saying that reachability won't be had from the
outside unless the internal device keeps itself "registered" with the ISP
router.
-
ult-gw for customer which want to directly hook up SLAAC devices).
For routed scenarios I prefer LL only between PE and CPE.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Admi
ethernet interface, but then it's not
really a /64, it's a /128 that you reach via ethernet.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Reque
else there will
be directly an ICMP unreachable. Simple as that.
A tunnel is not a broadcast medium, it's a point to point device. You
already statically tell it what the other end address is, right? Thus,
this is not a problem on this type of tunnel.
--
Mikael Abrahamssonemail: swm...
Test it out today and complain to your vendor ;)
Wow.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
rly when handling
10k ND state changes per second.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
l equipment
is the default gw on the customer LAN). This is even without any ddos
discussion, this is just normal operations.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf
its of MAC
BIA information or even in extremis dare I say 12 bits?
/120 would be more doable. When I think of ND table size per customer, I'm
thinking limitation to 16-32 entries, after that the customer needs to get
a router.
--
Mikael Abrahamssonemail: s
, so I do not ever have to keep any state
regarding individual customer placed devices.
We have already requested that our L3 switch vendors have ND starvation
protection, but there is serious lack of documentation to point to.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
Pv6 router platforms today and give it 10kpps to random destinations
to its attached /64 (10kpps of small packets is 5 megabit/s) it'll stop
working normally.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6
the Internet.
Service providers want to keep malicious clients from degrading their
network.
Exactly.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative
rnet again?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
ss network).
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
c and
pre-distributing keys, ethernet can't be fixed without the "bandaids" you
seem to call the measures being used widely to assure ethernet can in
fact be used securely.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
--
tacks on each other. This requires some kind of limitation of
traffic they can send to each other using L2, and full L2 isolation is of
course the best.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group ma
On Wed, 22 Jun 2011, Ted Lemon wrote:
On Jun 22, 2011, at 7:41 AM, Mikael Abrahamsson wrote:
I agree, that's the deployment model I advocate for hostile scenarios. Use
DHCPv6 for stateful addressing, advertise default GW via RA, don't advertise
any on-link prefix, and make sure h
communicate at
all with each other by means of enforcement in switches (or just separate
them into different L2 domains).
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Admin
t;obvious" have
historically been overlooked numerous times.
Just the same way describing how to do SAVI L2.5 functionality to solve
different security implications needs to be done to provide guidance to
vendors, I also feel that they need to be helped to handle fragmentation
attacks.
implementations of this wouldn't also have some kind
of idea or concept of "client ports" and "server ports"?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv
for ETTH for the past 10 years.
On IPv4, this was done by means of local-proxy-arp by the gateway, which
is suboptimal for other reasons.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6
and
H3 to communicate between each other even though they're in the same vlan,
will make this completely stop working if R1 doesn't have a knob to
disallow it from sending redirects that might indicate that H2 and H3 is
on the same L2 domain (on-link).
--
Mikae
s routing table?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
chatty, and it does cause problems on large networks. One might call
this multiple faults on multiple levels (bad linecard code, bad L2
platform, bad low-performing CPU on the RP), but it does cause problems in
real life regardless.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
On Fri, 13 May 2011, Thomas Narten wrote:
Per a previous thread, there are indications that the WG may now be
willing to recommend that DHCPv6 be a SHOULD for all hosts. This is
based on the following rationale:
I support moving it to SHOULD.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
ind a phone we can get it working with. Right now we presume it's
a baseband issue on the phones we have available.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Admi
On Sat, 16 Apr 2011, Philip Homburg wrote:
PMTU blackhole detection seemed so obvious to me, that I never bothered to
find out if there was an RFC specifying that it should be done.
<http://tools.ietf.org/html/rfc4821> is what you're looking for I guess?
--
Mikael Abrahamsson
here.
Anyhow, the above text seems fine to me from a technical point of view,
nothing pops up as weird or wrong anyway. I think it needs a second look
over before it's ready for publishing?
--
Mikael Abrahamssonema
m together) was present in the draft (or a
referral to other text describing it), I'd be fine.
Right now I couldn't help reading the text in section 2.3 and wondering
how it was supposed to achieve what was described.
--
Mikael Abrahamsson
On Mon, 28 Mar 2011, Brian Haberman wrote:
Hi Mikael,
On 3/28/11 4:25 AM, Mikael Abrahamsson wrote:
Hello.
I read through 2.3 of the draft, and I am a bit unclear as to how the
next-hop should be selected.
In the case of my SLAAC machine, I see the next-hop for my default-route
as a LL
ngs recent discussions
in v6ops, perhaps there would be benefit in using different terminology
here?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Reque
privacy extensions.
Just because privacy extensions is the only address widely seen today as
being non-EUI64, doesn't mean that if you disable privacy, you get only
single EUI64.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
eciate some reasoning in the draft why
this was chosen as a SHOULD option.
I do not like the "disable Privacy"-flag thinking at all and I really
oppose going with that solution.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
---
s the behaviour I've seen is correct, you end up with a /128 pointing
to yourself and a default route pointing to the router LL address, nothing
else.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working gro
that's not the same as "not working", it
might just be suboptimal in some deployment scenarios and highly desired
in others.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
e. I don't see any
theoretical or practical MUST requirement for an on-link prefix.
I'm not quite sure which 4.1 you're referring to. Point 1. of section 4
of RFC5942?
Yes.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
-
that it needed to use (and actually used) DHCPv6 to get its
IPv6 address. No on-link prefix was needed (or even desireable in some
deployment scenarios).
Does RFC5942 says this is mandatory? I interpret 4.1 as this is definitely
not mandatory, rather the opposite?
--
Mikael Abrahamsson
hemes.
-
No, DHCPv6 can't stop the user configuring a static address.
Together with SAVI functionality it can. Well, they can configure it, but
they won't be allowed to send packets to the network with it.
<http://tools.ietf.org/wg/savi/>
--
Mikael Abra
or DHCPv6
(stateless and stateful) than to fiddle with RAs where the router vendor
also has to implement this functionality. Let's try to change RA as few
times as possible, please. Let the routers do forwarding of
policy-required queries and handle these in a server that is not on
tionality into RA than what is absolutely
needed. If you need to know what host had what IP address at what time,
disallow SLAAC and run DHCPv6.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing lis
ange RA more than is absolutely needed. The
problem description sounds exactly like what DHCPv6 was designed to solve.
If you need to track what IPs are used at a given time and by whom, SLAAC
is not the way to go.
The proposed solution doesn't solve the problem described.
--
Mikael Abrahamsson
On Thu, 3 Mar 2011, Mikael Abrahamsson wrote:
How should I configure things when it comes to information in RA and
DHCPv6? If this isn't possible, was this intentional behaviour from the
beginning, that DHCPv6 hosts without SLAAC can't get an on-link prefix
but they must go through
es to information in RA and
DHCPv6? If this isn't possible, was this intentional behaviour from the
beginning, that DHCPv6 hosts without SLAAC can't get an on-link prefix but
they must go through the router to talk to ea
ed to do all the same filtering as I would have to without the CPE.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/lis
osoft Xbox 360 and ask them how easy it is.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
and apply them to the link layer port.
I'm sure this is one thing SAVI WG has looked at and is part of their
requirements.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.or
tomer) for ADSL (ethernet DSLAMs), I'm sure there is the
equivalent for DHCP, I just haven't had the need to deploy it so I haven't
looked into it.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 w
isms used for IPv4 to achieve this.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
had
what IPv6 address at what time, because the network will filter any
traffic coming from addresses not handed out by DHCP and one knows what
physical port was allocated the IP address at the time.
So SLAAC is out of the question for these types of applications. M and O
flag set.
--
Mik
operating systems
seem to handle RA in the kernel and not in userspace, extending RA to do
more things is harder than doing it in DHCP (which is generally handled in
userspace).
--
Mikael Abrahamssonemail: swm...@swm.pp.se
HCPv6 Only
I see quite a lot of code overlap in the last two.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
nk you provided doesn't include the word "DHCP" (or DHCPv6) at all.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
know Apple doesn't support DHCPv6 at all.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
asier it is for all involved. Static filtering is easier than
dynamic inspection and filtering based on that. It means less punting
packets to CPU in the L2 devices, less DoS vectors, less everything.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
--
On Wed, 22 Sep 2010, Hesham Soliman wrote:
On 22/09/10 3:30 PM, "Mikael Abrahamsson" wrote:
On Wed, 22 Sep 2010, Hesham Soliman wrote:
=> I understand that, but I think that to make this work you will need
to do that with zero modifications to the host's IPv6 stack. I d
Do you count the DHCP client as part of the stack?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
On Wed, 22 Sep 2010, Hesham Soliman wrote:
ND is a show-stopper or even delaying any router vendor.
Nobody is saying a router shouldn't do ND. What we're saying is that an L2
network shouldn't have to do ND inspection, so it should be possible to
make things work without
off (Cisco switch off RAs by
default on some interface types already) and will have static
configuration mechanisms.
.. and what (I, and others) are saying is that we would like DHCPv6 to be
able to do the same "static" configuration.
--
Mikael Abrahamssonemail: swm...@swm.pp.
#x27;s
anecdotal but we didn't see this on the mailing list either. I can't see how
ND is a show-stopper or even delaying any router vendor.
ND is an integral part in any IPv6 implementation. Nobody is saying ND
shold go away, what we're saying is that it should be possible to r
tion at all, it only needs
to look into DHCPv6.
So I can certainly see how we could make ND/RA redundant for certain
types of managed network, but I don't see how we can behave as if
they don't exist, at least from a security viewpoint.
Of course not.
--
Mikael Abrahamsson
bility and security, and I can
only do that if my customers only communicate to each other via L3 via my
router. I never want customer to talk direct L2 to each other. Q-in-q is
expensive to terminate so I still want them to be in the same vlan.
this doesn't work on unmodified hosts with standards that
exists today, but the changes needed should be minor...
- A host without ND/RA wouldn't work on currently existing LANs
That's not what I'm proposing. I'm not talking about ripping out anything.
--
endors do not have this support yet for IPv6.
You might not think this is worthwile because you don't have this
deployment model in your network. That doesn't mean it's not worthwile to
ISPs with millions of subscribers who use an L2 ETTH deployment model.
--
Mikael
age from "Mon, 20 Sep 2010 07:31:05 +0200 (CEST)".
"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."
--
Mikael Abrahamsson
On Tue, 21 Sep 2010, Ole Troan wrote:
in IPv4 access networks you do ARP from the CPE at least. how did you
intend for the CPE to learn the default router's mac address? glean it
from DHCP?
Yes.
--
Mikael Abrahamssonemail: swm...@swm.
hbours apart from your gateway need to be known or
found.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
for 5-10 years for some
vendors, what they're doing is less to invent new IPv4 functions but to
actually make them a standard and document them.
IPv6 is another ballgame, there new stuff is happening.
--
Mikael Abrahamssonema
lt;https://datatracker.ietf.org/wg/savi/charter/>
Sure. Are you holding your breath?
Well, duplicating work is probably a bad idea. They have running code, I
don't see why people who want to fix this shouldn't join them in their
effort. Am I missing something?
--
Mikael Abra
On Tue, 14 Sep 2010, bill manning wrote:
you mean something like this?
http://www.isi.edu/div7/publication_files/novel_use.htm
Yes, that seems like a framework that my idea could fit into, absolutely.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
On Tue, 14 Sep 2010, Jeroen Massar wrote:
On 2010-09-14 07:59, Mikael Abrahamsson wrote:
[..]
Does this sound like madness or something that might be of use? What WG
might be best suited to bring this idea to?
What part can not be achieved with WHOIS/RPSL already?
Why aren't people
ore
information. External parties should be able to decide which level(s) they
want to trust.
Does this sound like madness or something that might be of use? What WG
might be best suited to bring this idea to?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
---
be pushed out of the
market anyway. I consider DHCPv6 support as an essential component for any
device connecting to the Internet, and I wouldn't even call it "Full" if
DHCPv6 support is lacking.
--
Mikael Abrahamsson
th, is not
economically viable in my world.
Now what?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
On Sun, 12 Sep 2010, Mark Smith wrote:
On Sun, 12 Sep 2010 07:29:10 +0200 (CEST)
Mikael Abrahamsson wrote:
On Sun, 12 Sep 2010, Mark Smith wrote:
So my question was how would you solve it (architecturally)?
Layer 2 devices inspecting traffic isn't architecturally acceptable
because i
On Sun, 12 Sep 2010, Brian E Carpenter wrote:
So, indeed, those who market layer 2 solutions relying on layer
violation will have to update their products when a new layer 3 arrives.
That is perfectly understandable and that's not something anyone is
opposing as far as I can see.
--
M
here, Mark.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
e lists. I've multiple times been thinking "why
the hell am I doing this, my forehead is bloody enough as it is" and
throwing my hands up and leaving, but I try to dig in and continue.
I hope others do the same thing, we need to get IPv6 deployable.
--
Mikael Abrahamssonemail: swm
and saying things I perhaps shouldn't, but I
hope the above might explain a few things.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
who don't, especially if they need to handle thousands of
customers (ie thousands of interfaces). Compare this to a Cisco 3550 which
can route thousands of customers in a few subnets if needed.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
n floor or replace), rate
limiting the RS packets per second from the end users, etc.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
27;t deny there was a lot in use.
It's great that IPv6 over PPP is solved (it was the easy one to solve),
but we won't deploy PPPoE to our residential ETTH customers just to get
them IPv6, that is just not a reasonable solution for us.
--
Mikael Abrahamsson
e use that have not been properly
adressed yet.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
he
protocols designed in the IETF hasn't had that part as a design criteria.
It's definitely headed in the correct direction though, but there is still
a lot of work to be done.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
---
On Thu, 9 Sep 2010, Fernando Gont wrote:
Mikael Abrahamsson wrote:
Last I checked, the standards said that if precedence/dscp changed, the
host should reset the session (correct me if I'm wrong, I don't really
have time to check it right now).
You're right. And it doesn&#x
prefer the IETF
model compared to ITU. Starting to comment and contribute on IETF lists is
quite easy if you want to...
--
Mikael Abrahamssonemail: swm...@swm.pp.se
IETF IPv6 working group mailing list
ipv6@ietf.org
Administ
stand all these
mechanisms and enforce this policy as they do L2 switching.
That is the closest thing I've been able to come up with in IPv6-land that
matches what we already do in IPv4-land.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
--
1 - 100 of 115 matches
Mail list logo
