for
addresses with same IID part from the DAD, IIRC (need to check
minutes). if my memory is corret, my guess is that the node
requirement is more up-to-date on this issue.
itojun
IETF IPng Working Group Mailing List
IPng
be OS dependent.
If
csh mickeyfinn fe80::1%eth0
How did the user know to use eth0 (That is the issue.)
Lets just discuss the above for now for clarity?
LLMNR (or icmp6 node info query).
itojun
IETF IPng
address SHOULD NOT be on public
DNS database. i have already asked the author of
draft-ietf-dnsop-dontpublish-unreachable-03.txt to include the text,
and it is included.
itojun
IETF IPng Working Group Mailing
position.
where should we send the nominations? [EMAIL PROTECTED]
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp
router issues, and (lack of) routing protocol
functionality to handle it
therefore sooner deprecation is better.
itojun
PS: each of the items are summary of discussions we had before, to my ears,
don't try to comment on each items please. the point of the email is
the very first
(but on-link)
address?
to say it backwards, for the ICMPv6 redirect to work correctly, nexthop
address on the routing table MUST be link-local (even when manually
configured). i think adding this text clarifies the concern.
itojun
i'm using the latter definition, and i guess you are using former.
multilink subnet folks are using the former.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http
This is not a problem (IMO): the problem is that certain global addresses
are *also* on-link, but cause issues with redirects.
so i suggest replacing next-hop must be onlink with
next-hop must be link-local.
itojun
On the contrary, maybe, providing a /48 while having a /32 as an
ISP makes NAT coming as a solution, according to the potential
number of customers... and, for sure, I do agree that we have to
make NAT silly.
ISP can ask for more address to RIR when they have got 2^16 customers.
itojun
Do you implement queries with a name as subject using the multicast
hash?
If yes, did you find this useful?
KAME implements stuff with multicast address with hash(hostname) at the
tail, but i don't think many people are using it (= we don't find it
useful).
itojun
).
KAME does not do it.
itojun
PS: KAME folks, any clarifications/corrections are requested.
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive
to decide whether or not to respond to node addresses
NIQ (Qtype=2) - we may not want to reveal address on
other interfaces when A bit is present, like intranet
side of firewall machine
typo: Qtype=3.
itojun
in multiple ways (DNS lookup, can't use as referrals,
leakage, just like site-local), so technology that needs distribution
of policy table is not recommended.
itojun
IETF IPng Working Group Mailing List
IPng Home Page
of the domain, therefore i think
recommendation like SHOULD filter is too strong. how about
may want to filter or something like that?
itojun
IETF IPng Working Group Mailing List
IPng Home Page
I don't see the need as long as the result is 16-bits, but would like to
see if there are other opinions.
My opinion would be to reject more than 4 hex digits.
same here.
itojun
IETF IPng Working Group Mailing
register PTR record
by DNS dynamic update, for instance.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp
playground.sun.com (IPv6) is unreachable. please fix.
it is highly annoying that IPv6 side is unreachable while IPv4 side is
alive. please integrate IPv4 side and IPv6 side, or terminate IPv6
side if it cannot provide a stable service.
itojun
(= increased cost of IPv6 transition).
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct
) on the interface? DIID does not
work in practice.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
if machine A is
autoconfigured with prefix P::/64 and DAD-safe link-local address
fe80::ID, the other end could configure P:ID intentionally.
itojun
IETF IPng Working Group Mailing List
IPng Home Page
AI_PREFER_SRC_NONCGA
= why _SRC_ ?
I don't understand how can flags to getaddrinfo(3) affect source
address selection. where does it take effect in the following code?
itojun
error = getaddrinfo(host, serv, hints, res);
s = -1;
for (ai = res; ai; ai = ai-ai_next
, so getaddrinfo(3) cannot perform
[gs]etsockopt.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub
be supported as specified in RFC2462 section 5.4
for non PPP links.
Comments?
for link-local address RFC2472 exception makes sense, but for others
it does not. i'd say keep node-req text as is.
itojun
IETF IPng
.
i don't think so. you can say the same thing about routers -
one would want certain router to be able to inject certain routes only,
not the default route/whatever. there's no such protocol available
today. (s-bgp?)
itojun
vote for simpler implementation, therefore vote for very limited
site-local address usage.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive
equipment on the ISP side.
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
authentication encapsulation/extension header, it is authorized).
do i need to be more clear on such trivial thing? if so, how?
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http
);
so mozilla tries to connect to IPv6/v4 dual stack destination, it
would try to connect to IPv6 only. it has to be fixed by using
getaddrinfo(3).
itojun
IETF IPng Working Group Mailing List
IPng Home Page
Mozilla is going to fix this. Part of the problem was we took so long
getting rfc 2553 updated to new RFC (its in the RFC editor queue now)
they used Richard Stevens old program model. This will be updated to
getaddrinfo and I agree with Itojun. Now as usual we await release
updates :--) We
call customer support regardless
from the protocol type they're using. IPv4 or IPv6. there's no
difference.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http
of the full
2000::/16 for something else.
I'd rather reserve a documentation prefix somewhere else, and in some
other, _separate_ internet-draft.
there have been multiple attempts made to reserve address space for
documentation, including:
draft-itojun-ipv6-local-experiment
to routers, and why anycast can be used with limited number of cases
(like for instance it shouldn't be used as TCP endpoint address).
draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt
itojun
IETF IPng Working Group
they're using, but anyways)
if any of you have contacts in linksys/netgear, we'll be more than
happy to help them out/do some clue injection. so let me know.
itojun
IETF IPng Working Group Mailing List
IPng Home Page
, no real deployed codebase...
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
if we ship c.e.f.ip6.int/arpa zone files with BIND,
just like 1.0.0.127.in-addr.arpa?
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive
.
ok, then (1) we need 3041bis, and (2) node requirement may want to
refer dupont-3041harmful too.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
i think MAY is fine. conditions where the spec is appropriate
are spelled out enough in RFC3041.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
, but it is recommended to use at most 16-bit subnet IDs,
for convenience if the site is later connected to the Internet using a
global prefix.
i'm happy with the change.
itojun
IETF IPng Working Group Mailing List
IPng
.
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
to:
- limit nodes from joining more than (including) 2 sites at the same
time.
- document site-border router's behavior in full
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http
to, what
are you going to do? or what if you get 2001:240::/32 from both sides,
what are you going to do?
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com
are implementing link-locals properly, it's really very little
additional code to support site-locals. At least that's my experience.
could you comment on routing code? (RIPng, OSPFv3) i still think
it's way too tough to support multi-sited node.
itojun
a bit concerned about the use of scoped address in general,
as it will cause confusion when scoped address leaks out of site
in application payload (like email foo@bar@baz notation or whatever).
but i feel it too late to kill it.
itojun
sharing (like having 400Mbps bandwidth rather than 100Mbps)
yes.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp
the client.
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
Anybody giving online IPv6 classes?
http://www.soi.wide.ad.jp/ has some IPv6 tutorials online.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive
of RFC2292.
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
should
forbid the use of the address in an extension header. That is
for the extension header to define.
in which kind of extension header IPv4 mapped address make sense?
certainly not the extension header.
itojun
Jun-ichiro itojun Hagino wrote:
Secondly, I don't think that the addressing architecture should
forbid the use of the address in an extension header. That is
for the extension header to define.
in which kind of extension header IPv4 mapped address make sense?
certainly
based on v6ops interim meeting discussion, it seems that there are fair
amount of consensus that IPv4 mapped address on wire is harmful (causes
security drawbacks).
draft-itojun-v6ops-v4mapped-harmful-00.txt
so, i would like to ask you to update draft-ietf
-nat46 draft.
draft-ietf-ppvpn-bgp-ipv6-vpn-02.txt
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub
and unauditable tcp/udp/pcb
layer). it seems right for shortterm porting, but it actually hurts
people in long term.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com
i have another input to IPv6 addressing architecture, which is
very securty-sensitive. please review and integrate it before
publishing the next one.
draft-itojun-v6ops-v4mapped-harmful-00.txt
itojun
---
4. Suggested protocol change
o In IPv4 address
.
then your device will have trouble operating on coming switches
that support MLD snooping, and it will be very difficult to
track the issue down (extraordinary support load to your colleagues).
i suggest you to follow RFC2710.
itojun
description
in page 3 much shortened to avoid (possible) inconsistencies.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp
be disabled by default.
Would this address your concerns?
looks great!
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp
to have the proper effect?
(That is, to explicitly allow deprecated addresses to be used, other
than when it is a toss up which address to use).
Do we currently have a 2462 bis draft?
here are my proposed changes.
itojun
RFC2462
page 3:
in arbitrary communication is unrestricted. Later
.
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 PROTECTED]
(to avoid FTP bounce attack). therefore, FTP client
side shouldn't use temporary address for the control connection.
(apparently, server side shouldn't)
itojun
IETF IPng Working Group Mailing List
IPng Home Page
i guess you are confused.
But that doesn't mean that we break/refuse existing communications
earlier than we need to to achieve that.
i have never said we should terminate existing connections. i suggested
we should refuse new incoming connections (TCP SYN).
itojun
guidance
to incoming TCP SYN case, and
- we should drop incoming TCP SYN to deprecated addresses.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP
, ping6 ff02::1,
whatever). i don't agree with Pekka's take.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp
disruption.
this may be an implementation issue, but who should decide it?
in KAME case we have kernel code which forbids the use of deprecated
address as a source (bind(2)) and FTP daemon cannot override it for
data connecdtion.
itojun
prevent any new communication from using a
|deprecated address, but system management MUST have the ability to
|disable such a facility, and the facility MUST be disabled by
|default.
new communication isn't clear enough, IMHO.
itojun
|this may be an implementation issue, but who should decide it?
It was already decided long ago. The doc may need to be made clearer.
who means userland, or kernel.
itojun
IETF IPng Working Group Mailing List
this is an implementation bug: deprecated != invalid.
latest KAME tree permits bind(deprecated address), while older tree
(like *BSD) does not. i'll need to dig commit logs again to understand
the reasoning for the change (maybe i made the change and forgot).
itojun
TCP data connetion with EPRT (IPv6 PORT), we can't make it as we are
forbidden to make TCP connection with deprecated IPv6 address as the
source.
itojun
--- tcp_input.c
/*
* If deprecated address is forbidden
does.
*BSD and derived implementations don't (MacOS X at least, and probably
JunOS and ExtremeWare).
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
Do such implementations which have problems with 64KB packets need to be
able to use tunneling?
yes. think of small devices like DSL routers at home. they terminate
tunnels, and have severe memory limitations.
itojun
. it will have negative impact to IPv6 PMTUD.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct
of the paths could be IPv4-only
of course) while IPv6 (over IPv4) is one-hop.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive
supports the larger MTU.
with the cost of complexity in tunnel endpoint implementations (needs
to maintain IPv4 path MTU and reflect it to IPv6 tunnel link MTU).
i would really like to know how many of existing implementations follow
this part of RFC2983.
itojun
in
the IPv4 header. if you do this, storing the state
is not really complex I guess.
if you don't set DF bit on IPv4 packet (after encapsulation),
it is not mandatory to convert ICMPv4 to ICMPv6 (actually, you won't
see ICMPv4 need fragment). simpler the better.
itojun
the following error messages
baja{shroff}% gcc tcp_connect.c -lsocket -lnsl -lresolv -lc
tcp_connect.c: In function `tcp_connect':
i guess you are using Solaris, but which version?
#include netdb.h should be enough for pulling defs for struct
addrinfo.
itojun
,
so that we can help traffic analysis/diffserv researchers.
(they can't correlate traffic due to the use of ESP, or SSH)
draft-itojun-ipv6-flowlabel-api-01.txt has more details on it.
itojun
IETF IPng Working Group
quite parse it.
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
configure a new additional ID = I do a DAD for 4 new addresses. Do I do
them in parallel or do I have to do them one after another?
you can do them in parallel.
itojun
IETF IPng Working Group Mailing List
IPng Home
. my preference
is to run full DAD (will take 1 second or so), for every address
assigned to the node. the rule is simple - run it for every address
you assign to the node, that's all.
itojun
IETF IPng
-ipngwg-ipv6-anycast-analysis-01.txt).
read draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt for more on this
topic.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http
.
IPsec (AH/ESP) doesn't work here. do you have any proposal?
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com
Wouldn't it be much much simpler just to do DIID? I see zero reason for
e.g. PRFX1::1/64 and PRFX2::1/64 being assigned on two different nodes in
a same subnet.
i see zero reason for prohibiting the above configuration.
itojun
no, the device answering ICMPv6 request is not named.
??? I'm a bit confused. Are you saying that we can *not always*
assume the device answering ICMPv6 request runs a name server?
the thread of email assumes the following diagram.
itojun
client resolver - named
a TCP SYN on an anycast address,
today it apparently has to silently drop the SYN, and the other
end can't tell why.
No existing ICMPv6 error message applies to this case.
draft-itojun-ipv6-tcp-to-anycast-01.txt proposes to use addr unreach
(code = 3), but i'm happy to see a new code
situation) to me. IPv6 is not a toy in your lab any more. we have
people depend on it, we have serious IPv6 commercial network operation.
i suggest to leave the SHOULD/MUST decision to jari, the main editor.
itojun
think host would configure
secure channel to untrustworthy resolver?
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp
if they are unknown to them
(otherwise we cannot allow future extension - old implementation
will not be able to talk with new implementation), but i could be wrong.
anyways, the above is not the main focus of this discussion.
itojun
---
Sub-Options
Additional
18 is trying to mandate new thing to all IPv6 (RFC2460) implementations.
SHOULD for HAO is okay for me, but MUST for HAO is unacceptable at
this stage of RFC2460-based IPv6 deployment.
itojun
IETF IPng Working
does not have the private key.
client resolver - named --- the target
DNS queryNI query
client resolver - named --- the target
DNS response NI response
itojun
chairs,
i would like to get some guidance on how to proceed with my document
draft-itojun-ipv6-nodeinfo-revlookup-00.txt. i would like to publish
it as an informational/experimental RFC. which wg is appropriate,
or should i pursue it as individual submission
the above. quick-and-easy implementation
that calls gethostbyname() from within getaddrinfo() would behave
like you have described.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http
try to think more about how i should provide user
override for flowlabel values.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive
the change included in draft 19. thanks.
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
it is nice to consider legacy nodes. But software upgrades
are also very routine. I dont have a machine which is running
the earliest version of Windows/FreeBSD/Linux/..
i don't think i have the same definition for legacy with you.
itojun
chairs,
i would like to get some guidance on how to proceed with my document
draft-itojun-ipv6-nodeinfo-revlookup-00.txt. i would like to publish
it as an informational/experimental RFC. which wg is appropriate,
or should i pursue it as individual
as mentioned in the meeting, we've submitted this revision to address
IESG comment. I don't feel the need for another WG last call, so
please send it forward to IESG. thanks.
itojun
IETF IPng Working
to do that, and it gets very messy. that is the
reason why my draft does not provide ways for apps to pick the value.
In any case,
draft-itojun-ipv6-flowlabel-api-01.txt will have to be reviewed after we
reach consensus on draft-ietf-ipv6-flow-label
yes, that is why it is expired
handling (mobileip)
if they want to mandate it, they have to set it in stone NOW.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive
to be able to indicate that it wants to use *a* flow
label?
I can see the flow label management issue being more efficient in
the IPv6 stack itself.
FYI, draft-itojun-ipv6-flowlabel-api-01.txt provides no way to
set flowlabel value from the userland. the (sending) kernel decides
a proper scope support
- IKE implementation must have a proper scope support (ID payload
handling gets very tricky)
- automatic keying with IKE is impossible for multicast case!
to summarize, just saying use IPsec is not enough.
itojun
- that
they are unix-ish design. default-addr-select is a protocol document,
as far as i understand.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP
1 - 100 of 304 matches
Mail list logo
