answered that question in the past:
draft-itojun-ipv6-local-experiment-02.txt
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive
. they will leak.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests
set up DNS PTR records that returns
www.ietf.org. Similarly, anyone can respond with ICMPv6 node
information reply with www.ietf.org.
itojun
IETF IPng Working Group Mailing List
IPng Home Page
if it is not stable) that can be
added. Independent of that some more explanation of how it's been used
with http would be helpful.
interdomain. single prefix advertised with a single AS #, from
multiple different location (route injected into multiple different
ISPs).
itojun
heard this.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests
-local only), on p2p link. both works just fine.
i assign /64 global prefix when we need to monitor router p2p interface
from remote (by ping6), for instance. in other cases, i don't
assign /64 global addess prefix.
itojun
condition holds, traceroute6 work fine.
- intermediate routers are using weak host model
- intermediate routers have at least one global address
itojun
IETF IPng Working Group Mailing List
IPng Home Page
to the
remote neighbor address.
checking - unnumbered meaning link-local address only, am I
correct? yes, p2p link without global address works just fine.
itojun
IETF IPng Working Group Mailing List
IPng Home Page
/64 for p2p link. it works just fine, it supports
temporary address (RFC3041) if you desire, i can think of no reason to
use somethiing other than /64.
itojun
IETF IPng Working Group Mailing List
IPng Home Page
(lowermost 32bit used to relay IPv6 TCP session to IPv4 TCp session).
Regardless of how it works, it's one of many ways for a
site-local-addresses-only node to get external connectivity.
yes.
itojun
IETF IPng Working
-local IPv6 address at least for ND. use of
link-locals within zeroconf environment needs further study.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP
with/
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL
the venue.
http://contents.pr.v6pc.jp/apwg/en/event_sr01.html
(IPv4 only right now, should be reachable over IPv6 soon)
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http
no need for protocol modification, since there will be no
interaction between routes in site A and site B.
NEC IX router is the only implementation supporting this, as far as
i know (i'm a bit embarrassed, KAME doesn't handle this - yet).
itojun
routing protocols? Do you know anyone
on this team? Could we get them to describe how they handle the site border router
case
in detail?
they should be on the list so they should be able to comment.
itojun
IETF IPng Working
and was not able to produce
the text. If there is interest, I could see about writing
something up.
yes, i'm interested in having SCTP section. i'll need to update
the i-d anyways...
itojun
IETF IPng Working Group
for link-local multicast groups, default routers
won't be able to know which multicast group the 3GPP node is
interested in. there's no special text available in RFC2710 for
p2p links.
itojun
IETF IPng
things up...
the former paragraph speaks about discovery of DNS server, the
latter paragraph speaks about name resolution under environment
without DNS server.
itojun
IETF IPng Working Group Mailing List
and such, a /64 prefix out of fec0::/48 range will be added too.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp
prefixes because we were
multi-homed. so pls do not assume that there's single subnet prefix
on a link.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
the future operators will do, so it is safer
not to make assumptions.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp
argument
then become subnet-local prefixes.
i don't think it necessary to do anything about DAD. we perform DAD
(not DIIDD) for all addresses assigned, and we will be fine.
itojun
IETF IPng Working Group Mailing List
My guess is that it will just effectively mean people will not
use multiple prefixes for mobile nodes.
i guess so too, and therefore, i don't feel a need to provide
special hack in DAD. it is not a protocol issue, but an operational
matter.
itojun
that drastically change content every time the new version appears.
even if that technology is a good one, this way that won't deploy.
itojun
IETF IPng Working Group Mailing List
IPng Home Page
Do we allow unidirectional tunnels ?
if my understanding is correct, RFC1993/2893 describes unidirectional
tunnels, however, most of implementations in the wild implements
bidirectional tunnels.
itojun
/64).
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests
= Do you mean that MLD is used for the ALL Nodes mcast
address ofr example?
yes.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive
capability.
even under the above situation, there's no such clause that permits
omission of MLD in RFC2710 (MLD). if you have any reference please
let me know, i'm interested in knowing the rationale for the claim.
itojun
wireless link for
packet to ff02::blah. i believe MLD support has benefit to the
situation.
itojun
router
|
|
3G mobile node
IETF IPng Working Group Mailing List
IPng Home
|
H2R--- H1
If only H2 joined, doyou assume that the router will
send it to H1 as well? Why?
Note H1 and H2 do not share the same link.
i was trying to think about packets originated from R. not the
forwarding case.
itojun
to
shorten deadline?
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative
is your question?
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests
will not change
even if we change ethernet cards.
i would register (B) to DNS forward mapping. sometimes I register
(A) too.
itojun
rtk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
address: 08:00:74:50:44:1e
media: Ethernet autoselect (none
works just fine. otherwise, icmp6 redirect will
take care of it. so there's no issue.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive
is consistent with currently-practiced IPv4 anycast (or,
unicast address assigned to multiple nodes), like those documented in
draft-ietf-dnsop-*-shared-root-server*.
itojun
IETF IPng Working Group Mailing List
IPng
).
Generally, hosts already support MLD/IGMP in order to join multicast
groups, so why require them to run a routing protocol?
at this moment no client implementation issues MLD join for
anycast address, so it is a large change to make.
itojun
think it okay)
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests
?
in my opinion, required if you support multicast-capable medium.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp
infrastructure.
(like MacOS X shipped with NTP server configured to time.apple.com)
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive
measure.
if RFC2460 recommends something like anycast address can be used
only for short-lived sessions, it looks weird.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http
responses every day at this moment).
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all
(Now that I mention it, perhaps DHCP relays ought also to be replaced
by the use of a well-known, site-local anycast address.)
question i have is, can we really depend on availability of multicast
routing infrastructure in a site. there are lots of proposals that
assume
RFC2473: Generic Packet Tunneling in IPv6 Specification
i have a couple of comments on this document. i'd like to see these
addressed before this document proceeding further.
itojun
- tunnel encapsulation option (4.1.1, 5.1) does not seem to be widely
implemented/operated
in the document, regarding to transition
from ip6.int to ip6.arpa? for example, i think client resolvers should
do
try blah.ip6.arpa;
if (not found)
try blah.ip6.int;
as there are name tree populated on ip6.int.
itojun
In IPv6 fragmentation is prevented by intermediate routers. Only sender can
fragment IP packet.
Why so? Do we have any extra advantage because of this.
simpler router implementation (= hardware routing acceleration easier
to implement).
itojun
, as it is
supposed to be stateless (oops, this word again).
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com
over multicast and
do not define its own security mechanism. i wonder how many
implementation can do this. IPsec over multicast is, i would say,
hard (not to mention automatic key exchange).
itojun
IETF
sorry for the noise to the list, but IPv6 side of
http://playground.sun.com/ is down. we should unify the servers...
itojun
itojun[starfruit:~] telnet playground.sun.com 80
Trying 3ffe:8130:d000:0:a00:20ff:fe7b:645...
telnet: connect to address 3ffe:8130:d000:0:a00:20ff:fe7b
is not set.
btw - it is still unclear to me if administered (stateful) mechanism
mentioned in RFC2461 is DHCPv6, or some other protocol.
it is not explicitly stated anywhere.
itojun
IETF IPng Working Group
the current situation.
btw, i'm not scheduled to attend.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com
clients in customer's site to DNS server in the ISP.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub
autoconfiguration
protocol [...]
you have changed should into MUST. any reasons why? what happens
if a host does not have stateful autoconfiguration protocol
implementation?
i think SHOULD is fine.
itojun
, cellular host can omit AH and ESP.
so, I believe it okay for cellular host to omit AH/ESP, if needed.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP
that the -03
behavior is simpler is any respect.
the major problem I'm seeing for -02 definition is that there's no
relationship defined (impossible) between the normal TCP data stream
and ancillary data segments. I personally in favor of -03 definition.
itojun
into the
TCP data stream portion, -03 definition looks more simple. there's no
real need to put extension headers to ancillary data.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http
that works for multiple ISPs.
itojun
---
Requirements for IPv6 dialup operation / Jun-ichiro itojun Hagino
draft-itojun-ipv6-dialup-requirement-01.txt
-
[Slides available at http://playground.sun.com/ipng/meetings.html
draft-ietf-dhc-dhcpv6-11.txt to 20).
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all
).
I don't have a strong opinion either way.
I don't feel the need for consistensy among 2292bis setsockopts.
-1 should be fine for setting the default value for IPV6_HOPLIMIT
and other integer setsockopt.
itojun
Hello, every one.
I have installed apache-1.3.19-5.src.rpm(with
apache-1.3.19+IPv6.spec) and
mozilla-i686-pc-linux-gnu-0.9.5.tar.gz refer to Peter
Bieringer's linux IPv6 beginner's guide in WowLinux
7.1.
But I cant't access the apache server with mozilla by
IPv6 address, although I can access it
? (EINVAL? EOPNOTSUPP?)
what should happen for getsockopt(IPV6_ICMPV6) on ICMPv6 socket?
- always return 2?
- raise error (error code?)
itojun
IETF IPng Working Group Mailing List
IPng Home Page
http://www.iana.org/assignments/icmpv6-parameters
ICMPv6 type 0 is still unassigned. does it make sense to mark it
reserved, so that noone will use it? if so, how can we do it?
(for ICMPv4 it was assigned to echo reply)
itojun
So, if someone could summarize the conclusion of the die-hard-only
flowlabel discussion, I would love to hear that. (in my understanding
it wascomplete lack of consensus, am I correct?)
Just curious as I'm feeling a bit of responsbility for
draft-itojun
that the unassigned region is
unicast addresses, not just unassigned.
otherwise, implemnters cannot implement the code to handle these
future allocation addresses. in my understanding this is the
main reason for the wording change between RFC and i-d.
itojun
I've read draft-itojun-ipv6-dialup-requirement-01.txt,
I thought that we must discuss IPV6CP options.
in my analysis and past history, IPv6CP option for assigning address
space has been discussed and rejected (i guess i mentioned the history
in the draft). this partly
draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub
there?
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL
/MAY for this.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests
As I think that no standard should be excluded, I think that IPv6 WG
should do its best, to make IPv6 work well, friendly with MPLS. Which is
in a way [a subset of a)]+c).
could you describe [a subset of a] + c in more detail so that
people can understand you better?
itojun
, the technique is just for short-lived transaction, just as
stated in the draft.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp
if end nodes use ESP, he would liked to identify a
flow from other flows. So, he wanted us to attach unique pseudorandom
flow label per flow. This leads us to (b), and that's one of the
reason why draft-itojun-ipv6-flowlabel-api-02.txt is based on (b).
It is true
of getaddrinfo/getnameinfo behavior,
and it is outside of the scope of sin6_scope_id semantics discussion.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP
I think the WG needs to decide once and for all whether the flow label is
a) a CATNIP or MPLS-like routing handle
or b) a QOS hint for intserv only
or c) a QOS hint for intserv and diffserv
or d) a waste of bits
(b).
itojun
generated and cached, the risk
of high-jacking it, is NOT DIFFERENT than with the non-pseudo-random
flow label value.
I believe there's substantial difference, but okay, I got your point.
itojun
IETF IPng Working Group
between IPv6 end node and nameservers. your assumption does not hold,
especially during the transition period. because the assumption
does not hold, zone admins need to maintain records too.
itojun
IETF IPng
, we have no worry and everyone is happy.
itojun@tired.
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
it will take, and how many people do you think
get bitten by this?
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp
don't understand what you are saying, AT ALL.
I'm not using forwarding configuration. you must have some assumption
in your head which is not presented here.
itojun
IETF IPng Working Group Mailing List
IPng Home Page
of
the IPv6 DNS transport (as NS records need to point to , or A6).
I guess you are mixing up these two.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
that,
they won't interoperate with others.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
the consensus among people. This is not intended to be left
ununsewered (What suggested you like that? Did I tell you so?
how can can you assert like that without checking with me?).
itojun
IETF IPng Working Group Mailing
routers:
I know of multiple products which implements older RFCs.
therefore, you can't just make the old ones obsolete (you cannot
reuse codepoints).
itojun
IETF IPng Working Group Mailing List
IPng Home
.
itojun
- Avoiding ping-pong packets on point-to-point links
draft-ietf-ipngwg-p2p-pingpong-00.txt
10min to 15min
- Requirements for IPv6 dialup operation
draft-itojun-ipv6-dialup-requirement-01.txt
10min to 15min (changes only)
- An analysis of IPv6 anycast
draft-ietf
meetings, and i'll be in
term room all night:-) so it should be quite easy for us to meet up.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive
such infinite iteration of icmp6 errors, because the source
address of the error packet from Router B would P::b, which is
a perfectly legal address. We would only see one more error.
to illustrate the situation better, it should be like this.
(correct me if I'm wrong)
itojun
.
am i confused?
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests
.
itojun
2.1 RFC1981 - Path MTU Discovery for IP Version 6
If Path MTU Discovery is not implemented, then the uplink packet
size MUST be limited to 1280 octets (standard limit in [IPv6]).
However, the cellular host MUST be able to receive packets with size
up to the link MTU
Referring to the above RFC(2374);
you may want to check RFC2772 for current 6bone operation guidelines.
What about 'host-route' advertisement?
are you suggesting to have 2^128 routing entries worldwide?
itojun
design 2292bis to follow the new header ordering constraint.
just a meta-thought.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive
are
assuming a couple of things beyond documented, like when bind(2) should
fail (it is also not documented).
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com
and ETSI and ask folks at Sun to test for this at
Connectathon. KAME should be pretty much ready to test this too.
http://www.kame.net/dev/cvsweb.cgi/kame/kame/kame/bindtest/
checks this case.
itojun
IETF IPng Working
.
Thank you to Itojun for reporting a problem on the machine, it is now fixed.
I have a very serious request. for those of us who constantly use
http over IPv6, it is very very annoying to see non-synchronized
content (imagine how you feel when you look for some document
privately if you prefer.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative
- the implementation has IPV6_V6ONLY as specified in the draft
- the implementation has a BSD style SO_REUSEADDR
?
IPV6_V6ONLY is a good thing, but there still are items unclear.
please re-read drafts with fresh eyes, and you'll find out.
itojun
on the same port. some
systems reject bind(2) to 0.0.0.0, some does not.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp
.
i never suggest IETF to document platform differences.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp
that? Dave Thaler and i preferred no default at some point.
in fact it was about 6 to 3 ratio in favor of v6only not being the
default. or if there were 9 people only 3 wanted what you want.
at least the sentence conflict with the above no one.
itojun
to
handle IPv4-mapped IPv6 address and the IPV6_ONLY option, for example.
aha, I was biased to independent AF_INET/AF_INET6 implementation ;-)
as IPV6_V6ONLY support is still rare, not sure if it worth document it.
thanks anyways.
itojun
, but it looked too hairy to me.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all
as ... looks to me too optimistic.
the following is KAME v6test configuration file that generates
certain packets. the following URL an (expired) draft on this problem.
http://playground.iijlab.net/i-d/draft-itojun-ipv6-transition-abuse-01.txt
let me know if you know of of realworld
with getaddrinfo(3) loop.
itojun
-- the loop fails to accept IPv4 traffic on linux.
hints.ai_flags = AI_PASSIVE;
getaddrinfo(NULL, 80, hints, res0);
for (res = res0; res; res = res-ai_next) {
s[i] = socket();
if (res-ai_family == AF_INET6)
setsockopt(s[i], IPV6_V6ONLY
101 - 200 of 304 matches
Mail list logo
