Re: RFC3678: header incompatibility
> > i'm aware of that line, but that does not really meet my observations. > > You asked that we revise the RFC to be compatible with POSIX. > I observed that the RFC is not incompatible with POSIX. Now you > are asserting that isn't what you were really asking? > > > if the above POSIX line suggests inclusion of from > > , why freebsd did not do that and defined sockaddr_storage > > in two places? > > Because FreeBSD chose a different implementation. > > Are you suggesting that POSIX is wrong, or that we were wrong to write > the spec to be compatible with what POSIX requires? Or are you saying > that we should have ignored POSIX and instead written the spec to > what FreeBSD, OpenSolaris and *BSD prefer? > (I'd note that MacOS X has a simple #include in > , so apparently it's not impossible to implement > things that way.) i see. i was not doing enough homework. sorry about that. (yup, this is not a forum to talk about posix, but...) the older version of POSIX specification did not have "may include ". http://www.opengroup.org/onlinepubs/007908799/xns/netinetin.h.html i am under impression that "may include " clause can lead to portability issues in applications - some application writers will include only and it will compile fine on some platforms, and not on some other platforms. do you have any information about when the clause was introduced? was it with the use of sockaddr_storage? itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC3678: header incompatibility
>> is included prior to , and it is not >> possible for to blindly include . > >Why not? POSIX seems to anticipate this: > >>Inclusion of the header may also make visible all symbols >>from and . i'm aware of that line, but that does not really meet my observations. - freebsd do define sockaddr_storage in and , with #define to avoid duplicate definitions. - opensolaris and other *BSD do not include from , nor define sockaddr_storage in . if the above POSIX line suggests inclusion of from , why freebsd did not do that and defined sockaddr_storage in two places? my guess is that it was a too big change to be accepted (way too much interaction with existing code). http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/in.h.diff?r1=1.99;r2=1.100 itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RFC3678: header incompatibility
not sure if it is for [EMAIL PROTECTED] please redirect it to appropriate group if needed. http://www.ietf.org/rfc/rfc3678.txt http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/socket.h.html RFC3678 defines a C structure with "struct sockaddr_storage" inside (for instance, struct group_req in section 5.1), in . however, from POSIX standard, sockaddr_storage is defined in . there is no guarantee that is included prior to , and it is not possible for to blindly include . note: types like sa_family_t are defined in , and they need not be/shall not be from . please update RFC3678 so that it will fit better with POSIX standard. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
> The IPv4 clock will wind down right after the last FORTRAN compiler is > decomissioned. Wouldn't it make more sense to put the effort into > morphing v6 into something that *IS* attractive? hope you can do that in time... (i mean, not just for the States but for the entire planet) for me, IPv6 itself is attractive enough (that's why i'm putting so much time on it). if it can lose some of the extra meat which makes it a little bit more complex than it should be, it would be super. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
> On 2007-10-11 23:46, Jun-ichiro itojun Hagino wrote: > >> Not viewed from the socket programmer's point of view. > >> Look at how an AF_INET6 socket behaves when given > >> an address like :::192.0.2.3 > >> afaik the behavior is then exactly what you describe. > >> Whether the stacks are independent code modules or > >> alternate paths through the same code is irrelevant > >> to the externally observed behavior. > > > > see draft-ietf-v6ops-security-overview-06.txt section 2.2. > > Sure. I absolutely don't like to see ::/96 on the wire. then we'd have to deprecate SIIT at least. still, you cannot be sure that :::0:0/96 are not on the wire. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
> Not viewed from the socket programmer's point of view. > Look at how an AF_INET6 socket behaves when given > an address like :::192.0.2.3 > afaik the behavior is then exactly what you describe. > Whether the stacks are independent code modules or > alternate paths through the same code is irrelevant > to the externally observed behavior. see draft-ietf-v6ops-security-overview-06.txt section 2.2. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
> On Oct 3, 2007, at 12:55 PM, Ruri Hiromi wrote: > > http://www.apple.com/jp/downloads/dashboard/networking_security/ > > ipv420.html > > well, i could imagine what its good for , but an english version > would be appreciated ;) the widget itself is bilingual (english/japanese). itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Would someone help the secretariat figure out why they cannot route to teredo addresses?
> Le Monday 01 October 2007 20:50:00 ext Sam Hartman, vous avez écrit: > > Hi. I opened a ticket with the secretariat a few weeks ago > > complaining that I cannot reach www.ietf.org using a teredo address > > either allocated through the Microsoft Teredo server or the Debian > > teredo server. > > > > This is annoying because glibc's source address selection algorithm > > seems to prefer teredo addresses to v4 addresses. So, I get really > > bad response times to www.ietf.org when using teredo. > > To make a long short, that depends on your glibc version. As far as I > remember, RFC3484 was implemented in version 2.4. Configurable policy in > version 2.5, and Teredo in the default policy only very recently. this really shows that the approaches with policy table is very against of KISS principle... itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo() and searching)
> >>it can be application-specific, without application modification. > >>check out "systrace" by Niels Provos. > >> > it's useful but it really isn't flexible enough to remove the need for > applications to be able to specify policies. i wonder how many command line options will be added to the applications once you start adding up policy stuff... sendmail.cf lookalike for every apps? itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo() and searching)
> >> I've recently concluded that we need an extension to getaddrinfo() along > >> these lines, but I'm looking for somewhat tighter and more generic > >> semantics. > >> > >> My proposal is to add an AI_SECURE_CANONNAME flag with the following > >> semantics: > > > > do not try to implement policy into applications. you will end up > > forced to (?) rewrite every existing applications. > > > perhaps, but having the policy be application-independent doesn't make > sense either. it can be application-specific, without application modification. check out "systrace" by Niels Provos. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo() and searching)
> What a timely thread. > > I've recently concluded that we need an extension to getaddrinfo() along > these lines, but I'm looking for somewhat tighter and more generic > semantics. > > My proposal is to add an AI_SECURE_CANONNAME flag with the following > semantics: do not try to implement policy into applications. you will end up forced to (?) rewrite every existing applications. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
> We have more than enough IPv4 addresses for China. no way. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
T-shirt
ok... enough conversation about DHCP and stuff... there are ways to express opinions other than writing up a draft, so here goes. http://www.shirtcity.com/shop/index.php?file_merchandising=large&actual_merchant_article_serial_number=12&backjump_page=3&PHPSESSID=7cf26a35a9ca3e0428f610587232e21b itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
> > my persistent question to the enterprise operator is this: > > how frequently do you plan to switch your isp, or how many times > > did you do that in the past? > > > > i have never got any reasonable answer from anyone. > > OK, I'll bite. Never, and never (in nearly 20 years). Although we > in effect have IPv4 PI as being an older university we came online when > getting an old Class B was easy, before IP allocations were made from > the NREN space. i would like to hear more opinion from organizations that have connected to the internet more recently. the problem i'm seeing in the ietf is (of course there are exceptions): - vocal people have class B/C for their own use so they are not really feeling the pain of NAT (and they are contributing to the bigger size of the routing table) - vocal people are not using IPv6 daily itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
> > my persistent question to the enterprise operator is this: > > how frequently do you plan to switch your isp, or how many times > > did you do that in the past? > > That's actually irrelevant. Regardless of the real answer, > enterprises are > not willing to buy into vendor lock. if the management needs to be convinced by the cost, i would suggest ISPs to price PI advertisement like hell ($$$), so that we can make the worldwide routing table smaller. it will help ISPs use smaller peering routers in the end. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
> > > Let me see if I understand this. Without PI, the enterprises say > > no, and with > > PI, the ISP's say no. Got it. > > I believe that a more constructive assessment is that enterprises are > unwilling to pay non-trivial costs to renumber, and ISPs are > unwilling to pay non-trivial costs to support a non-scalable routing > subsystem. my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? i have never got any reasonable answer from anyone. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
> > because, in the end, ULA (whichever flavor it is) leads to > > IPv6-to-IPv6 > > NAT. > > did you read the thread some months ago? There was mention ID and LOC > splitting. ULA fits that idea almost perfect. IP address, or part of it, can never be an ID. so i'm against of all of the ID/LOC separation stuff. IP address can never be an identifier because: - you can switch from one IP version to another - once you have private address/ULA of some sort, you have conflicts it is a crazy thought that you have a unique ID in the lower 64 bit in an IPv6 address. MAC address is indeed not unique - some vendors do not keep the rules. go down to hongkong/akihabara and buy cheap NE2000 ethernet cards, and you'll know. if you need to identify some node/whatever, use ssh secret key, X509 certs, and alike. IP address is just to specify communication endpoint, nothing else. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
> > because, in the end, ULA (whichever flavor it is) leads to > > IPv6-to-IPv6 NAT. > > I prefer losing some bytes in all my packets between locations using > different ULA-D prefixes to get an underlying VPN / tunneling > infrastructure. This allows me to keep things flat, i.e. pure routing. > > itojun, let's just stop using the 3 letters word. It does not exist > anymore. is it ULA, NAT, VPN or all of them :-) itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
> > http://sa.vix.com/~vixie/ula-global.txt has my thoughts on this, which > > i've appropriated without permission from hinden, huston, and narten > > and inaccurately failed to remove their names from (since none of them > > supports the proposal). in fact, nobody in the ietf intelligensia > > supports the proposal. the showstopped is that this appears to many as > > an end-run around PI, and the fear is that there's no way to prevent it because, in the end, ULA (whichever flavor it is) leads to IPv6-to-IPv6 NAT. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
> I have an application where I will have approximately 2000 hosts (many > of them virtualized) in a cabinet, and I will eventually have hundreds > of such cabinets spread around the world. (snip) i wonder - why do you require it be a continuous address space? if your device do authenticate properly with each other, you can just use IPv6 prefixes from local ISPs (PAs). itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: History of autoconfig RFCs and siblings, please?
(sorry if it gets a duplicate) > I'm inclined to believe that dual-stack provider networks are going to > be relatively rare, and may not exist at all. I think it'll either be WIDE (AS2500) and two of the major ISPs which deploy IPv6 are running dual-stack. i bet others too (Verio, Internet2, anyone?) it is not economical to run two separate physical link across the pacific ocean. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 RIR policy [was Re: IPv6 addresses really are scarce after all]
> i repeat: voice your opinions AFTER you start using IPv6 daily. > i'm tired of this guessing games by people in ivory tower. To: field was wrong. "your" was general "you". itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 RIR policy [was Re: IPv6 addresses really are scarce after all]
i repeat: voice your opinions AFTER you start using IPv6 daily. i'm tired of this guessing games by people in ivory tower. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: one example of an unintended consequence of changing the /48 boundary
i suggest ietf.org mail server to operate in IPv6 only. > > 6to4 is now widely deployed > > Is it? Can you cite any data? - Apple MacOS X implements it. i'm not sure which release started shipping it, but if it was from 10.2, there are 22 million copies around, with IPv6 enabled by default. - Apple AirPort Exterme implements it. > > The /48 prefix length is not just some knob that RIRs or ISPs can turn > > at their will.It's a constant that's embedded into 6to4 protocol > > implementations in tens or hundreds of millions of computers. > > Give me a break. Use leading zeros for the first 8 bits of the subnet > part and everything else still works just fine. so if you are running 6to4 enterprise (/48) and then get some prefix from ISP/RIR which is like /56, you would have to renumber entire subnet portion to fit into 8 bits, from 16 bits. imagine how painful it is, and imagine how it will constrain people from exiting from 6to4 addresses to real IPv6 addresses. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Internet 2.0 box Was: IPv6 addresses really are scarce after all
> > /48 PA assignments to the customer is sufficient. > > for roaming clients (like travelling laptops with PPP) there's a > > different requirement. > > > IMHO even a traveling laptop with PPP needs to be able to subnet. > I've lost count of the number of times I've needed to do this in IPv4 > but been stuck with a single /32. I have also lost count of the number > of times I've used a laptop as a router in the days when I had a /28 > routed to me. Built in NAT capability for IPv4 that allows a single PPP > connection to be shared over wireless seems fairly common these days. > We need the equivalent capability in IPv6, just without NAT. agreed, like your laptop providing connectivity for your music player (like iPod), SIP-ready phone (like Symbian phones) and such. the internet infrastructure should keep options open for the other industry player to play with. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Internet 2.0 box Was: IPv6 addresses really are scarce after all
> I think that those who believe v6 DHCP and auto-conf are sufficient to > avoid the PI or local-autonomy requirement are deluding themselves, > but one cannot prove such propositions until it is too late to prevent > the undesired outcome. > > Counter-arguments? from realworld experience in providing IPv6 services at an ISP, and as a customer of that service: /48 PA assignments to the customer is sufficient. for roaming clients (like travelling laptops with PPP) there's a different requirement. anyone who would like to comment on this topic should better have real experience in assigning prefixes to the customers :-P itojun # ipv6samurais.com: saving the world with code and sword ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Internet 2.0 box Was: IPv6 addresses really are scarce after all
> what we really need is a layer of indirection at the BGP level so that > sites can have stable addresses without having to NAT. we should rather drop "stable address" requirement by having session layer protocol (something better than TCP). itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
> >>that's true, but when link MTU is different, it gets very nasty. > > > >IEEE 802 standards do not permit variation in the link MTU > >for Ethernet. Attempts to persuade IEEE 802 to approve use > >of jumbo-MTUs (e.g. 9180 bytes + Ethernet framing) have > >consistently failed within the IEEE 802. > > ok, then pls think about FDDI-to-ethernet bridge (i guess it is also > spec conformant but there are products), and/or 802.11 bridges. non-conformant, of course :-) itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
>> that's true, but when link MTU is different, it gets very nasty. > >IEEE 802 standards do not permit variation in the link MTU >for Ethernet. Attempts to persuade IEEE 802 to approve use >of jumbo-MTUs (e.g. 9180 bytes + Ethernet framing) have >consistently failed within the IEEE 802. ok, then pls think about FDDI-to-ethernet bridge (i guess it is also spec conformant but there are products), and/or 802.11 bridges. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
caveat: i have not checked the entire thread yet, so it could be a duplicate of someone's words. > First, giving each end user a /64 means that the user can > have up to 2^^64 devices at their site/home/office. That 2^64 interface ID is picked to reduce the possibility (or "probability" if you prefer) of address collisions when we use RA. it does not need to be tied with IEEE 802 MAC address - in fact, if i were to use bridged ethernet and wireless segment, i prefer to use MD5(hostname) just for the ease of migration between wired and wireless. (i guess i would like to mention a bit about session layer protocol, but that is outside of the point) > Second, Ethernet bridging is a well understood technology > and it works just fine even with very large numbers of devices. that's true, but when link MTU is different, it gets very nasty. > Third, DHCP is a well understood technology that is deployed > at millions of sites world-wide and generally works quite well. ISC dhcp server takes like 5 minutes to reboot when it serves /16 segment, due to the re-read of /var/run/dhcpd.leases. dhcp server is a single point of failure, unless you have a replicated lease database among dhcp servers. if there's implementations or practices, i would like to know that. > Fourth, lots of folks (me included) happen to find it convenient > to use NAT between my site/house/office and my upstream provider. ks. i wouldn't re-start this religious war, but i just can mention that (1) NAT is a single point of failure, and (2) NAT is not future-proven so you have to upgrade it forever. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
> > yes, but it's unreasonable to expect a home user to not need to > > subnet. > > You're kidding, right? > > You're actually expecting folks who couldn't set up VCR timers to > configure _subnets_? ISPs ship a DSL termination box with ethernet and wifi interface to customers. naturally these interfaces should be configurd as seaprate subnets (especially when MTU are different - like 9K MTU GbE), nd they can be configured by ISPs before the box gets shipped. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
> It seems that someone in ARIN land believes that IPv6 addresses are > scarce resources that need to be carefully dribbled out to customers > according to need. The following proposal has just been formally made to > change ARIN's allocation policy. sorry, is there a URL so that i can check the entire dicussions, conclusions and status? itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
> It seems that someone in ARIN land believes that IPv6 addresses are > scarce resources that need to be carefully dribbled out to customers > according to need. The following proposal has just been formally made to > change ARIN's allocation policy. for the world peace, as long as it does not have impact to global routing table (= do not leak out on cross-AS border) it is fine. for the ease of use for customers, it is a no-no, because they would like to use /48 always. if they get /62 or something they will need to get more prefixes again and again, and/or the amount of addresses would affect the address allocation policy towards the customer network subnets. so, i would like to say "do not do this". is it too late or still possible? itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Funding (was Re: Charging I-Ds)
> How would you write documents which warn against people doing funny >things? I wrote a draft about the issues with hop-by-hop options in IPv6 >and cautioning against their use. I see that there are still proposals >coming out which depend on new hbh options? What should I do instead of >writing a draft? you can implement test tools which would scan and probe vulnerabilities. like "dsniff". itojun http://www.youtube.com/profile_videos?user=itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: on the value of "running code" (was Re: Do you want to have more meetings outside US ?)
> IMHO, "running code" gets more credit than is warranted. While it is > certainly useful as both proof of concept and proof of implementability, > mere existence of running code says nothing about the quality of the > design, its security, scalability, breadth of applicability, and so > forth. "running code" was perhaps sufficient in ARPAnet days when there > were only a few hundred hosts and a few thousand users of the network. > It's not sufficient for global mission critical infrastructure. tend to agree. how about "multiple interoperable implementations"? itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Funding (was Re: Charging I-Ds)
> Charging for IDs will kill innovation. I use IDs to float ideas which > may or may not bear fruition. I would not work on these if I had to pay. > I also work on things at the IETF than my employer does not sponsor. > These things will get thrown out as well. I assume i-d to be a proposal for a new protocol, which is implementable with a reasonable efforts and costs. i think your view and my view are opposite. i'd like to see the following: - submission of i-d requires an implementation - to become a RFC requires two independent interoperable implementation itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6: Do you want to have more meetings outside US ?
> well i am just lurking, but i am very interested in everything about > ipv6 and deployment in general > there is an upcomming event here in cologne: > > "European Conference on Applied IPv6" at the 6th and 7th of september > 2007 here in cologne > > http://www.guug.de/veranstaltungen/ecai6-2007/index.html > > hope to cu there would love to attend, if someone can take care of my flight :-) itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
> > do not underestimate my paranoid-ness, i'm an OpenBSD developer > somehow, I think this should be on a t-shirt, or a bumper sticker. :) http://www.shirtcity.com/shop/index.php?file_merchandising=large&actual_merchant_article_serial_number=11&backjump_page=3&PHPSESSID=0be4b41bcaa11ad9eb49adb3bd9c61d5 itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
from what we have exchanged, the only things we do not agree with each other are: - you do not believe IPv4/v6 mixed environment would work, or too tough to make it work that it is not justifiable. also you see some problem in nodes with multiple addresses. - i do believe it would work ok > > if you are not under NDA, could you please be more specific? source > > code, RFC/draft for the protocol, whatever? i'm getting tired of this > > guessing games. > > > what do you want me to do, describe in detail every distributed > application that I've ever worked with? I'm not talking about any > specific application, I'm generalizing from several applications that > I've worked with and/or am otherwise familiar with. when you generalize things you might have missed some of the details, so if you could please send me pointers to details (privately). > > once you run ALG (which i guess you do not like) IPv6-to-IPv4 or > > IPv4-to- > > IPv6 looks much like SMTP relaying. > true. ALGs are okay for applications that have explicit intermediaries, > like SMTP. I don't like ALGs so much when they're used as interception > proxies. sometimes they work okay, sometimes not. yup. > > do not underestimate my paranoid-ness, i'm an OpenBSD developer > somehow, I think this should be on a t-shirt, or a bumper sticker. :) heh, maybe. > agree with all of those. but it sounds like you're close to arguing > that because there are so many other things that can screw with DNS, > it's okay for getaddrinfo() to return bogus results too. i did not say that. what i was trying to say are below: - you said that you do not trust getaddrinfo/getnameinfo but you seem to trust other DNS functions/responses. - under what kind of condition would you trust DNS, and would you not? - are you sure it is ok when you trust it? > > ok, so you are basically worried about uRPF, performance difference, > > and/or firewalling policy differences when you have multiple exit links. > > > it's not just multiple exit links, it's having multiple addresses per > host for any number of reasons. (mobility, renumbering, the desire to > have stable local addresses, and also the possibility of multiple active > network interfaces) note that "client machines with multiple IP address" has been a common practice even for IPv4, more than 15 years at least. i had the first laptop when i was in university, i ran 386BSD (4.4BSD) so that makes it around 15 years ago. mobility - i do not see your problem, maybe mobile-ip6 guys would want to speak up renumbering - multiple address DO help stable local address - well, define "stable" multiple active network interfaces - it is a common practice, use MacOS X machines with wireless and ethernet and switch them over time. TCP connection would not survive, which is a problem, but other than that, things are seamless (like browsers). > > do not take it as a self-promotion, but my take on this is in RFC3178. > > > but things like RFC 3178 do help. if we can get back to the expectation > that one address per host is the normal case, we'll make life much > simpler for application writers. the thing is, application writers does not really need to choose addresses to be used, as long as you write a program/protocol spec so that it does not embed IPv4/v6 addresses or DNS names. if you embed it, you would want to use DNS names instead of IPv4/v6 addresses, as you will want your application to work ok with the next protocol that would be introduced after IPv6. i would not call it IPv8 :-P > > so i can solve problem for Skype, so i guess i can solve problem for > > your "distributed computation system". want to hire a consultant? :-P > > > I can solve it too, and have done so on a couple of occasions. but I > don't pretend that it's easy to retro-fit every existing distributed > application (or to build every new distributed application) to handle > multiple realms. NATs have drastically raised the burden on > applications by dividing the Internet up into multiple address realms; > similarly, IPv4/IPv6 coexistence also divides the Internet up into > multiple address realms. Thus a "mixed" IPv4/IPv6 network is almost as > dysfunctional as a NATted IPv4 network. ok, i can understand your concern, but we need to do it anyways. unlike the introduction of IPv4, you cannot set a flag day, can you? itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
> > i guess we are living with very different assumptions. > > > it's just that the needs of applications vary as widely as the needs of > users. it's not as if all Internet users do nothing but email and the > web, and neither is it as if all Internet applications are like HTTP or ssh. if you are not under NDA, could you please be more specific? source code, RFC/draft for the protocol, whatever? i'm getting tired of this guessing games. > > sorry, you are, too lazy. remember the days when we had bitnet, > > decnet and compuserve (niftyserve in japan) in email world. > > we had a lot of technologies, or tricks i would say, to make emails > > get delivered from/to arbitrary networks. > > > > in this analogy, IPv4 is bitnet/decnet/compuserve and IPv6 is the > > Internet. of course. > > > yes, I remember those, and I also remember the problems we had trying to > make all of that work well - in particular, the problem of rewriting > addresses so that the mail would still be replyable after it crossed > multiple gateway boundaries. (actually I wrote a thesis on the topic). > I'm sure my experience with email addressing and gateways is part of why > I could see the problems with NAT earlier than most people. > > of course, it's not as if every application in the v4/v6 world is like > email. at least some of those email protocols were designed to be > store-and-forward and to allow email to be transmitted across networks > without end-to-end connectivity.store-and-forward isn't appropriate > for every applications protocol. (and I'd even argue that it probably > shouldn't be used for email anymore, at least not in the way that SMTP > currently does it, because it's really hard to arrange for errors to be > reliably reported to the party that needs to know about them.) well, i'm sure there still are instances of Lotus Notes running in ancient enterprises. once you run ALG (which i guess you do not like) IPv6-to-IPv4 or IPv4-to- IPv6 looks much like SMTP relaying. if you could give v6ops people your comments from your experiences, it would be helpful. i know we have been trying and tired to death, but this year is THE right time. > > without giving out the details of your "correct model" we cannot > > discuss. go by mathematical rules, first you give me axioms and > > then we talk about your theories. do not call theories a "fact" > > or "correct model" because we cannot define them. > > > I don't think there is a single "correct model" for all apps that works > in a network where hosts have multiple addresses and the performance can > vary significantly depending on which address pair you choose. yup, there's no single truth. we agree on that. > ideally, from the application's point-of-view, the network would always > perform well enough to suit the needs of the application and it wouldn't > matter which source and destination address were used. also, any > address would be reachable from any point in the network. the > traditional IPv4 network approximately fulfilled both conditions; the > current IPv4 network with NATs still mostly fulfills the first one. > having multiple addresses per host/network be the normal case in IPv6 > threatens to remove the first condition, and having a mixed v4/v6 > network nixes the second one. > > if you want PTR, MX and NS records, use res_send and stuff. > > > > use getnameinfo NI_NAMEREQD and getaddrinfo AI_NUMERICHOST if you > > want DNS resolution to happen for certain. > > > I don't recall that this guaranteed by the API specification. do not underestimate my paranoid-ness, i'm an OpenBSD developer, and i'm proud of it! i've met both Steve Mann and Richard Stallman face to face, though i don't think they remember me. - getaddrinfo/getnameinfo standards do not say a thing about DNS lookup so you cannot trust it. of course if analyze the source code, you may. - res_send/res_query are not a standard so the behavior is not defined in documents. of course if analyze the source code, you may. - even if you write code that plays with UDP/TCP socket, you are unsure if there's any tricks inside OS kernel, like host firewall blocking or rewriting your queries/responses. of course if analyze the source code, you may. - even if you trust your OS kernel, you cannot trust your router, especially when it implements NAT and you are using it with NAT disabled. of course if analyze the source code, you may, but the likelyhood of getting source code is rather low. - even if you trust your router, you would not be able to trust your ISP, or peering ISPs. now it became impossible to look at source code, and/or configuration of all the routers.
Re: chicago IETF IPv6 connectivity
i guess we are living with very different assumptions. > > no, the people who have implemented your applications that are written > > in > > IPv4-only and NAT-unfriendly, to be IPv4/v6 bilingual. i do not care > > about NAT (un)friendliness, i just need it to support IPv6. > > > you have it backwards. It is the NATs that are unfriendly to apps, not > the other way around. i guess we agree on this point, but recent IETF documents got it backwards so i worded it the way presented in the above. > it's easy to write a distributed app that can handle the case where all > nodes are IPv4, or the case where all nodes are IPv6. it is much more > difficult to write such an app that can handle the case where some nodes > are IPv4, some are IPv6, some are both, and there is a need to > communicate between arbitrary pairs of nodes within the app and to allow > some nodes to do referrals to other nodes. DNS names are not a good way > to solve this problem for reasons of performance and reliability and > because a DNS name does not, in practice, uniquely bind to a particular > host. sorry, you are, too lazy. remember the days when we had bitnet, decnet and compuserve (niftyserve in japan) in email world. we had a lot of technologies, or tricks i would say, to make emails get delivered from/to arbitrary networks. in this analogy, IPv4 is bitnet/decnet/compuserve and IPv6 is the Internet. of course. > > well, that depends on what kind of programming language you will be > > using. Python uses a model where you explicitly need to invoke bind(2) > > and getaddrinfo(3), so the programmer has to be knowledgeable enough > > to handle IPv4/v6 stuff. iirc Ruby TCPSocket class embeds all the > > details about getaddrinfo(3) loop within the class/instance method, > > so you do not have to care about which IP version is in use. > > > it is not reasonable to assume that for all apps the correct model is to > do a DNS lookup and then try the resulting IP addresses one at a time > until a connection succeeds for one of them. without giving out the details of your "correct model" we cannot discuss. go by mathematical rules, first you give me axioms and then we talk about your theories. do not call theories a "fact" or "correct model" because we cannot define them. > that, and getaddrinfo() is broken in a great many ways: it isn't tied to > DNS (so if your app is defined to use DNS then you can't trust > getaddrinfo() to do what your app needs); even if the implementation > does use DNS, getaddrinfo() can only do A and queries, it's not > asynchronous, if you want PTR, MX and NS records, use res_send and stuff. use getnameinfo NI_NAMEREQD and getaddrinfo AI_NUMERICHOST if you want DNS resolution to happen for certain. > and the whole idea that a host stack can select a > source/destination address pair by trial-and-error and get good results > within a reasonable time is, quite frankly, a joke. we agree on this point. i'm having trouble understaing the entire "source address selection" stuff. it won't get deployed nor properly managed. > > may i talk with you/designer of PVM/MPI code so that they can implement > > them in IPv6-friendly manner? privately. > > > I don't work there any more, and none of the people whom I knew that > worked on those codes work there any more either. ok, you need bump-in-the-stack (hitachi) or bump-in-the-library (erik nordmark/sun microsystems). > > there were tons of multipath TCP drafts, but there's no real > > authentication so all of them failed badly. so i see some future in > > ssh. > > ssh is not a bad protocol, but it doesn't solve the > multiple-addresses-per-host problem, even if you change it to allow > peers to re-connect (which would be a nice feature). what is the problem you have with "multiple-addresses-per-host" problem? i never had any problem even with IPv4. > > please tell me, your apps are totally multicast or broadcast? > > if not, we need to solve 2-nodes communication first, then you can > > solve communication among n (n could be very big) nodes. > > > this isn't a multicast or broadcast problem I'm speaking of. I'm > speaking of the need for the network to provide complete connectivity > between arbitrary pairs of nodes in a distributed system. describe what is "complete connectivity" in your definition. are you talking about QoS? > > then use vendor libraries that are URL-based. > > > my, you have a simplistic view of the application world! you did not give me the details, so i have to guessing. the last note. i guess i have a clear idea about how to make Skype dual stack. current Skype protocol is totally IPv4-only (see "silver
IPv6 demystified
i'm very tired of those mole-hunting games, so i concentrated some opinions onto a set of webpages. http://ipv6samurais.com/ipv6samurais/demystified/ itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
> >> that I personally use? I'm guessing about a half-dozen, though I don't > >> use them all everyday. some other apps work across NAT but with > >> degraded functionality. > > > > okay. if you could name them we can try to convince people who are > > responsible. > > > the people responsible for polluting the network with NATs? it's too > late to punish them, I fear :) no, the people who have implemented your applications that are written in IPv4-only and NAT-unfriendly, to be IPv4/v6 bilingual. i do not care about NAT (un)friendliness, i just need it to support IPv6. > > we kame are guilty for almost every application IPv6 support, including > > Python, Apache, Ruby, Postfix (wietse rewrote the whole thing), all > > tools > > on *BSD, BSD libc, whatever. honestly noone can beat us on this > > topic:-P > > > and the rest of us are very appreciative! of course, not all of the > applications that people use are those that are shipped with *BSD. and > while it's quite helpful if programming languages support IPv6, that > doesn't mean that the programs written in those languages will > automatically work with IPv6. well, that depends on what kind of programming language you will be using. Python uses a model where you explicitly need to invoke bind(2) and getaddrinfo(3), so the programmer has to be knowledgeable enough to handle IPv4/v6 stuff. iirc Ruby TCPSocket class embeds all the details about getaddrinfo(3) loop within the class/instance method, so you do not have to care about which IP version is in use. > > so, which is your real-world protocol which has the above problem? or > > is it a theoretical debate? "code then spec". > > > no, it's not a theoretical debate. I worked with a number of distributed > systems: PVM, some MPI implementations, and one of my own design that > didn't become so popular. There are a lot of applications layered on top > of one or the other of these. But unless you're into high-performance > computing you probably aren't aware of them. may i talk with you/designer of PVM/MPI code so that they can implement them in IPv6-friendly manner? privately. > > one way is to have a session-layer protocol (finally!). > > or, you can switch from TCP to SCTP. > > > for several reasons, SCTP is not a drop-in replacement for TCP. (but I'd > love to see further development and standardization of multipath TCP - > that seems like a very promising avenue) there were tons of multipath TCP drafts, but there's no real authentication so all of them failed badly. so i see some future in ssh. > > i have been trying to persuade openssh coders to have functionality > > to re-connect ssh session even when TCP session go down. if you tunnel > > everything over ssh, you won. > > > sigh. yes that would be valuable functionality, but somehow I don't > think that the answer to every problem imposed by shortsighted hacks in > the network is to push things down another layer. and this kind of > solution only solves the problem for two-node applications. please tell me, your apps are totally multicast or broadcast? if not, we need to solve 2-nodes communication first, then you can solve communication among n (n could be very big) nodes. > > you have to. you cannot be that lazy. > our goal in IETF should be to allow programmers to be that lazy. > separation of function between the host and the network is a Good Thing. > let the hosts exchange packets and the network route them. > > the goal is certainly not to keep increasing complexity of the network > and to keep making programmers' jobs more difficult. then use vendor libraries that are URL-based. > > or .Net framework (Windows) or > > CFNetwork (MacOS X) can handle it for you inside the library. > > > only if you want your application to be crippled in other ways. (my, you > have a simplistic view of the application world!) ??? i do not get your point. you would like to be lazy, then use libraries that are based on URLs. otherwise, you have to use getaddrinfo(3). other than that, either your design is broken or you are lazy. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
> > how many applications do you have that does not run across NATs? > > > that I personally use? I'm guessing about a half-dozen, though I don't > use them all everyday. some other apps work across NAT but with > degraded functionality. okay. if you could name them we can try to convince people who are responsible. > at my last job, where we worked on distributed computing systems? > several more than that. we kame are guilty for almost every application IPv6 support, including Python, Apache, Ruby, Postfix (wietse rewrote the whole thing), all tools on *BSD, BSD libc, whatever. honestly noone can beat us on this topic:-P > > how many of them have hardcoded 32bit address field in the payload? > > hard to say. I tried to promote IPv6-awareness at my last job and to > get developers to stop assuming that an address was 32 bits. > > but the bigger problem isn't the hard-coded address size - it's the > conflict between the application writer's desire that the network > provide complete connectivity (imagine having a network that actually > provided best-effort packet delivery!), and the various things that > exist to split the network up into realms with arbitrary constraints on > how traffic can be routed between those realms. having multiple address > realms of any kind - be they private address realms behind NATs, or > IPv4/IPv6, or whatever - basically forces apps to implement their own > routing, and sometimes, their own addressing. and requiring apps to > have their own routing is tantamount to requiring them to have their own > infrastructure that is rooted in the public Internet (probably on port > 80) where all nodes can presumably reach them. so, which is your real-world protocol which has the above problem? or is it a theoretical debate? "code then spec". one way is to have a session-layer protocol (finally!). or, you can switch from TCP to SCTP. i have been trying to persuade openssh coders to have functionality to re-connect ssh session even when TCP session go down. if you tunnel everything over ssh, you won. > it's much simpler to write a distributed app that is either entirely > IPv4 or entirely IPv6 than to write one that supports both. you have to. you cannot be that lazy. or .Net framework (Windows) or CFNetwork (MacOS X) can handle it for you inside the library. http://www.amazon.com/exec/obidos/ASIN/(A183180(B itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
> > cannot agree more. i do not care if it is based on TCP/UDP relaying > > (per session) or NAT-PT (per packet), but IPv6-to-IPv4 translators > > have its own benefits. and of course drawbacks, but the drawback > > is much smaller than conventional IPv4-to-IPv4 NAT as we have an escape > > plan (use native IPv6). > > > > translators do have benefits, and can be mostly harmless with applied > judiciously. the problems result from imposing translators in the > signal path to/from a significant number of hosts that are running > arbitrary applications. > > NAT-PT style translators can be just fine when used with a small number > of specific hosts for which it is known that the applications on those > hosts won't be harmed by the interposition of NAT-PT. though frankly, > most users aren't capable of doing such analysis - just like most users > don't understand the harm that NAT does. how many applications do you have that does not run across NATs? how many of them have hardcoded 32bit address field in the payload? in fact, as posted a couple of weeks ago i got an IPv6-only wireless network which works just fine for me. the only applications that does not go through it are: - Skype (MacOS X) - Software Update (MacOS X) - .Mac Sync (MacOS X) - NFS (any OS) caveat: i'm not a heavy user of multi-media apps nor BitTorrent. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
> Thus spake "Keith Moore" <[EMAIL PROTECTED]> > > NAT-PT really needs to be wiped off the face of the earth. It > > provides all of the disadvantages of IPv4+NAT with all of the > > transition costs of IPv6. > > Indeed it does. However, it has significant benefits as well: (snip) cannot agree more. i do not care if it is based on TCP/UDP relaying (per session) or NAT-PT (per packet), but IPv6-to-IPv4 translators have its own benefits. and of course drawbacks, but the drawback is much smaller than conventional IPv4-to-IPv4 NAT as we have an escape plan (use native IPv6). itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: PKI is weakly secure (was Re: Updating the rules?)
> What, do you mean, strong security? > > Given that CAs of PKI can be compromised as easily as ISPs > of the Internet, PKI is merely weakly secure as weakly as > the plain Internet. i would not word like this, you are asking for flamewar :-) i would say: - technologies that use hierarchical structure to combat scalability problem is very tough to make a successful deployment - key distribution problem is almost like NP-complete problem, it is way too difficult that you need some assumption to relax it (e.g. ssh first-time contact weak authentication) you now know which RFC i do not really love :-P itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A new transition plan, was: Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity
> - more and more ISP infrastructure practices OP25B for IPv4. OP25B = Outbound Port 25 Blocking. it disallows ISP customers to run SMTP server, or use SMTP server outside of the ISP network. maybe it is japanese-local acronym, google shows me japanese pages only. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A new transition plan, was: Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity
> > How will SMTP servers vet sources of inbound messages within an IPv6 > > environment? > I don't know, but except for very limited corner cases, trying to use a > source address to vet the source in an IPv4 environment is foolish and > error-prone. It is no less foolish and error-prone in IPv6, but that's > not the fault of IPv6. from my experience - very few SMTPv4 servers look at PTR/A record matching. i'm not sure how i can configure sendmail/procmail to do this. - i never found any RBL-style blacklist for IPv6. - spammers DO use SMTPv6. by chance or by intention? not sure. - more and more ISP SMTPv4 servers do filter SMTPv4 from outside of its network, to prevent the abuse by spammers. - more and more ISP infrastructure practices OP25B for IPv4. i'm not too sure about the latter two in IPv6. maybe we should ask NTT and IIJ email ops division about this. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
>> So basically, you're complaining that you came to the IETF and >> received production quality Internet service? > >Do IETF networks add missing IPv6 root glue? If so, would this be >beyond production quality? if I were to provide RFC3142 IPv6-to-IPv4 TCP relaying gateway, I will be using "totd" tricky recursive DNS server. if you put it in /etc/resolv.conf or something alike, you will get translated records whenever there's no real record present for a DNS name, and IPv6 TCP traffic will be re-connected into IPv4.. there still are some questions remain: - on *BSDs we do not have UDP relaying gateway, because TCP relaying gateway relies upon *BSD tcpcb structure. Yokogawa sells commercial device which does UDP relaying as well, so maybe yokogawa guys want to speak up. - if you run named or some DNS resolver which caches old results, your DNS cache may be filled with the translated results. it may or may not cause problems. the DNS TTL below shows that totd gives the same TTL as the original A records, it should be reduced to like 0 or 10 seconds when translation happens. with *BSD implementation there's no caching code in libc resolver. with Apple MacOS X there may be some cache but I have never experienced any issues. so there's no cache I suppose, or cache entries are associated with the information source DNS server. I have no idea about Microsoft OSes nor Linux. itojun | IPv6-over-IPv4 tunnel (MTU = 1280) garlic.itojun.org coconut.itojun.org |2 |1 ==+===+== wireless segment | 192.168.0.0/24, 2001:240:501:1::/64 wireless clients - DHCPv4 daemon will give wireless clients IPv4 address, DNS server IPv4 address (192.168.0.2), but NO IPv4 default gateway - IPv6 router advertisement will make wireless clients configure itself with IPv6 address(es) and IPv6 default gateway - totd runs on garlic.itojun.org (192.168.0.2) - totd returns translated responses to clients when asked about DNS names without record associated with it (such as a.root-servers.net). totd will not trick you if the DNS name has associated with it (www.kame.net). - TCP traffic to 2001:240:501:::/64 will get sucked by garlic.itojun.org - garlic.itojun.org will re-connect IPv6 TCP to IPv4 TCP itojun[garlic:~] dig @192.168.0.2 a.root-servers.net. a ; <<>> DiG 9.3.4 <<>> @192.168.0.2 a.root-servers.net. a ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13668 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;a.root-servers.net.IN A ;; ANSWER SECTION: a.root-servers.net. 604225 IN A 198.41.0.4 ;; AUTHORITY SECTION: root-servers.net. 604217 IN NS a.root-servers.net. root-servers.net. 604217 IN NS f.root-servers.net. root-servers.net. 604217 IN NS j.root-servers.net. root-servers.net. 604217 IN NS k.root-servers.net. ;; Query time: 27 msec ;; SERVER: 192.168.0.2#53(192.168.0.2) ;; WHEN: Wed Jul 4 05:18:25 2007 ;; MSG SIZE rcvd: 180 itojun[garlic:~] dig @192.168.0.2 a.root-servers.net. ; <<>> DiG 9.3.4 <<>> @192.168.0.2 a.root-servers.net. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30068 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;a.root-servers.net.IN ;; ANSWER SECTION: a.root-servers.net. 604798 IN 2001:240:501:::c629:4 ;; AUTHORITY SECTION: root-servers.net. 604790 IN NS a.root-servers.net. root-servers.net. 604790 IN NS f.root-servers.net. root-servers.net. 604790 IN NS j.root-servers.net. root-servers.net. 604790 IN NS k.root-servers.net. ;; Query time: 88 msec ;; SERVER: 192.168.0.2#53(192.168.0.2) ;; WHEN: Wed Jul 4 05:08:52 2007 ;; MSG SIZE rcvd: 192 itojun[garlic:~] dig @192.168.0.2 www.kame.net. a ; <<>> DiG 9.3.4 <<>> @192.168.0.2 www.kame.net. a ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61674 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.kame.net. IN A ;; ANSWER SECTION: www.kame.net. 86400 IN A 203.178.141.194 ;; AUTHORITY SECTION: kame.net. 86400 IN NS ns1.itojun.org. kame.net. 86400 IN NS orange.kame.net. ;; ADDITIONAL SECTION: ns1.itojun.org. 3600IN A 221.249.121.227 ns1.itojun.org. 3600IN 2001
Re: Domain Centric Administration, RE: draft-ietf-v6ops-natpt-to-historic-00.txt
> i do not have one myself so please verify it by yourself. i have > used it at meetings (Jun Murai has almost every version of it) as well > as while i have been war-driving in Tokyo. nice (or bad) thing for the > latter case was that there was no access control enabled for > 6to4-based IPv6 for the particular base station i've associated with:-P I have no idea where the IPv4 access blocking was implemented. I could not single out the issue or find workarounds, because I had IPv6 access already :-P itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Domain Centric Administration, RE: draft-ietf-v6ops-natpt-to-historic-00.txt
> so, Apple is not slacking and KAME/*BSD are not too. for the record, I do not get paid from Apple, just yet :-P itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Domain Centric Administration, RE: draft-ietf-v6ops-natpt-to-historic-00.txt
>> PS: in openbsd community if you do not commit frequently=20 >> enough you will be scolded for being a slacker. > >Which is part of where we need to get to. > >What I propose is a brand, similar to WiFi that tells a customer, = >whether home or enterprise that a product: > >1) Either > Will install itself automatically and seamlessly within a network that >is under domain centric administration. > > Will do the above, unless the network is not already under domain >centric admin in which case it will establish the necessary DNS and DHCP >infrastructure to support one (and yes would be nice if this also >extended to redundancy). > >2) Supports both IPv4 and IPv6 seamlessly. > >3) Has a built in device cert and is able to perform 802.1X >authentication to the network hub > >4) In the case of a wireless device supports a network configuration = >mechanism that does not involve a user touching a keyboard. > > >In other words you have the current Internet and the 'it-just-works' = >Internet. And the IJW-Internet happens to support everything you need = >for IPv6. from what i've gathered from information sources, the device you want to buy is the latest version of Apple AirPort Extreme base station. i do not have one myself so please verify it by yourself. i have used it at meetings (Jun Murai has almost every version of it) as well as while i have been war-driving in Tokyo. nice (or bad) thing for the latter case was that there was no access control enabled for 6to4-based IPv6 for the particular base station i've associated with:-P (1-2) are already covered as it implements NAT for IPv4 if you want. it can be configured as a pure L2 bridge between ethernet and 802.11, if you got enough IPv4 address to spare. in terms of IPv6, it has a button or something to turn on IPv6, and it even speak 6to4 if there is no ISP device/contact to terminate static IPv6-over-IPv4 tunnel. of course you can bridge IPv6 as well. (4) is of course covered, almost every Apple product ships with GUI. i'm not too sure about (3) but i hope someone from Apple to comment. if necessary i'll meet people in Apple Japan tomorrow so i can ask. the device i've used were configured either with WEP or no auth. it runs *BSD variant, if you run namp on it you should be able to know which *BSD it is. so, Apple is not slacking and KAME/*BSD are not too. MacOS X is shipped with IPv6 enabled by default since 10.2 (or 10.3?) timeframe, and from WWDC2007 comment by Steve Jobs there are 22 million machines which runs 10.2 and beyond, so there are 22 million IPv6 enabled machines. MacOS X is good, it is basically having Macintosh Aqua GUI on top of a BSD variant. you will love it. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Domain Centric Administration, RE: draft-ietf-v6ops-natpt-to-historic-00.txt
i will be a bit implite. >> as I posted before, almost every one of people who attends IETF are >> running IPv6-capable operating system. if you are not, you are very >> out of date like 5 years. >> >well, even if your OS supports IPv6 doesn't mean that it works well with >things like your host-based firewall. if that is true, the company selling that host-based firewall is slacking. >> IPv6 is not enabled just because implementers have been polite enough >> not to enable IPv6 transition technologies like Teredo or 6to4 on by >> default. maybe we should think it over? >word I hear is that Vista's enabling of such technologies is causing >problems for enterprise networks because their traffic filters and >intrusion detectors aren't set up to handle them. firewalls and IDS companies are slacking. itojun PS: in openbsd community if you do not commit frequently enough you will be scolded for being a slacker. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Domain Centric Administration, RE: draft-ietf-v6ops-natpt-to-historic-00.txt
> This is the time when everyone should be running dual stack. as I posted before, almost every one of people who attends IETF are running IPv6-capable operating system. if you are not, you are very out of date like 5 years. IPv6 is not enabled just because implementers have been polite enough not to enable IPv6 transition technologies like Teredo or 6to4 on by default. maybe we should think it over? itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Domain Centric Administration, RE: draft-ietf-v6ops-natpt-to-historic-00.txt
> My point here is that the principal objection being raised to NAT, the > limitation on network connectivity is precisely the reason why it is > beneficial. > > There is no other device that can provide me with a lightweight firewall for > $50. other reponses gave you some good news. > Same can be said of IPv6. > > We have a lot of really good ways of avoiding issues we don't like: > complexity, accessibility, limited access in third world countries. > > Unless the arguments are applied consistently they should not be made at all. > Otherwise they just become special pleading. well, you can say this for IPv4, or operating systems which does not have enough history. for the record, KAME group found a bug in IPv4 options handling, rooted in Net/1 timeframe, in year 2000. so i use operating systems which has its roots in 1970s only :-P http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_input.c revision 1.132 > As I told Bruce Schneier after his silly IPSEC and Certification Authority > papers, security is risk control, not risk elimination. > > It is not helpful to criticise a security measure that empirically offers a > high degree of security for failing to address cases it is not designed to > deal with. An HTTP server behind a NAT box is no HTTP server and thus no > threat. > > In a full default deny infrastructure I can allow the HTTP server external > access and deal with issues such as HTTP server corruption by requiring the > HTTP server to run in an isolated O/S partition so that compromise of the > server cannot lead to compromise of the host. i can understand your point about "security is risk control". we trust 16-digit credit cards as credit card companies have $$$ insurance in the back. ATM machines and credit card CAT systems use stone age technology called MODEM, so wiretapping them should be less than trivial for those who read the "2600 magazine". however, we are internet engineers, aren't we? we are not forced to use modems, and even if we use modems, we put IP layer on top. do check Steve Deering's "hour glass" presentation if you missed it. http://www3.ietf.org/proceedings/01aug/slides/plenary-1/index.htm and, not to offend Verisign or anything, and really a off topic, but i still believe PKI and other tree-based authentication technology does not scale enough. since we need to install keys for famous certificate authorities into the browsers, it became more difficult for small free software people to implement/distribute HTTPS capable browsers without hitting the problem "we do not have CA key for Amazon.com". > I can shut down 95% of existing botnets using reverse firewalls. I have yet > to find a legitimate network use with an access pattern that remotely > resembles the access patern of a production botnet. > > The approach I propose in the dotCrime Manifesto is that by default the > newtork access point throttles outgoing SYN and DNS requests to some large > number that is well short of the needs of spammers, DDoS SYN flooding etc. so you install both forward and reverse firewalls, then what kind of communication would you permit? :-P > > OSes have to be secured by default, that's all. > > Linux is ten million odd lines of code. When you have more than a million > lines of code you can be certain that at least 50% of the people working on > it were below average in talent. Vista is ten times bigger. > > We simply don't know how to build a secure operating system today. well, you are using OSes which are not in AT&T UNIX family tree so you are in the wrong world. sorry Microsoft guys, i do try hard not to offend you :-P http://www.freebsd.org/cgi/cvsweb.cgi/src/share/misc/bsd-family-tree > The 'security through obscurity' argument is bogus. > > Back in the early 1990s people were arguing AGAINST the use of shaddow > passwords in UNIX on the grounds that they give a 'false sense of security'. > > I agree that most enterprises have an exagerated idea of what perimeter > security can do for them, but that does not mean that the solution is to drop > all the firewalls. That is not what is being discussed when people are > talking about deperimeterization. funny that you say "obscurity". i would say that NAT is the obscurity device. if you are in Linux camp you know that RMS does not use password at all. but i'm in OpenBSD camp so i randomize/encrypt every single bit of information i use, even process IDs are random. i do not trust MD5 password. i use Blowfish-based password developed by Niels Provos. i think i am more paranoid than most of Verisign guys, modulo those who are managing the root CA key in the secret vault in a dat
Re: Domain Centric Administration, RE: draft-ietf-v6ops-natpt-to-historic-00.txt
> > There is no other device that can provide me with a lightweight firewall > > for $50. > > Yes there is; it's a SOHO gateway with its NAT function switched > off for use with a "fixed IP address". > > SOHO gateways with IPv6 support will provide exactly as much firewall > protection as a NAT-capable IPv4 SOHO gateway. The only question is > when they will cost $50. if they use software to forward packets (it is unlikely for $50 routers to have silicon to forward packets) and they are wise enough to use free software, there is almost no real reason to raise the price for IPv6 support. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
> > The IETF network is not, and never has been, for experimentation, > > showing off new technology, or making political statements. Please keep > > it that way. > > +1 RFC1883 is not new. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Domain Centric Administration, RE: draft-ietf-v6ops-natpt-to-historic-00.txt
>Its not exactly a surprise, folk seem to place a higher premium on
>shooting NAT than anything else. Meanwhile the vast majority of
>residential broadband access is behind NAT.
>
>And from a security point I want to see as much NAT as possible. Without
>NAT we would be in a much worse situation security wise than we are
>today. NAT is a blunt instrument but it shuts down inbound server
>connects. And that is such a good thing from the point of view of
>stopping propagation of network worms.
(snip)
a few points. IPv6 technology really needs to be demystified.
you do not have to rewrite IP address to ensure that there's no
inbound connections. you just have to have a packet filter which
watches/drops TCP SYN or whatever alike. if you do not have enough
address space to serve your enterprise, it is a good reason to use
IPv6 :-)
even if you have NAT, or any middle system which rewrites IP address/
port number, or RFC3041 trick in your end system, your privacy is
leaked by the use of HTTP cookie and OS fingerprinting. if you do not
use HTTP cookies, you cannot buy things at Amazon. if you have RFC3041
and other tricky systems, your system will have higher likelyhood of
having implementation bugs (violation of KISS principle).
even if you stop all inbound connections, malicious parties which
controls HTTP/whatever servers can inject your end node any kind of
crufted TCP options, which might cause buffer overflow (DoS/privilege
user hijacking). the only solution (internet-wise) to this is to have
TCP relaying proxies like TIS firewall toolkit/Gauntlet. even skype
cannot go across TCP relays.
spam, phishing and botnet are independent from presense/absense of NAT.
OSes have to be secured by default, that's all. heavy use of firewall/
NAT have propagated "false sense of security" inside enterprise
network, and therefore, many of end systems within enterprise are very
vulnerable to attacks. the most common attack vector these days are
laptops owned by people like IETFers (goes in and out of enterprise)
or VPN-connected laptops, which carry worms. so, many people purchase
end node firewall systems ("fire suit" in the old terminology), but,
if your end node operating systems are secure by default, you do not
need those end node firewall systems and/or keep upgrading signature
files.
http://www.openbsd.org/papers/asiabsdcon07-network_randomness/index.html
itojun
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 transition technologies
> > > > i tend to agree, but in rfc-index.txt i could not find the change of > > state to "Historic". what happend to very similar (and much more evil > > IMHO) transition technology, SIIT? > > If you look at draft-ietf-v6ops-natpt-to-historic-00.txt (the > draft that obsoletes NAT-PT), it is quite critical of SIIT > (RFC 2765), but does not obsolete it. > > [I attempted to obsolete SIIT before it was written (RFC 1671 > section B) but that didn't work :-) . There are parts of > RFC 1671 that are wrong, but not that part.] i cannot agree more. maybe it is time to revisit draft-itojun-v6ops-v4mapped-harmful-02.txt? itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
draft-ietf-v6ops-natpt-to-historic-00.txt
> At 1:56 AM +0900 7/2/07, Jun-ichiro itojun Hagino wrote: > > > NAT-PT really needs to be wiped off the face of the earth. It provides > >> all of the disadvantages of IPv4+NAT with all of the transition costs of > >> IPv6. If there is ever any significant penetration of NAT-PT, then the > >> pseudo-IPv6 network will not be able to support any more kinds of > >> applications than the NATted IPv4 does today. > > > > i tend to agree, but in rfc-index.txt i could not find the change of > > state to "Historic". what happend to very similar (and much more evil > > IMHO) transition technology, SIIT? > > <https://datatracker.ietf.org/idtracker/?search_filename=draft-ietf-v6ops-natpt-to-historic> > > indicates that the document making NAT-PT is in the RFC Editor's > queue. i am not convinced at all with the content of the draft. if NAT-PT is to be made historic due to the claims presented in the draft, all of the NAT related documents have to be made historic, instead of informational, since "informational" can be misleading to people who try to implement stuff. the worst of all is RFC3235. and all of the NAT traversal documents (RFC3489, RFC3519, RFC3715, RFC3947, RFC4091, RFC4092, RFC4380) has to be banned at once. [EMAIL PROTECTED] 911 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
> >>maybe we can have the default "IETF61" SSID be pro-IPv6, and SSID > >>"legacy" be IPv4-only :-P > > > > > > Ahh, well. That moves the change from being coercive to being cool. > > No, that moves it to being pejorative. > > In any case, what is the need for separate SSID's? Do you truly > intend to clutter the airspace further with another set of AP's? > There are effectively only three channels and you really want to use > all three already to provide overlapping non-interfering coverage... you right. we have been running dual stack network since 1998 or something (Marc Blanchet should have the real answer), and we even supplied IPv6-to-IPv4 translators, so there should be no problem at all. I can bring in IPv6-to-IPv4 translator if necessary. it would be an OpenBSD Soekris box. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IPv6 transition technologies
> NAT-PT really needs to be wiped off the face of the earth. It provides > all of the disadvantages of IPv4+NAT with all of the transition costs of > IPv6. If there is ever any significant penetration of NAT-PT, then the > pseudo-IPv6 network will not be able to support any more kinds of > applications than the NATted IPv4 does today. i tend to agree, but in rfc-index.txt i could not find the change of state to "Historic". what happend to very similar (and much more evil IMHO) transition technology, SIIT? itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
>> to use legacy protocol like IPv4 :-) you can use IPv6-to-IPv4 >> tranlators like NAT-PT or RFC3142. > >NAT-PT (RFC 2766) is being moved to Historic status. RFC 3142 is >Informational. Without a standards-track method for people to use >IPv4, changing a production network to IPv6 seems unwise. RFC status does not have direct connection with "being implemented" or "being deployed" (see all the W3C standards which did not originate in IETF). at N+I tokyo we have been using RFC2766/3142 for IPv6-only net cafe since around year 2000 or something. in June 2007 N+I network team used Windows Vista official releases as the clients. >> their scalability is no worse than IPv4-to-IPv4 NAT. > >That may be true, but it is also irrelevant, given that the current >production network doesn't use IPv4 NAT at all. you are in ARIN region so you are enjoying vast amount of IPv4 address space... come to APNIC region or LACNIC region to experience the pain. i pay $300/mo for PA /29, and it is a real bargain. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
> > Maybe we are getting to the point in time where we should only have IPv6 > > at IETF meetings or it that's premature run IPv4 behind a couple of > > layers of NAT. > > On the theory that the ietf meeting net is for production services, wouldn't > it make sense to have the time to cut over to pure ipv6 be when production use > of ipv4 becomes minimal? maybe we can have the default "IETF61" SSID be pro-IPv6, and SSID "legacy" be IPv4-only :-P itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
> > Maybe we are getting to the point in time where we should only have > > IPv6 at IETF meetings > > good luck. Until the ISPs and our corporate networks deploy it, we > can't go there. to use legacy protocol like IPv4 :-) you can use IPv6-to-IPv4 tranlators like NAT-PT or RFC3142. their scalability is no worse than IPv4-to-IPv4 NAT. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
>> From: Bob Hinden <[EMAIL PROTECTED]> > >> Maybe we are getting to the point in time where we should only have >> IPv6 at IETF meetings > >Guess that's the only way you can get people to convert to IPv6, huh - cut >off their IPv4 access? well, if you are using either of the following, you are IPv6 ready. - MacOS X after 10.2 (or 10.3? I do not remember but you should really be using 10.4.10) - *BSD releases after year 1999 - Linux after year 2000 or somewhere around (depending on your distribution) - Nokia Symbian phones (Bob will tell you more about it) - Windows Vista - Windows XP SP2 with "ipv6 install" command if you still are using Windows Me/98/95, you should really upgrade, since there's no security patch releases from Microsoft any longer IIRC. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
chicago IETF IPv6 connectivity
i'm wondering about IPv6 connectivity at chicago IETF69. if any of you have hints about it, please drop me a note. if there's no plan for IPv6, i'd be more than happy to help out, as always. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
[IETF61] no IPv6?
how come there's no IPv6 on the "IETF61" network? i'm happy to help it get installed, so contact me if you need any help >noc people itojun ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
places to visit
if you are looking for computers/gadgets: - technomart (Gangbyeon st. on line #2) - yongsan electric town (Yongsan st. on line #1) if you are looking for korean books: - books libro (north-east corner from lotte hotel/good selection of japanese manga translated to korean) - kyobo bookstore (near Kwanghwamun on line #5) - youngpoon bookstore (near Jonggak st. on line #1) i'm looking for musical instruments shops (bookshops do carry sheet music but i could not find what i have been looking for). if any of you have suggestion please drop me a note. tnx. itojun
Re: draft-ietf-vrrp-ipv6-spec-05.txt lacks IPR clause
btw, KAME have removed VRRP6 implementation from the distribution because of the IPR statement (it conflicts with our policy about IPR). there's ongoing work called "carp" which is specifically designed to avoid infringing cisco patent on HSRP by avoiding core details, so KAME would integrate that eventually. itojun --- KAME IPR policy 9. Policy on technology with intellectual property right restriction There are quite a few IETF documents/whatever which has intellectual property right (IPR) restriction. KAME's stance is stated below. The goal of KAME is to provide freely redistributable, BSD-licensed, implementation of Internet protocol technologies. For this purpose, we implement protocols that (1) do not need license contract with IPR holder, and (2) are royality-free. The reason for (1) is, even if KAME contracts with the IPR holder in question, the users of KAME stack (usually implementers of some other codebase) would need to make a license contract with the IPR holder. it would damage "freely redistributable" status of KAME codebase. By doing so KAME is (implicitly) trying to advocate no-license-contract, royality-free, release of IPRs. Note however, as documented in README, we do not guarantee that KAME code is free of IPR infringement, you MUST check it if you are to integrate KAME into your product (or whatever): READ CAREFULLY: Several countries have legal enforcement for export/import/use of cryptographic software. Check it before playing with the kit. We do not intend to be your legalease clearing house (NO WARRANTY). If you intend to include KAME stack into your product, you'll need to check if the licenses on each file fit your situations, and/or possible intellectual property right issues.
draft-ietf-ngtrans-ipv6-smtp-requirement
--- Blind-Carbon-Copy To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Ned Freed <[EMAIL PROTECTED]>, Ted Hardie <[EMAIL PROTECTED]> Subject: draft-ietf-ngtrans-ipv6-smtp-requirement X-Template-Reply-To: [EMAIL PROTECTED] X-Template-Return-Receipt-To: [EMAIL PROTECTED] X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: [EMAIL PROTECTED] Date: Wed, 09 Jul 2003 17:31:26 +0900 Sender: [EMAIL PROTECTED] a couple of IETFs ago, it was suggested at the ngtrans wg meeting that the document draft-ietf-ngtrans-ipv6-smtp-requirement-xx "should be handed to SMTP experts in application area". since then, there has been no actions taken. the fact is, there is no active working group for SMTP and email-related activities. also ngtrans wg is concluded. therefore, the document is in "zombie" state. I still want the document (or the contents of it) be published, as it contains critical guidelines for IPv6/v4 dual stack SMTP operation. I would like to ask IESG to decide and take appropriate actions, such as: - poke SMTP experts, let them work on the topic and produce an RFC - let me handle the document as an individual submission and publish it as an RFC thanks. itojun --- End of Blind-Carbon-Copy
rogue IPv6 router
it seems that there's Windows XP laptop acting as rogue router serving bogus 6to4 prefix (generated from IPv4 linklocal address). please stop it, thanks. itojun
[IETF54] IPv6 demo room
before you fly out from Narita (or head to Kyoto for sightseeing) don't forget to visit IPv6 demo room in central Tokyo. http://contents.pr.v6pc.jp/apwg/en/event_sr01.html On Friday afternoon, there will be a special joint demo session from Korean and Japanese IPv6 folks. itojun
slides for IESG plenary
my slides for IESG plenary is available at: http://www.itojun.org/paper/itojun-ietf54-iesg-plenary/ itojun
[IETF54] keep rooms clean
to IETF54 participants: please keep meeting rooms clean. put garbage into the appropriate garbage cans. room 503 was a total mess last night and caused additional labors to NOC team. if you could help cleaning rooms up when you leave rooms after the sessions, it would be very nice. thanks! itojun
IETF50 terminal cluster IPv6 usage
http://www.kame.net/ietf50/ has all statistics gathered during IETF50 IPv6 terminal cluster operation. highlights include: - 7-8% of laptops are IPv6-aware (respond to IPv6 ping) - there seem to be 10+ machines who have configured their machine to be IPv6-only (using IPv6-to-IPv4 translator) Thanks go to Lucent term cluster team, and all people helped IPv6 network configurations/operations. I really hope IPv6 connectivity to be officially provided, at IETF51. itojun
[IETF50] IPv6 non-working basestations
really^100 sorry again for spamming. I got no response from NOC guys yet. the following 3 wireless basestations are configured no to bridge ethernet-layer multicast, preventing IPv6 from working across them. please turn on ethernet-layer multicast bridging. thanks. itojun BSSID 00:02:2d:1c:f4:04, @ 3F near Director's room #3 BSSID 00:60:1d:f6:b4:28, @ 3F near big ballroom D BSSID 00:60:1d:1e:ee:91, @ 3F near big ballroom D
[IETF50] wireless basestation that does not relay ethernet multicast
sorry for spamming. i could not find email address for NOC guys and [EMAIL PROTECTED] does not seem to work. itojun --- Forwarded Message Return-Path: [EMAIL PROTECTED] Delivery-Date: Mon Mar 19 06:52:24 2001 Return-Path: <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] Received: from localhost (localhost [::1]) by starfruit.itojun.org (Postfix) with ESMTP id B35A47E73 for ; Mon, 19 Mar 2001 06:52:23 +0900 (JST) Received: from coconut.itojun.org [210.160.95.97] by localhost with POP3 (fetchmail-5.5.3) for itojun@localhost (single-drop); Mon, 19 Mar 2001 06:52:23 +0900 (JST) Received: from starfruit.itojun.org (pcp000911pcs.wireless.meeting.ietf.org [135.222.65.155]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id GAA25798 for <[EMAIL PROTECTED]>; Mon, 19 Mar 2001 06:50:15 +0900 (JST) Received: by starfruit.itojun.org (Postfix, from userid 1001) id 0CFA47E73; Mon, 19 Mar 2001 06:50:14 +0900 (JST) To: [EMAIL PROTECTED] Subject: non-working wireless basestation Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Message-Id: <[EMAIL PROTECTED]> Date: Mon, 19 Mar 2001 06:50:14 +0900 (JST) From: [EMAIL PROTECTED] (Jun-ichiro itojun Hagino) X-Filter: mailagent [version 3.0 PL68] for [EMAIL PROTECTED] X-UIDL: UZ9!!T:a"!+>-"!`+R"! not sure if the mail address is working or not, but anyway i'll try. the basestation does not seem to bridge ethernet level multicast packet, and preventing IPv6 from working. could you please fix this box? i got connected with the basestation on 3rd floor, in Director room #3. >>Current BSSID: [ 00:02:2d:1c:f4:04 ] itojun NIC serial number: [ 00UT16414753 ] Station name: [ NetBSD WaveLAN/IEEE node ] SSID for IBSS creation: [ NetBSD IBSS ] Current netname (SSID): [ IETF ] Desired netname (SSID): [ IETF ] Current BSSID: [ 00:02:2d:1c:f4:04 ] Channel list: [ 16383 ] IBSS channel: [ 14 ] Current channel:[ 11 ] Comms quality/signal/noise: [ 38 93 56 ] Promiscuous mode: [ Off ] Port type (1=BSS, 3=ad-hoc):[ 1 ] MAC address:[ 00:60:1d:21:c9:59 ] TX rate (selection):[ 3 ] TX rate (actual speed): [ 11 ] Maximum data length:[ 2304 ] RTS/CTS handshake threshold:[ 2347 ] Create IBSS:[ Off ] Access point density: [ 1 ] Power Mgmt (1=on, 0=off): [ 1 ] Max sleep time: [ 100 ] Microwave oven robustness: [ ] WEP encryption: [ Off ] TX encryption key: [ 1 ] Encryption keys:[ ][ ][ ][ ] [ 1 ] Max sleep time: [ 100 ] Microwave oven robustness: [ ] WEP encryption: [ Off ] TX encryption key: [ 1 ] Encryption keys:[ ][ ][ ][ ] --- End of Forwarded Message
[IETF49] outgoing SMTP blocked
could you please allow outgoing SMTP session (TCP port 25) from the venue? I understand it is to prevent spammers, but for spam protection, forbidding inbound SMTP should be enough... itojun
[ITEF49] SMTP port filtered?
sorry for too wide distribution, there's no terminal staff contact point listed on the webpage. it seems that outgoing SMTP session is filtered (SYN ACK never comes back from outside the venue). could you permit outgoing session, or provide SMTP relay server at the venue? to prevent spams, filtering inbound SMTP should be enough. itojun
[IETF48] IPv6 shutdown time will be 11:30
we will remove IPv6 router at the venue around 11:30. thanks. itojun
IETF venue IPv6 network information
IPv6 is ready and runinng at IETF venue. see http://www.kame.net/ietf48/ for detailed info. you just need to use autoconfiguration, that's all. itojun
