routes (S 5.3) mistakenly points to
rfc5942.
- running " in the added rfc4941 text in S 5.9.3
- there's some overlap in the changelog section, at least rfc5952 and
rfc5722 are mentioned twice. (strange to see both numbered and
non-numbered entries there as well.)
--
Pekka Savola
in a study set a non-zero flow label.
http://www.maths.tcd.ie/~dwmalone/p/ec2nd05.pdf
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Mart
so I'm not sure how compelling it is.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
-
or in the absence of such history, a
randomly generated initial value using techniques that produce good
randomness properties [RND] SHOULD be used.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems
On Sat, 19 Feb 2011, Brian E Carpenter wrote:
On 2011-02-18 21:55, Pekka Savola wrote:
I think this document should also discuss APIs we have defined and that
relate to the protocols described in the document. A separate section
should be added on this.
I'm not convinced. If the goal
On Fri, 18 Feb 2011, james woodyatt wrote:
On Feb 18, 2011, at 17:44, Mark Smith wrote:
On Fri, 18 Feb 2011 10:55:18 +0200 (EET) Pekka Savola wrote:
RFC4191 (Default Router Preferences and More-Specific Routes) should be
discussed. Is this a MAY? Quite a few host implementations already
y (MLD) for IPv6 - RFC 2710
.. take out the RFC number from the title as you're actually addressing two
different MLD versions in this subsection.
The following two MIBs SHOULD be supported by nodes that support an
SNMP agent.
.. s/MIBs/MIB modules/ :P
--
Pekka Savola
claims to support this.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
IET
access lists doesn't seem simpler, though I see it
could be an option in some other contexts. In our case, we have 20+
subnets which are not behind a single big firewall, so there is no
"inside" and "outside". Also for that reason, using only globals would
be preferable
this also applies to other
applications so the issue does not go away with application-specific
tuning.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George
draft-ietf-6man-rfc3484-revise-01, "fec::/16" should be "fec0::/10".
fec:: would mean 0fec:: and the prefix length is also wrong.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Secu
radvd, but it would be nice to interop-test it with a client written
by someone else.
Please contact me off-list if interested.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. --
e can only have two nodes connected and does not perform
neighbor discovery.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- G
ar text on how these documents fit together.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Wed, 25 Aug 2010, Christopher Morrow wrote:
On Wed, Aug 25, 2010 at 1:06 AM, Pekka Savola wrote:
On Tue, 24 Aug 2010, Alain Durand wrote:
This is true for leaf networks where hosts share links with routers.
This is useless in the core of the Internet where you only have
point to point
routers and hosts.
I've not yet heard of a single example of a router which does not
support Ethernet and in consequence would not need to implement
Redirect for the abovementioned reason.
--
Pekka Savola "You each name yourselves king, yet the
on how this is actually
done, and right now I can't find any written references on the "p2p
self ping" troubleshooting technique I seem to recall. Olivier's note
about the different scenario may still apply.
--
Pekka Savola "You each name yourselves king, ye
different (incoming/outgoing interface). Does this
have different implications on the feasibility of implementation?
FWIW, "Packet may be forwarded back on the received interface" is
actually, AFAIK, used in certain PE routerscenarios where you ping
yourself over a p2p link.
--
Pe
from 1) RFC4861 perspective or 2) interface
flags perspective (whether ND is used for address resolution) like
SONET. As far as I know, it is not even possible to configure e.g.
Juniper routers to do either 1) or 2).
--
Pekka Savola "You each name yourselves king, yet the
On Thu, 12 Aug 2010, Alain Durand wrote:
It probably depend on what kind of router.. If you only have point
to point link, what is the value of mandating to implement
redirects?
I've yet to see a router that only implements point-to-point
interfaces.
--
Pekka Savola
On Wed, 5 May 2010, Pekka Savola wrote:
On Tue, 4 May 2010, Brian Haberman wrote:
This draft is the result of the constructive discussion in Anaheim
on moving RFC 5006 (DNS option for RAs) to the standards track. Please
review this document and provide feedback to the list.
Hopefully
tinfo/ipv6
----
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
IET
vailable to
applications (for example, I don't see apps like that using DHCP
information..).
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings-
from the IETF Trust).
For the record, the first version of code appeared in 2002 and was
from someone at ETRI:
http://tools.ietf.org/html/draft-shin-ngtrans-application-transition-01
About a year later, I rewrote and reformatted most if not all of the
code that now appears in RFC4038.
--
)?
This is not procedurally required for PS, but if there are a lot of
implementations already, this would be a strong argument for going to
PS.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks
n't call
that "implemented" myself. At least on my FreeBSD 7.2 router, subnet
router anycast address isn't configured automatically and I don't even
see system configuration parameters (e.g. in init scripts) which would
change this.
--
Pekka Savola
ng and what the right prefix is. So it's more general and
easier to just say "you're using a wrong source address, try something
else" (e.g., if a packet is coming from a source address that's
"directly connected" or otherwise do a silent discard.
--
Pekka Sav
make a great
addition to the total hash key for the purposes of this discussion.
Even though the flow label is set to zero, hashing would still work
just fine but on IP/tclass granularity. By adding flow label, you
could get finer granularity for flows that do set it.
--
Pekka Savola
* Traffic class
http://www.juniper.net/techpubs/en_US/junos9.5/information-products/topic-collections/config-guide-policy/policy-configuring-per-packet-load-balancing.html
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Sy
of UDP, though this would
complicate the spec slightly. The LAG argument doesn't apply in the
case of AMT.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George
view of AMT specification, I don't see the need for
IPv6 UDP encapsulation, even if you buy the LAG argument (I'm not sure
if I can see 10G+ of traffic being LISP encapsulated between a couple
of routers), it doesn't apply to AMT due to different traffic
patterns.
--
Pekka Savo
tinfo/ipv6
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A
publish this document at
its discretion. Readers of this document should exercise caution
in evaluating its value for implementation and deployment. See
RFC 3932 for more information.
(From RFC3932 Section 4)
--
Pekka Savola "You each name yourselves king, ye
nt.
I think this is interpreted so that some IETF approval for new
codepoints is required. It is not obvious why one couldn't just ask
community the question "do we grant this codepoint for this purpose?"
instead of "do we grant this codepoint for this purpose by appr
ts from/to a non-labelled link,
as described in the draft.
This has issued mentioned above, but even if it is true, equally
possible would be to do that insertion with dst options or some other
marking.
--
Pekka Savola "You each name yourselves king, yet the
Netcore O
op-by-hop options, and this doesn't
reach that.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--
l host.
Some older versions also didn't support '-M do' properly for IPv6.
So there are quite a few things that could lead to non-deterministic
behaviour.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds.&quo
re as evidence that site-local deprecation hasn't
been as successful as we could hope. Putting 3879 to AS doesn't fix
above.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- Ge
work as well.
Site-locals and ULAs is one area where I suspect our understanding of
the situation has improved, and will continue to improve. Timing the
update properly to gather that understanding is probably a good idea.
--
Pekka Savola "You each name yourselves
and organizaitons like that to do
that. We could help in that process, and I'd hope we'd get feedback
on the viability of our specs in that regard, but trying to write RFCs
would likely be difficult.
So I think we would be best served by a TCP-roadmap like document,
which we coul
n/listinfo/ipv6
----
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
---
idance) on
when one should choose WiMAX using IPCS or Ethernet-adapation, or
possibly some third (or fourth) option.
I'll note that while the current node requirements lists some IPv6 L2
adaptation mechanisms, the list is not complete, and I don't think it
needs to be complet
minal operating as a L2 bridge and multiple devices
behind it requesting addresses with DHCPv6?
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security.
On Thu, 16 Oct 2008, Iljitsch van Beijnum wrote:
On 14 okt 2008, at 18:45, Pekka Savola wrote:
The reality is that most implementors will just ignore anything the spec
says they don't like or consider unnecessary in the scenarios they have in
mind. As long as their code interoperate
on,
especially when coupled with other configuration management tools that
can help automate it for you.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George
t of the protocol; we can then throw away the rest
unless there is serious interest in it.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
---
hinders
interoperability.
I'd say there's a failure somewhere (missing liaison?) in driving IPv6
APIs to completion. This isn't exactly a recent issue given the
predecessor RFC2292 was completed some 10 years ago..
[1]
http://sourceware.org/bugzilla/show_bug.cgi?id=6775
--
Pek
s a lot of other junk
that hosts spew out anyway (e.g. some won't like similar Bonjour
multicasts). If this is truly a problem, we could try to figure out
solutions for that, e.g. by tweaking the retransmissions or giving
operational guidance for filtering in switches / access
? I'm not seeing it. IPv4 has (AFAIK) the same
constraints except that IPv6 has link-local addresses and you actually
don't need any prefix at all unless you attach hosts to the link.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy
v4 prefixes (or addresses in
degenerate case) for each VLAN-capable router interface today, so I
fail to see how this argument would apply to IPv6.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks
s problem that we see issues in the specs, we
discuss them, yet we don't track them and we don't reach closure on
how to proceed with them.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Sys
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/nd6_nbr.c.diff?r1=1.52;r2=1.53
I guess we have a problem.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Netw
I assume you refer to a scenario where on the same broadcast domain
there are hosts which are configured with say A.B.C.0/24 length, and
some others are configured with, say, A.B.C.D/28 prefix length.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy
ere are other reasons why /127 is broken (RFC3627), the IETF might
need to do something.
Workarounds are at least using distinct /128 addresses and static
routes or a routing protocol or just link-local addresses.
--
Pekka Savola "You each name yourselves king, yet the
Netcore O
So - by all means, please open a TAC case.
>
> As a workaround, we have used "ipv6 nd dad attempts 5" on the specific
> line that gave us headaches - so we've never pressed the issue with Cisco.
>
> gert
>
&
t is responsible for
re-injecting a new packet:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg50634.html
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds.
to do so (e.g. by default address selection choosing to use
IPv4 instead).
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--
s where exactly the
same problem appears in addition to many scenarios which are usually
due to misconfiguration. I believe our protocols should be robust
enough to cover both valid scenarios and (if there aren't major
drawbacks) common misconfigurations.
--
Pekka Savola "
FYI,
While we're considering RFC3484 changes, here's one additional
proposed modification to RFC3484 for Linux with ORCHID (RFC 4843) that
is worth serious consideration. (Discussion on the best
implementation choice(s) and glibc changes is still going on.)
One may debate whether ORCHID addre
ication as necessary.
Instead of leaving each vendor in the dark and invariably doing lots
of corner cases wrong.
Maybe the critical thing that has been missing in the RFC3484
discussions has been "have vendors already fixed this? how? which
approach has worked and which not?"
--
Pek
FYI,
While the default router "persistence" is an interesting observation, the more
interesting one is why the default address selection algorithm pick
source,destination pair of v6:{link-local,global} which is almost certain not
to work instead of v4:{site-local,global}
(ietf-464nat is using p
product to be
"RFC4294 compliant", "RFC4301 compliant", claim it supports IPsec, or
claim it's "RFC" compliant (where corresponds to an RFC
number which mandates IPsec). That's all.
The product also might not get IPv6 ready logo certific
and OSPFv3 is as good an option as any".
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
-
h it
currently doesn't have any IETF consensus behind it (it's just an
informative list of some RFCs somewhat related to IPv6).
Some might say the current state is somewhat problematical and making
a superficial update without fixing the root problems could make the
matter even
n is proposing a solution in (mostly) simpler
scenarios which are typically unmanaged. A default policy, if such
could be created, shipping in smaller routers could fulfill this goal.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingd
fect existing deployments) are
unacceptable or at least very strongly frowned upon.
Why do you believe ULA addresses are intrinsically not WAN routable?
Is there something I'm missing?
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy
hat if a ULA(-C) site would have no global addresses
whatsoever, reverse-DNS delegations can't be done.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George
d that the
authoritative DNS servers have non-ULA addresses. I think Mark was
assuming that ULA address for authoritative delegation point might be
OK, which would lead to issues if the ULA address is not reachable
from everywhere where reverse DNS lookups should succeed.
--
Pe
deploy, the more likely it is that
it breaks something especially given that most firewall/ACL
implementations have restrictions on which RHs it can see.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Netwo
ckets to the slow path" is one primary
thing that a high-speed router should not have to do. I think I'm not
alone in the operator field with this sentiment.
Oh yeah, hop-by-hop extension header should be retired as well :-)
--
Pekka Savola "You
upstream/etc. borders. Having
such ACLs prevents almost all RH0 looping abuse. (There is a scenario
Gert Döring mentioned where you loop between backbone routers within
the target organization but that can be eliminated by disabling RH0
processing in that organization's routers
is that Section 4 only specifies the behaviour of the
EFO option (three MUSTs) on transmit. The behaviour on receipt
(particularly when those MUSTs are ignored) is unspecified.
I believe also the RA Option Bit 55-56 under IANA considerations
should be 54-55 (56 be off by one bít?).
--
Pekka
OK to
accept a registration. As the draft cites 'exceptional
circumstances', maybe a higher bar (e.g., IETF consensus or Standards
action) would also be possible.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds
w ingress filters could/should be more
source-routing friendly.
In either case, I believe currently deployed ingress filters will
practically block bouncing attacks with rh0 or ipv4 source routing.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy
However, I agree that the current wording could probably be better.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
t worried about
attacks of that caliber as O(100Kpps) and O(1Mpps) attacks are already
commonplace with existing methods.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R.
of an
address inside the subnet where the attacker is, but I don't see this
as a very useful attack myself because it'd be more effective to
attack directly.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Sy
, it shouldn't discuss the mitigations either. (Both of
these are potential ratholes that we should avoid.)
With regard to IPv4, ADs seemed to feel that it should be addressed in
a separate document.
--
Pekka Savola "You each name yourselves king
On Wed, 16 May 2007, Vlad Yasevich wrote:
As part of the deprecation effort, does it also make sense to
update RFC 3542 (Advanced API) to remove the references to Type 0
routing header?
Dunno about that, but I guess an Updates: 4294 (IPv6 Node
Requirements) would be in order.
--
Pekka
bility will turn out for the good after all if
it means better BCP38/84 deployment :-)
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George
rently deployed support routing-header type matching (I
believe some recent Cisco IOS versions, on some platforms, support
type matching but those are typically deployed at the edges if even
there yet). I don't know whether such a change in the ACL lookup
"depth" would be feasible o
;t think it's necessarily a bad idea to have two
drafts. That way the WG can probably choose better which approach to
pursue.
[[ Personally I don't have a strong opinion whether we should disable
or deprecate. Any rough consensus works for me.. ]]
--
Pekka Savola
wide use, and still cause problems for
ingress/egress filters, I'm also ok with deprecation.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--
. No experimental spec can do that. If DISCOVER is to be
revived it will need to use one of other publication processes.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Marti
other protocols what we have defined as constants could
very well have been defined as suggested default values (for
example).
This is more than strictly required for interoperability.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy
y addition.
Any thoughts?
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
IET
s do seem to have a place.
But if we're going to change the spec, I'd even go as far as suggest
lowering the default to say 60 or 100 seconds.
I suggest we stay with the current text.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy
it"
would be helpful in that dialogue.
It'd be even more helpful because folks could be pointed to it (or
could find it themselves) before the issue even arose at the end of
the process (when it's usually much too late to fix it in any case).
(FWIW I'd like to see a simila
probably a
lot of other things that the IETF and its participants could be
doing).
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R.
this text.
If the text has little relevance, then I don't see why it needs to
change. AFAIR, it was significantly debated, and reopening that
discussion might not be the best use of our time and energy.
--
Pekka Savola "You each name yourselves king, yet
good motivation for the change), given that the document has
already left the WG quite a while ago.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A
r requiring other form of identification (e.g.,
TSIG) instead of addresses. In practice, I doubt such authentication
would be used very often.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy
K any global IPv6 addresses
from being received (in DNS packets) from _outside_ the site.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A
se the 'matching scope' tweak.
Do we need to specify that v6 ULAs should be treated as "site scope"
for the purposes of default address selection, or something else?
Note that I do not believe it's sufficient to require that each site
(and each host within the s
ether the RFC-editor would
even accept it as errata.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
ed to discard NI Queries to
multicast addresses other than its NI Group Address(es) but if so,
the default configuration SHOULD be not to discard them.
Please respond by 01/31/06.
Regards,
Brian
--
Pekka Savola "You each name yourselves king, yet the
where you are based:
How long you have been based in that country:
Uhh, I'd go over the research methology again if I were you; mining
information out of whois should be your friend...
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy
d IKEv2, and both old and new IPsec architectures. Even though the
old ones are now obsolete, I'm not going to remove the support and
text on the obsolete ones.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Sys
nd then sending
individual NIQ's
- looking at the ND packets that fly by
- etc.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks.
implementations listed there are even maintained anymore.
The detail level of the implementation and interop report doesn't seem
useful enough in deciding whether the full spec has been implemented
and tested or not.
--
Pekka Savola "You each name yourselves king, yet the
1 - 100 of 408 matches
Mail list logo
