Re: [v6ops] 6to4v2 (as in ripv2)?

[Jeroen Massar]

On 2011-07-30 03:06 , Mark Andrews wrote:
> In message <4e3127f1.2030...@unfix.org>, Jeroen Massar writes:
>> On 2011-07-28 01:36 , Mark Andrews wrote:
>> [..]
>>> Is there *one* tunnel management protocol that they all support or
>>> does a cpe vendor have to implement multiple ones to reach them
>>> all?  I'm pretty sure I know the answer to this question but I'd
>>> love to be proved wrong.
>>
>> There is no 'one' solution to the problems that they are solving.
>>
>> As such there tend to be a combo of:
>>  - static proto-41 tunnel
>>  - 6to4
>>  - 6rd
>>  - TSP => dynamic NATted addresses
>>  - proto-41 + heartbeat + TIC => dynamic public addresses
>>  - AYIYA + TIC => dynamic NATted addresses
> 
> I was more thinking about commonality with tunnel brokers.

These all are implemented by "tunnelbrokers", be they tunnel brokers
where you can just fill in the details yourself (6to4) or the others
where the parameters are provided by the entity you want to connect to.

> 6rd is not a replacement for 6to4 as it requires ISP involment or
> someone to create a registry of 3rd party 6rd providers along with
> associated parameters sets similar non anycast 6to4.

6rd is then also intended for a per ISP deployment.

> static proto-41
> tunnel is also not a viable replacement as it doesn't handle address
> reassignment at the CPE end.

See the "proto-41 + heartbeat" option, that is standard proto-41 but
with a side-channel which beats where the endpoint currently is.

But why are you trying to replace 6to4? What are the requirements that
you have that are not satisfied by any of the above methods?

Greets,
 Jeroen
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [v6ops] 6to4v2 (as in ripv2)?

[Jeroen Massar]

On 2011-07-28 01:36 , Mark Andrews wrote:
[..]
> Is there *one* tunnel management protocol that they all support or
> does a cpe vendor have to implement multiple ones to reach them
> all?  I'm pretty sure I know the answer to this question but I'd
> love to be proved wrong.

There is no 'one' solution to the problems that they are solving.

As such there tend to be a combo of:
 - static proto-41 tunnel
 - 6to4
 - 6rd
 - TSP => dynamic NATted addresses
 - proto-41 + heartbeat + TIC => dynamic public addresses
 - AYIYA + TIC => dynamic NATted addresses

TSP conveys configurartion information inline with the UDP packets.
TIC is solely for configuration information and does not do tunneling
but can be used for all proto-41/heartbeat/AYIYA protocols (and for
instance AVM chose to only do proto-41 + heartbeat as their devices
always have public IPv4 IPs).

Teredo is only for a single host thus is not useful for CPEs and thus
not included in them.

> One of the advantages of 6to4 anycast is that it is just needs a
> check box to turn on and off.  Everybody speaks the same thing.

Except that it does not work behind a NAT and most people do sit behind
a NAT.

Next to that those anycasts are even rarer around the world and on top
of that it is hard to figure out issues when they are there (although
some people have tricks to apparently debug them, the anycast on both
IPv4 and IPv6 requires one to contact a lot of folks).

The big advantage over a known tunnel endpoint is the known behavior of
that endpoint and the simple way of complaining when something is
broken. And people fortunately do complain when stuff is broken,
unfortunately not always with the proper details though, but I am to
blame for not finishing that program up...

> Another advantage of 6to4 is it doesn't require manual intervention
> on renumber events.  Manual tunnel don't pass muster.

I guess you are one of the lucky people to get a public static IPv4
address prefix at home that never renumbers? Guess what, most of the
world does not have that luxury, they get 1 dynamic address and for
instance in Germany they get a disconnect/force-renumber every 24 hours
(according to the ISPs because of 'accounting' reasons...)

Do realize that when you have that public IPv4 address, when it changes
you are renumbering your 2002:::/48 prefix everywhere. Fun...
(I hope you also like asking 6to4.nro.net everytime to change your reverse)

The tunnels above all have ISP-supplied prefixes and tend to be static
(I think TSP anonymous tunnels rotate addresses, but the majority just
keeps on returning the same static allocation, in the case of SixXS you
really get a fixed address, much easier on the PoP side and we can do
whois and store it in the relevant RIR registry)

> Another advantage of 6to4 is you don't have to register.  For most of
> the tunnel brokers you have to register.

I guess you also where able to anonymously sign up to your IPv4 ISP!? :)
Especially that static IPv4 address must be wonderful to get that way.

Note that Freenet6 offers 'anonymous' tunnels, thus that is just a TSP away.

Something with the amounts of abuse made us (SixXS) require that we
require valid address data. Next to that it is a RIPE requirement to
register /48 prefixes. Other Tunnelbrokers just started blocking things
like IRC and NNTP because there was too much abuse or traffic
We kill off accounts of people when they abuse, google my name and you
will find various people who where caught in the act and are quite mad
that they can't have funny vhosts on IRC anymore and attract 500mbit
DoSses and other such nonsense which are not the goal of providing IPv6.

Also, the registration means that people can just type in their
username/password (and optionally which tunnel they want to use out of
the multiple tunnels they might have) in their CPE and the CPE then uses
TIC or TSP to fetch this configuration and set it all up, and it will
just work(tm).

As a nice example see http://www.sixxs.net/wiki/images/FritzboxHowto.jpg
and
http://www.sixxs.net/wiki/Fritz!Box_7270

Next to that knowing where the user is and more importantly their
endpoint allows one to select a proper PoP for that user close to their
endpoint causing low latency and generally high throughput.

With anycast you are just hoping that that all will work.

Greets,
 Jeroen
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [v6ops] 6to4v2 (as in ripv2)?

[Jeroen Massar]

On 2011-07-27 20:21 , Keith Moore wrote:
> On Jul 27, 2011, at 11:35 AM, Tim Chown wrote:
> 
>> I suspect, but have no proof, that the huge majority of 6to4 users don't use 
>> it intentionally, and the content they are trying to reach is also available 
>> over IPv4. But for people who want to develop and use new IPv6-specific 
>> apps, then either a broker or something like OpenWRT ought to meet their 
>> needs?
> 
> tunnel brokers suck if the tunnel endpoint isn't near your current network 
> location.

Let me rewrite that sentence for you:

 "transition mechanisms suck if the tunnel endpoint isn't near your
current network location"

It does not matter much if that mechanism is static proto-41 (6in4),
6to4, AYIYA, TSP, PPTP, HTTP Proxies or whatever, there is going to be a
bit more latency if they are not directly next to you. Not much you can
do about except deploy more of them or

And this will always be the case unless you deploy enough of them in all
places possible. For SixXS we are at 48 boxes around the world,
Hurricane has 25 and Gogo6 has 4 of them of their own for Freenet6 and
then there are 4 others at other organizations and there are a couple of
other services out there which provide tunnels see:

 http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers

> there are currently no universally applicable, or even widely applicable, 
> v6-over-v4 solutions.

For your set of requirements maybe but especially Tunnel Brokers are
working very well for a lot of people and if one sees the traffic stats
on Teredo and 6to4 nodes due to this little thing called NNTP I would
state that those are doing quite fine too for giving access to what
people need to get to.

Your major requirement seems to involve latency though, thus as such,
there is only one thing to do, get one of those boxes deployed locally
to your endpoint.

Do note to yourself that the next issue you will run into that the
service you are actually contacting will be far away, and you suddenly
understand that you need that Akamai content box and a Google one and
various other closeby too ;)

If you want to solve your problem though, I guess for HE you'll have to
give them connectivity to their network and space in a rack for a box,
gogo6 will sell you a box and for SixXS you provide the box+connectivity
and we'll set up the software for free for you and handle the tunneling
completely.

Greets,
 Jeroen
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [v6ops] 6to4v2 (as in ripv2)?

[Jeroen Massar]

On 2011-07-27 18:03 , Mark Andrews wrote:
[..]
>> b) use a tunnel broker - this works much better through NATs and with dynamic
>>  IPv4 addresses
> 
> For which there is only experimental / ad-hoc code.

You call my code Experimental/ad-hoc? :)

Like a good whiskey it matured over the years and hopefully soon I will
be releasing the next edition of AICCU which solves, at least in that
implementation, a couple of quirks that we have encountered in the
recent years.

> Please name
> CPE vendors that support tsp?  Please name CPE vendors that support
> tunnel re-configuration on re-number.

I don't know about TSP, but for the combination of TIC/heartbeat + AYIYA
in some cases there are a variety of vendors, amongst which AVM
Fritz!Box, Draytek, ZyXel Motorola, and various others I tend to forget
;) I unfortunately do not have an exact list of devices/models as I had
nothing to do with them, we just get users saying that they have a
device which supports it ;)

The fun part though with CPEs is that they tend to sit on the public IP
address, which is also the reason why the Fritz!Box only does TIC/heartbeat.

And of course every self respecting distribtion has support for it too
by just adding AICCU, that includes the various WRTs, pfSense, m0nowall,
Astaro and many many others.

As you said, everybody can decide themselves what options they add ;)

Greets,
 Jeroen
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Actual IPv6 deployment observed

[Jeroen Massar]

Arnt Gulbrandsen wrote:
> Iljitsch van Beijnum writes:
>> You do have to understand that IPv6 support was available in 
>> BitTorrent clients for a long time, but then the Pirate Bay deployed 
>> trackers (servers) that were incompatible with the existing clients, 
>> so only people who both have IPv6 and a recent IPv6-capable client
>> are  in those numbers. I had to null-route the PB IPv6 address to get
>> my  old client to work again over IPv4...
> 
> So considerably more than 1% of random filesharing users have IPv6
> already? I assume that also means >1% of random DSL connections have
> IPv6 already.

No, it is not "Native IPv6 over DSL" or any other form unfortunately.

ou have to start thanking Microsoft for pushing 6to4 and especially
Teredo, having it automatically on new platforms and having clients like
uTorrent auto-enable it on install for those that don't.

For instance read a bit here:
http://mailman.nanog.org/pipermail/nanog/2008-August/003051.html

Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF 78 Annoucement

[Jeroen Massar]

Ole Jacobsen wrote:
[..]
> Train time is around 3 and 1/2 hours with 3 changes, but I'd actually 
> recommend going all the way to Utrecht on the German ICE which gives

If you are going to hop over Utrecht, better just take a direct flight
to Amsterdam (AMS) :)

For The Netherlands, one can plan train rides using: http://www.ns.nl
Top right corner has a link to the English edition.

Amsterdam->Maastricht will take at least 3 hours though... :(

Greets,
 Jeroen

(and Zurich->Maastricht by train is also 8 hours, or by plain 3 train +
3 plane would make 6, oh well, bit silly though for that short distance,
lets see how Hiroshima works out at least I get to see something new then ;)



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Extending the Dean Anderson PR-action to lists on tools.ietf.org

[Jeroen Massar]

Cullen Jennings wrote:
[..]
> Sam, not disagreeing with anything you are saying here but none of this
> helps me understand why Dean should be blocked. [Note, I'm not saying
> this blocking is right or wrong, just that I don't understand why].
> Should someone who is subject of a PR action just be automatically
> blocked from all IETF lists?

With all the nonsense caused by this person with his 'dishonest' lists,
I would say YES.

I am very delighted that Henrik took those actions and fully support
that decision in light of the PR action and all the abusive nonsense
that the individual is causing.

Greets,
 Jeroen
  (who fortunately is able to configure all his MX's to nicely reject
   mail from that individual and all his silly mailinglists, to avoid
   having to read the nonsense, and worse, get mail doubly which
   completely messes up message sorting and thus causes a lot of work,
   and there is enough of that already)



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Problems accessing www.ietf.org over IPv6

[Jeroen Massar]

Robert Moskowitz wrote:
> I have a /48 native IPv6 prefix routed to my home lab.
> 
> I come back from IETF, and Firefox 3.0.6 is hanging accessing
> www.ietf.org on my duo-stack Centos 5.2 laptop.

That is called a Path MTU issue.

As you have a Linux box, install the tracepath6 tool (iputils-tracepath
on Debian, probably similar package for an RPM distro) and then do a
"tracepath6 www.ietf.org" and you will see where it goes wrong, then
contact your provider and pass them that info.

It is kinda funny to see big old AT&T hanging behind OCCAID; I hope the
secretariat is not paying AT&T too much for that kind of 'transit'.
(seems that Sprint and Telia also have the route but don't play transit
for AT&T thus the only transit for AT&T is OCCAID...) Lets hope that
improves soon...

Greets,
 Jeroen

--

jer...@purgatory:~$ tracepath6 www.ietf.org
 1 : [LOCALHOST]  pmtu 1500
 2:  gehenna.ch.unfix.org   1.581ms pmtu 1480
 3:  xen-gw.zrh.sixxs.net  26.816ms
 4:  ipman.zrh.sixxs.net   29.298ms
 5:  ge0-3.br01.zrh254.ipv6.ip-man.net 29.472ms
 6:  pos3-0.cr01.gva02.ipv6.ip-man.net 33.045ms
 7:  srp1-0.cr01.gva16.ipv6.ip-man.net 33.928ms
 8:  pos2-0.br01.ams254.ipv6.ip-man.net51.227ms
 9:  amsix.r1.ams2.nl.opencarrier.eu   53.085ms
10:  opencarrier-ams-px.occaid.net 71.227ms
11:  bbr01-p1-0.nwrk01.occaid.net 143.202ms asymm 12
12:  r1.mdtnj.ipv6.att.net194.826ms
13:  2001:1890:61:9017::2 270.532ms
14:  mail.ietf.org263.312ms reached
 Resume: pmtu 1480 hops 14 back 51




signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Subscriptions to "ietf-honest"

[Jeroen Massar]

Joe Abley wrote:
> 
> On 23-Mar-2009, at 14:35, Melinda Shore wrote:
> 
>> I was auto-subscribed to Dean's "ietf-honest" mailing
>> list, and I'm unhappy about it.
> 
> As I think was mentioned a day or two ago on this list, the reasonable
> way I found to avoid these auto-subscriptions to ietf-honest was to
> block packets from the originating network. I had a very enjoyable few
> days following the installation of those packet filters.
> 
> However, it now seems that (a) any address I've used in the past is now
> fair game, and not just the addresses I'm using today, and (b) it's not
> just the ietf list, but working group lists too, e.g. see below. I don't
> have the same ability to do server-side filtering or packet blocking on
> other mail accounts.

Seems he wants the core of the Internet to apply those filters...

I must say that I love the wording:

>> This list was created by IADL.ORG (www.iadl.org) because of dishonest
>> filtering by the IESG.  See http://www.av8.net/IETF-watch for more
>> information on the corrupt activities of officials of the Internet
>> Society, Inc (ISOC) IETF Activity, and their connection to other
>> corrupt activities.

Those are clear allegations of corruption. Isn't that what the IETF
calls an ad-hominum attack? Wasn't there something about that about
causing subscriptions to be able to be blocked etc?


>> You were probably added to this list because you participated in
>> dn...@ietf.org discussion, and that list is used to determine
>> consensus for ISOC IETF Activity actions. Consensus is a democratic
>> activity of the ISOC, which is a U.S. non-profit, tax exempt
>> membership corporation. ALL members of the ISOC IETF have a property
>> right to participate in its democratic decision processes.   [see U.S.
>> v. Local 560, extortion (Hobbs Act) and racketeering by mafia that
>> took over a Union and tried to prevent participation by those opposing
>> the mafia]

Nice one, the IETF is compared to the Mafia.

>> [..] IETF representatives (e.g. Working Group Chairs) have a duty
>> to the  corporation to read email sent to them on IETF business, and
>> should not try to unsubscribe.

And here it goes: as a WG chair you are not able to unsubscribe, you are
not even allowed to try. Nice Mafia-alike practice.

I didn't know that the IETF was incorporated btw. All news to me ;)

Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Reverse IPv6 DNS checks on ietf MXs?

[Jeroen Massar]

Tim Chown wrote:
[...]
> It's not uncommon for IPv6 servers to be multiaddressed, so mail admins
> will probably just need to be a wee bit more careful, and certainly try
> to avoid using autoconf globals on servers.

Nothing wrong with EUI-64 or autoconf, as long as you actually want them
there ;)

and otherwise on eg Linux:
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.all.accept_ra=0
other mechanisms hopefully available on your favourite OS.

As for the IETF mailservers rejecting it, clearly there was a
misconfiguration and they caught that perfectly fine. Misconfigured
boxes should not be able to send out mail, there is most often other
things also misconfigured then and/or they are not monitored and thus
just used for abuse.

> In our case our server
> acquired an additional global autoconf address on top of its manually
> configured address, which it started sending from, and as this had no 
> reverse DNS entry we encountered the Rejects.

I suggest installing NDPMon (http://ndpmon.sourceforge.net/) next to
your arpwatch that you should have running for IPv4. Of course
protecting your L2 with 802.1x or a similar system next to that is also
a good hint.

BTW: for postfix, smtp_bind_address6 allows you to fix the outgoing
address to a certain IP (smtp_bind_address for IPv4 ;)

Greets,
 Jeroen




signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Hey my local ISP has IPv6 connection!

[Jeroen Massar]

Marshall Eubanks wrote:
> Can you share their name ?
> 
> Should we start a site listing IPv6 providers ?

Something like:

 http://www.sixxs.net/faq/connectivity/?faq=native

Which lists quite a number of them already, there is also a link to the
Japanese service providers of which there are quite a few more.

> On Oct 29, 2008, at 10:18 AM, Hallam-Baker, Phillip wrote:
> 
>> Did a ping this morning from my residential broadband, was surprised
>> to see responses from an IPv6 address.

6to4/Teredo etc make connectivity possible semi-automatically in a lot
of places, thus without seeing source addresses and a traceroute it
doesn't say that you are native at all; and when it is not native, then
most very likely your local ISP doesn't have much to do with it.
But as can be seen in the above URL, there are ISPs which are already awake.

Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Be aware when traveling to the USA.

[Jeroen Massar]

Truman Boyes wrote:

Hi there,

According to the US Customs and Border Protection Policy document it 
appears that search and seizure at border/immigration centers does not 
apply directly to sealed letter class mail; and documents inside sealed 
letter class mail may not be read by officers without a appropriate 
search warrant.


For folks concerned about this, do at least read:
http://www.cbp.gov/linkhandler/cgov/travel/admissability/search_authority.ctt/search_authority.pdf 


as it might clarify some things which might be misunderstood otherwise.

That document also mentions:
"Notwithstanding this law enforcement mission, in the course of every 
border search, CBP will protect the rights of individuals against 
unreasonable search and seizure."


Unfortunately they don't specify what they call unreasonable, as IMHO 
this whole 'mission' of them described in that PDF is unreasonable.


How about mailing yourself a USB drive with encrypted data and taking 
that along for the trip.


Or what about, trying to use this great invention called... The Internet

Which kind makes it completely useless for them to be doing this in the 
first place (IMnsHO) because the people who want to bring data from A to 
B will just send it that way and nicely over all kinds of secure 
channels. Then again, a plane full of tapes is faster than most internet 
connections of course.


I am still wondering what the real reasoning is behind this lame 
security theater setup. It is just another annoying step from wanting me 
to go there.


For me the procedure seems simple and applies actually to any case where 
you might expect your data/hardware to be stolen (it is the same thing 
in my opinion if they take it with law behind them, or a thief just 
steals something from me):


 - Don't bring along anything you don't want others to get
 - For the hardware you bring along before entering _and_ leaving
   the country:
- use shred(*1) on the full disk and other media you have
- re-install a full copy of $distro, so that you have the tools
- just have one account: username=root, password=root
  Then after arrival, download and use your data, before leaving
  (might take 8 hours++ for the shred) upload your data to your
  internet host, shred+re-install in the same way.

Now if they want your laptop or other hardware/storage, you can just 
give it up, yes, you loose them for some time, but there is nothing you 
have really lost. Yes, it is, like every other Security Theater, very 
annoying, but at least you avoid the problem where you loose something 
you didn't want to loose, and you can also just tell the guys there 
"this is my re-install cd, you can have it, you'll figure out that there 
is nothing on this thing that can be illegal or violating anything"


Don't forget that your PSP or DS, that you are using in-flight, might 
also contain precious save-games especially after 8 hours of gaming 
in-flight), so don't forget to figure out a way to back-up those after 
landing ;)


Of course, one can always make use of Tor (http://www.torproject.org/) 
to send your data around so that you'll remain quite anonymous too.


For these kind of nasty rules, we'll just have to bend over and keep on 
smiling (but not too much, because they won't like that either...)


Greets,
 Jeroen

*1 = 
http://www.gnu.org/software/coreutils/manual/html_node/shred-invocation.html




signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: problem dealing w/ ietf.org mail servers

[Jeroen Massar]

Kurt Erik Lindqvist wrote:

On 8 jul 2008, at 20.41, Keith Moore wrote:

[..]
I disagree that it doesn't work for servers.   (Or it would be better 
to say that I'd like to know why you think it doesn't work for servers.)


People have personal opinions, one likes this, the other likes that, 
maybe it works for you, maybe it works different for me.


Well, when I change that broken NIC in my server, it will receive a new 
address that needs to be reflected in the DNS.


Which is why EUI-64 is a great method on combination with RA to do 
autoconfiguration, but if somebody (for whatever reason they have) want 
to use those 64bits differently (eg using DHCP or static config) they 
should definitely do so, it is their network after all, and there is no 
meaning in those bits.


EUI-64/RA is just to make some cases (the dental office one for 
instance) really simply, but it is not a solution for everything else.

Pick and use what is useful...

BTW: Most OS's allow overriding of the MAC address, next to of course 
just configing an "automatic EUI-64 address" as a static one on an 
interface ;) Your network, your rules, your problem if you peep it up.


Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: problem dealing w/ ietf.org mail servers

[Jeroen Massar]

John C Klensin wrote:


--On Friday, 04 July, 2008 10:46 +0200 Kurt Erik Lindqvist
<[EMAIL PROTECTED]> wrote:


On 3 jul 2008, at 15.57, Jeroen Massar wrote:

[..]

Which (autoconfig) you should either not be using on servers,
or you   should be configuring your software properly to
select the correct   outbound address. (I prefer to use the
autoconfig one for   'management' and using a 'service
address' for the service).


What a shame that's not what's in the RFCs..:-)


Despite the ":-)", I think there is an important question here.

>

Does it imply that this is a use case from which we should be
learning... and then fixing the RFCs?  Or that you believe that
the RFCs are correct and Jeroen's analysis is incorrect?   


I guess/hope he is just teasing ;)

As I privately replied to Kurt already, RFCs are Requests For Comments, 
as such what I am giving is definitely a comment, and the only way to 
solve it for real and to give some guidance is to move this problem to 
v6ops (which I think is the most appropriate WG) and document scenarios 
that guide people on how to possibly configure a network using IPv6.


Of course people could also just get a good book and/or use common 
sense, unfortunately that is not always happening, especially the latter.



I hope it doesn't mean "the RFCs ought to govern, even when
reality and experience seem to contradict them".


See my message to ietf@ + v6ops@ titled:
"Draft on how to correctly configure servers and other hosts (IPv4+IPv6)
 (Was: problem dealing w/ ietf.org mail servers)"

As RFC's can be updated as much as we want and they definitely are not 
final.


Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Draft on how to correctly configure servers and other hosts (IPv4+IPv6) (Was: problem dealing w/ ietf.org mail servers)

[Jeroen Massar]

(That draft would basically be a BCP, cc'd to v6ops where this belongs)

[EMAIL PROTECTED] wrote:

I think I could have been clearer with my message.[..]
Instead, I was presenting what I thought was an interesting example of a 
subtle problem that can come up in ipv6 deployment.  


I think it is a good idea to document common examples of how one could 
setup a datacenter, or at least a small network. One thing to note is 
that people should stop thinking in IPv4 terms. Yes, IPv6 is in effect 
only more bits, but those bits belong to you and you can use them to do 
all kinds of new interesting setups as you are not limited any more to 
what you are doing with respect to address usage.


Generally the ideas for a network I follow are:

 - autoconfig (or if wanted DHCPv6) for hosts (client+server)
   Turn off RFC3041 on all hosts (it is just annoying IMHO :)

 - for servers use the autoconfigged address for 'management' purposes

 - for services, use a /64 per service, or just use one with all
   services. Call these 'service prefixes'.
   Thus DNS could be ::53/64. Then you can use quagga or similar to
   do OSPF/BGP/whatsuitesyou on the server and announce that it is able
   to serve DNS, just announce the ::53/64 (or /128 or whatever)
   everything in the network can use ::53 for DNS resolutions.
   Of course the side-effect is that you can just setup another host and
   do the same trick, then have some scripting on those hosts to check
   if the service is actually working and retract announces when needed.
   Voila a very nice distributed-by-anycast-local-service setup.
   Repeat this trick for any service you want. Remember, if your service
   becomes busy, just add another box, or just move it to another etc.
   Also, if the MAC of the box dies, it is unrelated to the actual
   service and outages will be kept to a minimum. This of course works
   for http-proxies/smtp-servers/imap-servers etc.

   Note that for the service prefix, as it is generally only for serving
   local clients, one could quite well use a ULA prefix, which will
   thus will never change even if changing upstreams or disconnecting
   etc. YMMV on that one though. Note that you just need a route to that
   ULA prefix and can avoid clients having to have a secondary address
   in that range. Benefit for ULA prefix is of course that automatically
   it will be hard for external sites (The Big Bad Internet) to reach
   these services as they don't easily get a working TCP bidirectional
   path to it.

 - Forward/Reverse DNS, I simply register the EUI-64's in DNS,
   hardcoded. One can of course with DHCPv6/(Secure-)DDNS also do it
   dynamically if wanted. If you are a Windows-shop Active Directory
   can also help you out in this area. It depends a bit on what you
   require, how many hosts you have and also how much control you have
   over these hosts.

 - DNS resolving is configured either static (we have the service prefix
   which will most likely never change anyway if lucky) or you could
   simply do it using DHCPv4||v6.

 - Don't forget to properly configure your firewalls ;)


Another note for a lot of people who use a VPN when working from home 
but where the VPN is only IPv4-capable. When you are at home you will 
have a (public) IPv4 address, an IPv6 address and a VPN-IPv4 address, 
but no VPN-IPv6 address, thus most likely the Internet-IPv6 address will 
thus hit the firewall and die off there. Thus if you have 
[EMAIL PROTECTED], 's in the DNS you won't be able to reach them and 
hilarity ensues as this will cause lots of connections delays due to 
most firewalls dropping connections, not rejecting them. Thanks to our 
marvelous IS team here though I found out that ISATAP is a perfect 
solution to this problem as it automatically sets up tunnels locally 
when needed, as the VPN IPv4 is 'local' the tunnel works and you can 
reach resources which would be firewalled when using the global address. 
Which reminds me to quickly write&submit another draft I had in my head 
on that subject.



The mailserver in question uses a default redhat enterprise build (actually
centos).  ipv6 is either enabled by default, or just has a single check box,
with no further information.  The fact that ipv6 is enabled so trivially
carries the implication that just enabling ipv6 won't actually damage
anything. 


Unfortunately if people just click they will open a lot of things that 
are not needed and can cause issues, for them bot more importantly for 
others. As that means that the box is not properly configured, clearly 
as the 'admin' didn't care, why would anyone then even care to receive 
mail/traffic from them?



Now I know different.  Just enabling ipv6 on an otherwise correctly
configured and functioning ipv4 box *will* cause damage -- it will cause mail
that would have been delivered to not be delivered.  I could be wrong, but
this strikes me as a trap that lots of people could fall into. 


People who make those mistakes ar

Re: problem dealing w/ ietf.org mail servers

[Jeroen Massar]

On Wed, Jul 02, 2008 at 10:47:53PM -0700, 'kent' wrote:
[..]

However, this last address, 2001:470:1:76:2c0:9fff:fe3e:4009, is not
explicitly configured on the sending server; instead, it is being implicitly
configured through ip6 autoconf stuff:


Which (autoconfig) you should either not be using on servers, or you 
should be configuring your software properly to select the correct 
outbound address. (I prefer to use the autoconfig one for 'management' 
and using a 'service address' for the service).


SMTP shows that it is perfectly usable for these situations as it nicely 
rejects the message with a proper message automatically telling you on 
how to solve it.



That is to say, it appears the ietf.org mail server is probably now rejecting
mail from *any* box that is getting a default global ipv6 address, since
those addresses will most likely not be in ip6.arpa.  There may be a whole
lot of boxes in this situation. 


Those boxes are not set up correctly thus should not be sending email in 
the first place. For that matter you should actually be 
firewalling+logging port 25 outbound so you can monitor any host in your 
network doing illegal SMTP connects. Spam bots don't use IPv6 yet 
(afaik), but when they are aware how 'open' everything is and especially 
that RBL's don't exist yadda yadda, they might just switch over to that.
Good that the mainstream spamreceivers (gmail/yahoo/etc) don't have IPv6 
yet as that would change that scenario.


Configure your mailservers correctly, it helps you send out mail, and it 
helps avoid others receiving crap from you.


Greets,
 Jeroen

--

For postfix folks:
http://www.postfix.org/IPV6_README.html
8<
/etc/postfix/main.cf:
smtp_bind_address6 = 2001:240:587:0:250:56ff:fe89:1
>8
Other SMTP servers have similar mechanisms.



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Multicast and charging (Was: Was it foreseen that the Internet might handle 242 Gbps of traffic for Oprah's Book Club webinars?)

[Jeroen Massar]

Patrik Fältström wrote:
[..]
I am afraid that this is the sort of reasoning that has lead to P2P 
having such widespread use.


I fully agree, (unicast) P2P is a godsend for Transit operators.

The fun with "p2p" is though, that HTTP is also peer to peer and actually 
anything unicast is p2p from a design point of view ;)


Is not one of the problems of exchanging multicast packets that someone 
that receive a multicast packet do not know how much bandwidth in the 
internal network that packet in reality will take? If the incoming 
packet is a unicast packet, there is a 1:1 relationship between incoming 
and outgoing packets. With multicast, one might have to send >1 packet 
out over the egress after receiving a packet?


Generally a network is a tree, unicast will mean you get a packet per branch, 
multicast you get 1 packet for all branches. As such your traffic is less. 
Though indeed, if you get 1 packet from your transit (thus at the root of your 
network), it takes up 1 packet everywhere else in your network. But you only pay 
your transit for 1 packet, not the zillion of branches that you might have and 
thus not for a zillion of packets.


AFAIK the biggest problem with multicast is management though. Not evening going 
onto the subject of it being available in hardware for most platforms...


If so, could not new models of charging be that if A send multicast 
packet to B, "the number of packets sent" are the number of packets 
going _out_ from B, not in to B? If it was possible to do such 
accounting...


Multicast account is simple: you do it at the place where you measure, same as 
unicast.


Thus if you have:
   /> H
  /-> I
   /---> E--> J
A ---> B ---> C ---> F
   \   \---> G
\
 \
  \---> D

For multicast, if you have clients everywhere, at A you see 1 packet and at H 
you see 1 packet, but that same packet is also at I J etc.


For unicast you see  times packets at A and 1 packet at each client.

As such, an ISP (B) who has clients C,D,E,F,G..., will pay Transit A, in case of 
Multicast 1 packet, while for unicast he would pay Transit A for  
packets. In both cases though ISP B will charge his clients for that single 
packet. As such, multicast makes money for B, but not for A.


Transits thus don't like it, ISP's don't get it.

Greets,
 Jeroen

(This all reminds me to put working multicast on the list again for SixXS...)
u



signature.asc
Description: OpenPGP digital signature
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Was it foreseen that the Internet might handle 242 Gbps of traffic for Oprah's Book Club webinars?

[Jeroen Massar]

Patrik Fältström wrote:
[..]
P.S. And if multicast is in use, or unicast or some othercast, that is  
from my point of view part of the "innovation" the ISPs have to do  
(and will do) to ensure that the production cost is as low as possible  
so that their margin is maximized.


I actually see a bit of a problem here as multicast would lower the usage of 
links, as such, they can't charge as much as with link that is saturated with 
unicasted packets. Thus to lower the use in the internal network one would use 
multicast, but the client would then still have to get unicast so that for every 
listener they are actually paying...


Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: PTR for IPv6 clients (Re: IPv6 NAT?)

[Jeroen Massar]

Harald Alvestrand wrote:

Mark Andrews skrev:

You also don't want to do it as you would also need massive churn in
the DNS.

Microsoft gets this wrong as they don't register the privacy addresses
in the DNS which in turn causes services to be blocked because there
is no address in the DNS.

>

perhaps the advent of IPv6 will result in people finally (*finally*)
giving up on this sorry excuse for a security blanket? (calling it a
"mechanism" is too kind)

Or perhaps it'll just make people register wildcard records at the /64
level in ip6.arpa :-(

 [EMAIL PROTECTED] (MY, what an useful
reverse map!)


Like a lot of things, "it depends".

For SMTP/SSH and for management-alike protocols requiring proper
reverse -> forward -> reverse mapping is IMHO a good thing.

Clients & servers using these protocols  should be on stable & trackable 
addresses. (of course you an set a low TTL etc, that is why one should 
always log the name + IP, the more information the better). With 
management I mean for instance reverses on router IP addresses, as it 
makes traceroute so much more informative, also reverses on servers etc.


For SSH you will most likely have firewall rules in place anyway. SMTP 
should similarly only be allowed to clients that are in your client 
list. One doesn't have to require r->f->r if the client is in your 
client-list of course. Your server, which talks to other SMTP servers 
outside of your control, should be on a stable IP and have functioning 
r->f->r. For SMTP the current track of mind is: no reverse, no 
communication. Which stops most of the spam already, as that client is 
clearly not configured correctly to do inter-domain SMTP.


For that matter anything that is 'stable' should (note should) IMHO have 
a proper r->f->r.


For any other protocol _requiring_ reverse is silly IMHO.
You don't need it for HTTP, you don't need it for BitTorrent etc.
Having reverse in those cases is nice, as it might give extra 
information (eg the remote is most likely dsl as it contains 'dsl' in 
the reverse), but it is always a guess and might quite well be faked.


The biggest issue with the use of reverses tends to be with applications 
which only lookup a reverse, but don't check if the r->f->r link is 
complete.


Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
IETF mailing list
IETF@ietf.org
http://www.ietf.org/mailman/listinfo/ietf

Re: Presentation on IP address shortage

[Jeroen Massar]

Henning Schulzrinne wrote:
I'm looking for a reasonably recent presentation on the state of IP  
address allocation that would be suitable for a class I'm teaching.


See: http://www.potaroo.net/tools/ipv4/index.html

or for a 'recent' presentation:
http://www.ripe.net/ripe/meetings/ripe-55/presentations/huston-ipv4.pdf

also google(geoff huston ppt ipv4 prediction) or google(tony hain ppt 
ipv4 prediction), permutate with pdf ;)


Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf

Re: Eating our own dog food and using SIP for telephony... (was Re: My view of the IAOC Meeting Selection Guidelines)

[Jeroen Massar]

Dan York wrote:
[..]
P.S. How many folks out there have phones (hard or soft) from which they 
can place calls to other random SIP endpoints?  (I do, but also realize 
I'm in a minority.)


I know quite a number of people who have and are actively using SIP 
phones. I personally am a great fan of the Siemens S450IP/S675IP[1], 
just plug it in, go to the webpage, configure, works, and the fun thing 
is, it is a normal phone, thus plug in POTS and that also keeps on 
working. I donated one to my folks, and now it is publically known how I 
can call up my mum for free (except inet&hardware&power etc costs) for a 
couple of hours if I am cooking something up again ;)


The problem at the moment with SIP is:
 - STUN works, but is sorta annoying to setup
 - E164 support is not there yet (just try to get your number
   registered in e164.arpa, workaround: use e164.org)

One big solution would be using IPv6 of course ;)

But:
 - most hardphones don't support this
 - Asterisk doesn't come out of the box with IPv6 *yet*, see [2]

With IPv6 enabled, one can at least avoid the STUN tricks and routing 
the packets over the PBX (eg asterisk) and that would make latency 
better (unless you have bad IPv6 connectivity) and thus even more enjoyable.


Currently, the S675IP with a Asterisk box works like a charm though and 
it is what I use daily for calling up people and getting called.


Greets,
 Jeroen

[1] = http://www.voip-info.org/wiki/view/Siemens+Gigaset+S675IP
[2] = http://www.asteriskv6.org/



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf

Re: IETF 72 --> Dublin!

[Jeroen Massar]

Jaap Akkerhuis wrote:
[..]

And it seems the the resort is build
on the meadows used by the fairies.


Fairies hebben geen heibel gemaakt want de golf-velden daar liggen er 
super mooi bij.


Er is ook een helicopter landplaats daar, wat wellicht een goede optie is :)


I'm afraid that the potheen
will be less available then it used to be. That's progress I assume.
What makes me think the public transport might have improved although
the traffic jams might be a new problem.  That's progress again.
Maybe can rent a bike.


Een ding wat je dus NIET wilt doen is fietsen in Dublin.

Het gaat best op zich hoor, maar je moet wel heel erg oppassen en het 
liefste over de stoep fietsen. Vooral bussen en taxis hebben namelijk 
nogal de rare neiging om fietsers gewoon maar de kant (lees: muur, paal, 
andere autos) in te drukken. Ik heb er een jaartje gewoont en veel 
gefietst, want dat openbaar vervoer is NIETS, nog erger dan de NS in 
nederland (al is de trein redelijk de paar keer dat ik hem gebruikt 
heb): ze hebben geen echt schema voor de bussen, er komen er dus gerust 
twee achter elkaar en dan heel lang niets, als je je hand niet opsteekt 
stoppen ze niet. Ze vergeten te stoppen, ook al druk je tig keer op de 
knop of zeg je het tegen de chauffeur dat ie hem toch echt gemist heeft 
etc. Oh en dan natuurlijk het verkeer, muur vast want de straten zijn te 
smal en de bussen passen er eigenlijk niet door heen, daarnaast stopt er 
een, en de andere erachter moet dan maar wachten, etc, etc. Ramp dus, 
dus pak je als nederlander lekker de fiets. Aanrader, koop schoenen 
zoals ik heb: 
http://www.underground-cybershop.co.uk/acatalog/info_UR_044_L_BLK.html
Juist ja, zware schoenen met mooie keiharde plastic neuzen en een tikkel 
metaal zodat, als er weer een bus over je tenen rijdt omdat die het leuk 
vind om je de kant in te forceren je iig geen platte tenen overhoudt, 
nee idd deze schoenen deuken niet :)


Platte land, dus in de buurt van dat hotel is het overigens goed te doen 
hoor, want je zit er effectief in de middle of nowhere, maar *in* 
Dublin, probeer de fiets maar niet, taxi is een halve optie, de andere 
manier is de tram nemen, die dan nog half-redelijk rijd.


Enne, vergeet de paraplu niet, want die ga je nodig hebben ;)

Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf

Re: IETF 72 --> Dublin!

[Jeroen Massar]

Ross Finlayson wrote:

Excuse me, but isn't this in the boonies way outside town? Are we
going to be stuck in a $200 a night hotel with no reasonable
alternative accommodations eating vastly overpriced hotel food and
facing a one-hour commute to anywhere else?


How easy will it be to commute between the hotel and central Dublin 
(e.g., if we want to eat lunch or dinner somewhere other than the 
hotel)?  What transportation options are available, and how long will the take?


Bus -> "cheap" (in a sense), but takes about 45mins (ex waiting time)
Taxi -> "expensive", takes about 30 mins

The bus is funny btw, as it only runs once every while, in Dublin that 
will mean that they come at random times and might just not come, or 
there might be two busses directly after each other.


The ride is a nice one though as you are guided through large parts of 
Dublin because of it. For the people with a bit more cash, they have 
heli-pads at that hotel, so you might be able to pull an Oracle and just 
fly in and out, but you should be able to pay the taxi then too ;)


Oh and one major thing not to forget: umbrella's!
No sunshine in that part of the country (unless you are very lucky to 
accidentally hit some sunshine). For sunshine you will have to go south, 
or west, that is, of the country, not of the city ;)
There is one trick around it though: when it starts raining, just jump 
into a pub, take a beer, wait till it is over and go to the next pub 
before it starts raining again, that should keep you busy. For the 
golfers: don't forget to take along a nice wetsuit to keep you dry ;)


Museums are mostly gratis/free and actually pretty good, except for 
instance Trinity College, if you want to see the Book of Kells, the 
Library above it (The Long room, aka The Jedi Archives*) which is 
included in that tour is more worth it though. Don't forget to crash the 
local Eddy Rockets for a Oreo milkshake and a fish&chips place for a 
battered mars bar.


Enjoy ;)

Greets,
 Jeroen

* = http://www.irish-architecture.com/news/2002/000238.htm



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf

Re: IPv6 and email routing, was Re: AAAA records to be added for root servers

[Jeroen Massar]

Tony Finch wrote:

On Fri, 4 Jan 2008, John C Klensin wrote:

However, there is also a rule that, if no MX records are present at a
particular node, the mail system looks for an A RR at the same node and
treats it as if its label appeared with an MX preference of 0.  That
default does not apply to  records, so it is necessary that
operators understand that, if mail systems are to be accessed using
IPv6, they MUST have MX records at the relevant nodes.


The only document that I know of which specifies IPv6 email routing is RFC
3974, which says that  should be treated exactly the same as A. As far
as I know, Exim, Postfix, and Sendmail follow RFC 3974.


It seems that at least Postfix doesn't handle this the way it should do 
it. It does IPv6, but not according to how I understand it which is:


--
all_mxs = dig("dom", "MX");
sort_on_prio(all_mxs);

done = 0;

for (mx in all_mxs && done == 0)
{
all_addrs = dig(mx, "|A");
sort__first_then_a(all_addrs);

for (addr in all_addrs)
{
if (connect_to(addr, 25))
{
ret = try_smtp_exchange();
if (connection_timeout) next;

if (ret == 2xx) done = 1; success(); last;
if (ret == 4xx) last;
if (ret == 5xx) done = 1; DSN(); last;
}
}
}

if (!done)
{
queue_message_for_later_retry();
}
--

Then if we have:
---
example.com.
MX  10 a.example.com.
MX  20 b.example.com.

a.example.com.
2001:db8::11
A   192.0.2.11

b.example.com.
2001:db8::22
A   192.0.2.22
--

'a' & 'b' are both separate MX's. As such according to the above 
pseudo-code, which I deduced from the RFC, whenever 'a' is contactable 
and you can get a response from it, you should honor that response. Thus 
if you contact 'a' and it replies with a "450 Out of diskspace, try 
later" or other temp failure or a 5xx error etc, one should go to 'b'.


Postfix contacts a-, gets a 450 diskspace, then contacts a-A, gets 
the same error again, and then tries b- and then b-A, which might 
accept the message.


We actually noticed this last year because of one of Paul Vixies email 
setups rejects-all over IPv4 but accepts mail on IPv6, but as IPv6 gets 
greylisted (and thus it sends a 450) postfix tried the IPv4 address 
also, which resulted in a 500, rejecting the message, if Postfix would 
have properly followed the RFC like in the above pseudo code then it 
would have requeued the message and tried again a bit later, which would 
have caused the message delivery to succeed.


Indeed it is an odd-case, but it is the way it is specified in the RFC.
Also, the real thing is that one should not retry on the same MX as it 
is the same host, otherwise it would be a different host with a 
different weight in the MX label.


Also indeed, this does also lighten the load on 'email clusters' where 
the MX label has maybe 20 A records or so, as the sender should only try 
once to that MX label, and not try and contact all 20 of them.


Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Transitioning to IPv6 == dual-stack (Re: AAAA records to be added for root servers)

[Jeroen Massar]

Hallam-Baker, Phillip wrote:
[..]
> example.com MX  1 1 1 smtp1.example.com
> smtp1.example.com A 10.1.1.1
> smtp1.example.com  ..

Which is a perfect example of dual-stack.

As for 'home users', they will get an IPv4 NAT while IPv6 will be e2e.

> So what if you can pull up the .com domain via IPv6? The DNS server
> still has to be IPv4 capable or the query will quickly fail at
> microsoft.com, google.com or wherever.

In the mean time:

http://www.microsoft.com.sixxs.org
http://www.google.com.sixxs.org

or:
http://www.kame.net.ipv4.sixxs.org

if you have IPv4 but want to look at IPv6 only sites.

As "The Internet" for most people is SMTP (see above for the solution)
and HTTP (just add a IPv6/IPv4 proxy somewhere) there is not an issue at
all with going to IPv6 except for enabling proxies at the right places,
configuring tools to use them and getting the connectivity to the users.
For everything else SOCKS does still exist.

Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Deployment Cases

[Jeroen Massar]

[EMAIL PROTECTED] wrote:
>>> Unless I've missed something recent, the IETF did not do a 
>> lot of work 
>>> on the scenario where IPv4 islands need to communicate over an IPv6 
>>> Internet, talking to both IPv4 and IPv6 services.
>> It is called dual-stack.
> 
> That seems to simply ignore the issue by saying, let there be IPv4
> everywhere for those who need it. But if there are not enough
> addresses to grow the IPv4 infrastructure, you can't have IPv4
> everywhere.
> 
>> The big question of course is: what exact problem do you want 
>> to solve?
> 
> An IPv4 island, that is blissfully unaware of the IPv4 address
> crunch until far too late, wants to avoid changing their network
> but still maintain connectivity to both the IPv6 and the IPv4 
> Internet. They may have to connect to an IPv6 ISP (for instance
> if their IPv4 ISP goes bankrupt or they move an office location)
> or they may connect to an IPv4 ISP who peers with a dual-stack
> ISP or 6PE ISP. How do they continue to access all Internet services
> from their IPv4 island, regardless of whether or not the services
> are using IPv6 only?

What is so difficult in going dual-stack? IPv4 is NATted, as it already
is at a lot of places, and IPv6 comes in there using a tunnel.

Most 'services' that people use over the internet, fall under either:
 - HTTP -> Use a HTTP Proxy with both IPv4 & IPv6
 - SMTP -> Use a SMTP server which supports both IPv4 & IPv6

Anything else? Not really. As such, which exact services do you want to
transition?

> Note that this is rather similar to the question raised regarding
> the IPv4 outage at an IETF meeting. How does an IPv4 laptop user
> continue to function without interruption when only IPv6 Internet
> access is available at an IETF meeting?

As your source address breaks the moment your connection is interrupted
your have an interruption already. But you probably mean so that they
can continue using service X, well first start by defining service X.

The generic answer is of course NAT-PT, but there is a big reason why we
don't want that. Another trick is totd and there are a number of these
transition functions which are already in place and in use for a long
long time.

As such the sole problem left, which is going to be resolved soon, is
DNS, we will finally have  in the root, next step DNSSEC :)

[..]
>> Stating "I want to connect from IPv4 to IPv6", can mean a lot 
>> of things, is this HTTP? SMTP? or do you really want a 
>> generic solution?
> 
> A generic solution that will work for all TCP and UDP protocols.

NAT-PT, but NAT doesn't understand all the protocols, if it did, then we
would not have to go to IPv6 in the first place.

> I don't believe that there is an IETF solution for this scenario
> which I expect to be a very common scenario specifically because 
> transition to IPv6 is being triggered by an IPv4 address shortage
> whose effects will be felt first in the network core and ripple
> outward from there.

As you clearly believe that there is no such thing, then make a list of
all the things you have tried and where they fail to meet your
requirements. Then make a list of the requirements you are missing and
propose that we solve that problem.

Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Deployment Cases

[Jeroen Massar]

[EMAIL PROTECTED] wrote:
[..]
> Unless I've missed something recent, the IETF did not do a lot of
> work on the scenario where IPv4 islands need to communicate over
> an IPv6 Internet, talking to both IPv4 and IPv6 services.

It is called dual-stack.

One will have IPv4 NAT and IPv6 e2e. This is already the case for most
end-users who have received an IPv6 block from their provider or who
went to a tunnel broker to get a nice fat /48 IPv6, while they only got
a /32 IPv4 from their provider. This has actually been a huge incentive
for a lot of people to start using IPv6 and to start using it everywhere
they have hosts as this way they can reach all their hosts at home and
have full e2e connectivity between machines, thus allowing you to SSH in
to your local box. This is a, by now, 8 year old trick btw ;)

The big question of course is: what exact problem do you want to solve?

Stating "I want to connect from IPv4 to IPv6", can mean a lot of things,
is this HTTP? SMTP? or do you really want a generic solution?

As for the case where you have a limited number of public IPv4 addresses
and want to provide them to the clients, who will have IPv6 all the
time, there is a sweet little protocol called DSTM (See for more
http://www.dstm.info) which solves that problem. Of course a protocol
like AYIYA also allows a IPv4 over IPv6 tunnel and lastly we also still
have SOCKS and application-specific proxies (eg MX's and HTTP proxies).
Oh I forget of course our good old ones: L2TP, PPTP etc :)

There are a LOT of choices, probably too many. The following URL:
http://www.sixxs.net/faq/connectivity/?faq=comparison has a short list
of them, not all of them are on it of course. eg tinc/OpenVPN etc are
missing.

Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: mini-cores (was Re: ULA-C)

[Jeroen Massar]

Keith Moore wrote:
>> In my vision the /48s being given out as "PI" today can be used for the
>> ID portion, while every transit will give a "location" /48 to the site
>> that needs it. Over the DFZ the src/dst will be in DFZ/location style,
>> but when it arrives at the endsite it will be in PI mode again. NAT
>> (that evil thing) is useful and when you do it twice you actually still
>> have the same packet and have achieved a tunnel without the overhead of
>> it. The signaling of what to use is the tricky part though.
>>   
> I think that dual NAT can be used in a somewhat benign way.  If it's
> done by bilateral agreement between networks with globally unique
> prefixes, and the mappings at each end are symmetrical, it seems like
> it's basically equivalent to a tunnel with a kind of header compression
> and without the PMTU reduction issues.

Exactly what I meant. The 'bilateral agreement' is the unknown magic
pixie dust though which should be automated and is the biggest problem.
For the rest it is indeed just automated "tunnels".

> And if the addresses used at the host are unique, it gets rid of many
> of the problems caused by overlapping use of RFC 1918 addresses in IPv4.
> There's still some issues related to traceability of traffic over the
> network, but maybe those are manageable.

The source and destination address are globally unique. As such you know
where the traffic comes from as all these prefixes are correctly
registered in whois. This means that an end-site organization might have
5 /48's in whois: one they use for "ID", this can be a special block
like ULA, PI or just a block they get from one of their upstream ISPs,
and maybe 4 from their upstream ISPs. All would be in whois, pointing at
least to the ISP responsible and maybe even to the org that is using it.
As long as uRPF is correctly enabled nothing will go through the DMZ
which is not from the ISP that actually is supposed to send data sourced
from that prefix. Traceability thus becomes easier as traffic has to be
sourced from the ISP it has to come from.

As mentioned above "PI" blocks can be used for this. As such
organizations who can convince all ISPs in the DFZ that they are
important enough to have their own routing slot can cough up the dough
and be there, others will just have to do with this mechanism to get around.

Greets,
 Jeroen




signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: mini-cores (was Re: ULA-C)

[Jeroen Massar]

Paul Vixie wrote:
>> Without going into debate about consenting adults, and while I might
>> disagree with Paul in certain fine points, I'd suggest that we consider the
>> ULA-G proposal within the IETF and ask that Paul submit it as an I-D.  ULA-G
>> could have broad application if in fact we solve the multihoming problem
>> (IMHO) and I'd like to be the optimist and say that we can do that.
> 
> i'll need new coauthors.  i ain't signing up for this alone, and the authors
> of ULA-C only wrote it up so that we would all know what ideas had been
> abandoned, not as a way forward.

And in another mail wrote:
> i'm at the "ignore ietf now" stage with things like DNSSEC DLV, and
> it's going to come as no shock to me if SIXXS is at the "ignore ietf
> now" stage with ULA.

My view on the ULA story and for that matter any address space being
given out is much simpler and it has nothing to do with ignore, it has
to do with what is realistic. That "ULA registry" is just to demonstrate
that a very cost effective (aka 0.0EUR cost) way can be setup where
people can register their prefixes if it really is so important for them
to have that little bit more certainty that they are 100% unique instead
of the collision probability of 4.54*10^-05 even when having 10k
connections to other ULA sites. If IANA would want to run similar code I
am very happy to provide them with the details etc on how to do it,
though I am fairly sure they can easily do it themselves too.

Currently organizations need IPv6 address space. ARIN/APNIC/AfriNIC
allow them to get a nice /48, or larger if they can justify that. In
RIPE land you just become LIR and get a /32 along with it. This allows
them to deploy IPv6 today.

As for organizations wanting 'disconnected' address space, just go to
your RIR and get it. There is (except for AfriNIC) no requirement
anywhere to announce the space in the DFZ. If you don't want to go to an
RIR, go to an LIR who have a /32 and just ask them for a /48, and pay
them a 100 EUR or something for 'administrative fees' or whatever. That
is why LIRs exist. This is also what happens today with IPv4 address space.

IMHO The /48 "PI" thing is a good thing. Except that in my view of
things in a year or 10-20 they won't be floating in the DFZ any more.

The DFZ as we know it will be a real Tier system. Only the "Tier 1s and
Tier2s", the current organizations who get the /32's and up will be in
there. All the 'small' parties, thus the /40 - /48's will be using a
non-BGP method of connecting up to the Internet and thus won't
contribute to DFZ re-calculations.

Routing will become more 'geographic', the only thing you will need to
know is that "Organization X is a customer of transit Z and Y and they
prefer Z", you have a BGP route to transit Z and simply send your
packets there. When transit Z flaps around, then you only need 1 update,
not 10, which are their customers. Still you will have some state
which can be updated in near-real-time, where X will say "please send
packets destined to me preferably over Y" or "Transit W is now our
preferred transit, use them please".

In my vision the /48s being given out as "PI" today can be used for the
ID portion, while every transit will give a "location" /48 to the site
that needs it. Over the DFZ the src/dst will be in DFZ/location style,
but when it arrives at the endsite it will be in PI mode again. NAT
(that evil thing) is useful and when you do it twice you actually still
have the same packet and have achieved a tunnel without the overhead of
it. The signaling of what to use is the tricky part though.

See [EMAIL PROTECTED] for more of those discussions. Those folks are doing
good work.

It might indeed not be ready tomorrow, not next year, maybe not in the
next 10 years, but really current routing hardware will scale up to
that. Remember, only 900 IPv6 routes today and only 1517 prefixes have
really been allocated from the RIRs to the ISPs and I don't see another
200k popping out of nowhere anywhere soon. I could be very wrong of
course though :)


Who can be Tier1 or 2 will then be determined based on cash,
connectivity and weight; eg YouTube and Google for instance can do
pretty much they want, if they do www.google.com A 1.2.3.4, 1.0.0.0/8
will most likely quickly be theirs, just because otherwise you will have
your customers whining that you broke the Internet.

Greets,
 Jeroen




signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Representation of end-users at the IETF (Was: mini-cores (was Re: ULA-C)

[Jeroen Massar]

Stephane Bortzmeyer wrote:
> On Wed, Sep 19, 2007 at 12:50:44AM +,
>  Paul Vixie <[EMAIL PROTECTED]> wrote 
>  a message of 32 lines which said:
> 
>> in the IETF, the naysayers pretty much kick the consenting adults'
>> asses every day and twice on sunday.  and that's the real problem
>> here, i finally think.
> 
> Time to have a formal representation of end-users at the IETF?

What is defined as an 'end-user'?

You, me, the rest of the people, are all end-users IMHO.

That we might have quite a bit more knowledge on how things work and
that we might have some connections to people so that we can arrange
things, is nothing of an advantage over people who are not technically
inclined (or how do you put that nicely ;)

The point is that those people don't know better and as such they also
don't know what is possible and what they are missing.

Eg, if you tell somebody "oh but I have a /27 IPv4 and a /48 IPv6 at
home and I can access all my computers from the Internet wherever I am",
they will be going "and? why would I need that". The typical lay-man
end-user really couldn't care less, as long as their stuff works.

The only people really noticing problems with this are hobbyists and
most likely the gaming crowd trying to setup their own gameserver and
finding out that they are stuck behind this thing called "NAT".

P2P people, thus quite a large group of people using the Internet today,
have their tools to nice NAT tricks, thus these won't notice it.

And for the rest of the population the Internet consists of http:// and
https:// if they even recognize those two things, thus most likely only
"www" and "email", the latter likely only over a webinterface...

Which group do you want to 'involve' in the IETF and more-over, why?
Last time I checked the IETF was doing protocols and not user interfaces.

Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)

[Jeroen Massar]

Iljitsch van Beijnum wrote:
> On 18-sep-2007, at 17:50, Jeroen Massar wrote:
> 
>> I don't think ULA-C makes sense. We have a RIR system in place. These
>> RIRs are supposed to provide address space for people/organizations who
>> can justify a need for that address space.
> 
> That's like selling train tickets at the airport. Except for the
> fraction of a promille of all IP users that have their own portable
> address space, RIRs don't even talk to IP users who are _connected_ to
> the internet, let alone those who aren't! It just doesn't make sense to
> involve the RIRs here.

Then setup an LIR who gets a /32 from the RIR and let that RIR handle
all enduser conversions about this. That covers 65k /48's and thus
endsites, when they run out of space, well they have their whois, they
have their DNS delegations recorded, thus they can easily justify more
address space.

You can make that LIR a non-profit organization where every member pays
their share of the LIR fees that the organization has to pay yearly to
the RIR. Presto problem solved.

This is already what is in place today, you just need a friendly LIR.

But for some reason people don't want this, as the LIR can go belly up?
Odd eh.

Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)

[Jeroen Massar]

Tony Hain wrote:
[..]
> The people that are fighting having ULA-C are the same ones that don't want
> PI, and they are trying to force ULA-C == PI so they can turn that argument
> around and say 'we told you PI was a bad idea' when there is no way to
> filter out what would have been ULA-C. If you really believe there is going
> to be a routing system problem, then you absolutely have to support ULA-C
> because it is the only way to enforce keeping private space private.

I don't think ULA-C makes sense. We have a RIR system in place. These
RIRs are supposed to provide address space for people/organizations who
can justify a need for that address space. Clearly everybody does want
this address space to be unique and a lot of people for various reasons
(statistics, contact info, who it belongs to, which country, etc) want
to have at least an entry somewhere in a database that is publicly
available.

As at least ARIN, APNIC and AfriNIC have policies in place now, which
break the "global policy" that once existed, to provide /48's and upward
to individual sites. These sites might or might not be (completely)
connected to the Internet, there is no requirement anywhere to do so.

As such, there is already a perfect method of getting globally unique
and registered address space. As such, there is no need for ULA-C.

Which is good, as any address space that gets marked as 'special' will
be unusable because some people won't ever update filters, which is
their problem of course, but it will hurt others.

As history has shown that one day or another you will want to connect to
the Internet, having those blocks simply come from the RIRs is the
perfect way to do it.

As for the routing system problem, simple Economics will resolve that.
Either Transit Providers will stop accepting certain sized prefixes or
they will nicely start charging serious amounts of cash for the routing
slots they occupy.

In the mean time the great people working on the [EMAIL PROTECTED] list will 
find
a great method of avoiding that problem. We are at <900 prefixes in IPv6
and I really don't see it hitting 100k of them any time soon. When it
does, then we know that we might need to hurry up a bit. But as the IPv4
tables are already at 230k and are doing fine, I think we can have quite
a couple of quiet years before that will become a serious issue,
especially when ISPs can always filter if they want.

Checking the Looking Glass of GRH (http://www.sixxs.net/tools/grh/) it
shows also that quite some ISP's are already attempting de-aggregation
of their /32's and even the /20's they have received. Still the basic
premise is that they should only be announcing that single prefix and
most likely they only connect to you at one/two common points anyway and
you won't need their more specifics. As such you can filter on those
borders to avoid those few routes.

Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
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]

[Jeroen Massar]

Thomas Narten wrote:
> [..] There was overwhelming support for the PI to end sites proposal.
> Anyone who was at the ARIN meeting would have to take away two
> things: 1) some people were seriously worried about the long-term
> impact the policy would have on routing table size, and
> 2) there was still an overwhelming sense that PI for end
> sites was needed anyway, to support the requirements of larger
> enterprises. There were even some people who shared _both_ views.

My view on this is that the RIRs have, partially, done the right thing.
A RIR is for allocating internet resources in their region, as such them
providing /48's and up to their members is the right thing to do. That
they have names like "PI" and "PA" for it is IMHO wrong though, they all
should have the same name "Allocation" and the only difference should be
the size that they are allocated in, which is based on the justification
provided by the request that gets sent to them. This would then allow
anybody who can justify the need for address space to get it.

A /48 per 'site' is good, especially in the case of businesses, for
home-usage though, most very likely a /56 will be more than enough. As
such IMHO having 2 sizes, one business, one homeuser, would not be a bad
compromise, otherwise the really large ISP's, eg the ones having
multiple million customers, would need multiple million /48's and then
the address space consumption suddenly really goes really fast. Having
/56's there would slow that down a little bit. A /56 is still 256 /64's,
and I have a hard time believing that most people even on lists such as
ARIN ppml or the various IETF ones will ever configure that many subnets
 at home.

But now something the RIRs should not be doing though is meddling in
what ends up in BGP. Fortunately mostly they do stay out of there, but
unfortunately the allocation policies are based on them. Routing
(currently done mostly using BGP) is something that the ISPs will figure
out. In IPv4 >/24 is filtered out, for IPv6 at the moment it is >/48.
ISPs are running the show there and they can do what they want, and as
long as their customers can reach the sites they need to they will.
They also make up the bulk of the RIR crowd and thus can also set up
most of the policies there, nice monopoly settings are very possible
that way. Fortunately policies are more or less relaxed and as long as
you can come up with some solid business arguments one can get address
space quite easily, still the take up on IPv6 is not very high yet.

The problem with this, at least assumed, is that a certain point the
IPv4 + IPv6 routing tables will 'explode' into millions of routes and
apparently people don't want to upgrade their routers to handle these
over the coming years, which is somewhat understandable. The big
question here is, how quickly will we reach that huge number, and also
which hardware will fall over first; or otherwise said: should we really
be so worried about this. Looking again at those IPv6 takeup numbers,
should we really be worried about routing table explosion in the next
couple of years? IMHO not really, most likely current equipment will be
able to be used for the next couple of years.

Looking at http://www.sixxs.net/tools/grh/growth/ we have surpassed last
years number of allocations and one can also clearly see that ARIN
(blue) took off quite a bit allocation wise, mostly because of their
"PI" /48s.

Still, the total number of prefixes that have been allocated is only
~1600*, thus if every one of them would be announced only 1600 of them
would exist in the BGP tables, (unless folks deaggregate) could be me
but that is far off from the 200k that we have in BGP, or the 300k that
some have internally. Of course internal BGP for IPv6 can become large,
but that is why one should use a /40 per PoP or similar constructs to
nicely aggregate things up.

In the mean time though, there is great working being done on the
Routing And Addressing Mailing List
(https://www1.ietf.org/mailman/listinfo/ram) and some great ideas have
already been shown there. One should also not forget HIP of course and a
variety of other problem statements and solutions.

Greets,
 Jeroen

* = http://www.sixxs.net/tools/grh/dfp/



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: DNS as 1980s technology [was Re: The Internet 2.0 box Was: IPv6 addresses really are scarce after all]

[Jeroen Massar]

Keith Moore wrote:
[..]
> I believe I understand how to replace DNS with a better protocol while
> preserving the existing hierarchy and RRsets and DNSSEC, and allowing
> graceful transition from the old to the new.  However, I'm not sure that
> I have enough understanding of DNS's failings to engineer something that
> addresses all or most of them - I just know about the ones I've run
> into.  But I'd like to hear from other people who are interested in
> replacing DNS, maybe we could collaborate on a proposal that shows how
> DNS could be improved and how replacement of DNS is feasible.

Might I suggest that you first start doing what most sensible people
have been doing over the long long years of human existence:

 - define your problem
 - define what you want to solve
 - define for what you want to solve it

And then after that is all done, realize that the problem you have is
very difficult.

The IETF has a simple process for all of this: write a draft.
And the alternative process is: build running code.

But afaik you already know about this. Bickering about all this is fun
of course, but it doesn't help coming to a solution, especially as the
solution doesn't have a defined problem set and what it is supposed to
solve.

Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IPv6 addresses really are scarce after all

[Jeroen Massar]

Tony Li wrote:
>>
> 
>> When they do, they are violating the premises on which they received
>> their allocation. As such any ISP which is not willing to provide a /48*
>> to an end-user should get their IPv6 allocation revoked by the RIR.
> 
> 
> Could you please site chapter and verse?  Here's what I can find:
> 
> http://www.arin.net/policy/nrpm.html#six54
> 
> 6.5.4.1. Assignment address space size
> 
> End-users are assigned an end site assignment from their LIR or ISP. The
> exact size of the assignment is a local decision for the LIR or ISP to
> make, using a minimum value of a /64 (when only one subnet is
> anticipated for the end site) up to the normal maximum of /48, except in
> cases of extra large end sites where a larger assignment can be justified.

Thanks for quoting exactly the correct portion as that part exactly
explains what the ISP is supposed to do. Except that the boundary here
is worse than what is being proposed, the boundary in the above case is
/64 - /48. For instance /128 is not allowed to be assigned to an
end-user. They will have to provide at least a /64, but as not "exactly
one subnet is anticipated for the end site" they will have to provide
more than that single /64.

As the proposal currently on PPML has, it tries to standardize the size
of the prefix actually given away. In IETF talk the 'rule' has always
been /128 if only one IP, /64 for a single subnet, /48 for anything else
(see the architecture RFC's). Proposed now is to add a /56 for home-user
sites, and 2 other prefix sizes (which IMHO are a bit overdone).

>> ISPs should be charging based on *bandwidth usage* not on IP usage.
> 
> 
> Sorry, ISPs charge based on providing a *service*.  Yes, that includes
> bandwidth (and generally flat bandwidth, not usage) and also other
> components (DHCP, addressing, DNS, email, web hosting, spam filtering,
> etc).

Strange that many ISPs charge *specifically* for more IPv4 addresses.

But that is IPv4 addresses, I hope that the RIR's can make very clear to
the ISPs in question that they are getting a IPv6 /32 based on the mere
fact that they can then assign /48's to their endusers.

Someone mentioned the Comcast case, unfortunately for those users,
Comcast clearly only has the intention of using the /32 for provisioning
the CPE's, they won't be providing /48's from that block. If they where
going to do that, they really have to go back to ARIN and request
something in the vicinity of a /20, as that would actually cover the x
million customers they have.

Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IPv6 addresses really are scarce after all

[Jeroen Massar]

Tony Li wrote:
[..]

> Most MSOs would VERY much like to
> sell you a service with a fraction of an IPv4 address today, but they
> really haven't
> figured out how they could do so technically.  For v6, they will always
> sell a service
> with a minimal amount of address, regardless of ARIN policies.  If they
> could figure out how to make that a /128, they would.

When they do, they are violating the premises on which they received
their allocation. As such any ISP which is not willing to provide a /48*
to an end-user should get their IPv6 allocation revoked by the RIR.

Unfortunately it is for any RIR not very easy to check up on these
things. Though it would be great if the RIRs have an easy reporting
mechanism for these cases so that end users can report against ISPs
which are not willing to provide them with IP addresses.

ISPs should be charging based on *bandwidth usage* not on IP usage.
It is really strange that they do do that as they are paying their
transits based on traffic too, not on the amount of addresses.
Of course it is a great way to do business, but lousy for the enduser,
and it will only really cause the thing that IPv6 was supposed to avoid:
NAT or better said to be able to provide end-to-end connectivity.

Alas, as long as ISPs can get away with it, they will most likely do so.

Greets,
 Jeroen

* currently, which is why the /56 thing has come up again, which IMHO
might be a good idea as a /48 is an awful lot that I won't even use at
home, though a /48 for every end-site is fine by me as it currently is too.



signature.asc
Description: OpenPGP digital signature
___
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

[Jeroen Massar]

Brian E Carpenter wrote:
> 
>> 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.

going-nicely-ietf-offtopic:

google(WRT cheap EUR) returned me with:

http://www.dd-wrt.com/shop/catalog/product_reviews_info.php?products_id=28&reviews_id=21

Which is a "Buffalo WHR-G54S" for 49.99EUR. When buying them there you
get them preloaded with DD-WRT which does IPv6 (and even aiccu :) out of
the box.

Instead of there you can of course buy a lot of variants of the WRT type
of 'routers' in your local shop and make them into real routers by
upgrading them to OpenWRT/DD-WRT and a number of variants.
WRT's are accidentally also the cheapest managed router/switch/wifibox
as you can install SNMPd, SSH/telnet/webif etc etc ;)

Problemo solved and yes IMHO those are really nice boxes to have. There
are also a few of those boxes which can do DSL for you btw, all depends
on the config they come with.

Of course there are also a number of vendors who ship with IPv6 support
as a standard feature.

Greets,
 Jeroen

==
Oh and to 'prove' that they do IPv6:
 7  sheol.unfix.org (2001:7b8:20d:0:20f:66ff:fec8:5fd4)  16.9 ms  14.006
ms  14.308 ms

 7  gehenna.unfix.org (2001:7b8:20d:0:214:bfff:fe72:f83c)  18.911 ms
13.978 ms  15.3 ms

Yep, both still work fine and I haven't touched those for quite some
time now ;)



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: chicago IETF IPv6 connectivity

[Jeroen Massar]

Paul Hoffman wrote:
> At 2:36 PM +0900 7/1/07, Jun-ichiro itojun Hagino wrote:
>>  > > 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.
> 
> 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.

The thing to do before thinking of removing IPv4 connectivity is too
look at which applications are actually using IPv4.
NetFlow/sniffing etc can be used to determine these organization wide.

Most likely you will come down to at least:
 - HTTP -> for which one can use a HTTP Proxy which does v4+v6
 - SMTP -> for which one can use SMTP :) (does both v4+v6)
 - IMAP/POP -> let the app handle it

In the end though one needs to have a machine somewhere which does both
IPv4 and IPv6 and translates between them. But on the Application
Protocol level, not by changing bits like NAT-PT does.

I am not sure, but is there not a draft/rfc/paper which details
something like "Common application migration path from IPv4 to IPv6"?
It is now I guess all cluttered all over the place. Maybe a Wikipedia
article would be more appropriate, outlining which protocols can be
resolved in way X and/or Y. This also allows everything to be in a
central place which pointers to the programs that can do this too.

Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: chicago IETF IPv6 connectivity

[Jeroen Massar]

[bcc'd someone from Verilan who can most likely comment on this :) ]

Jun-ichiro itojun Hagino wrote:
>   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.


It seems that VeriLAN (http://www.verilan.com) is taking on the NOC role
again, they did, from what I understood, a great job in Prague*. A
search using their own search toy for "IPv6" didn't result in any hits
though and google doesn't seem to know about it either.


In the possible case that no IPv6 (native) connectivity can be arranged,
there is a SixXS PoP in Chicago, courtesy of OCCAID, this box is up and
running and can easily provide a fast stable tunnel + /48 to the site if
needed. Just yell in case help there is needed.

Greets,
 Jeroen

* = http://tools.ietf.org/group/iaoc/wiki/VeriLAN



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: 6bone space used still in the free (www.ietf.org over IPv6 broken) (Was: why same names, was Re: NANOG 40 agenda posted)

[Jeroen Massar]

The IPv6 connectivity problems, at least the ones that I and some
others encountered, where resolved yesterday.

Thanks to all the folks involved who made that happen!


Mike Leber wrote:
[..]
> Would you similarly disconnect a nonresponsive customer because they used
> a /30 from RFC1918 space on a point to point link with you?

That link should not have existed in the first place. Also RPF filters
would catch any packets being sourced from that block.

[..]
>> Of course, Neustar, who are hosting www.ietf.org, might also want to
>> look for a couple of extra transit providers who can provide them with
>> real connectivity to the rest of the world.
> 
> That won't renumber Bill Manning's links if that is the problem you are
> trying to fix.

Not much to fix when the person in question doesn't want to fix it.
That comment was more meant to point that Neustar should have multiple
upstreams.

[..]
> BTW, Jeroen does have a valid beef, [EMAIL PROTECTED] used to not be
> handled by our normal engineering staff.  It was somebody's part
> time side project. This has changed with the migration of our IPv6
> network into our core. Since IPv6 is available via all core routers
> for customers on the same links as their IPv4 connection, all
> Hurricane network engineers are now required to be able take care
> of issues with it.

That is great to hear, keep the good work coming!

Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [ipv6] 6bone space used still in the free (www.ietf.org over IPv6 broken) (Was: why same names, was Re: NANOG 40 agenda posted)

[Jeroen Massar]

Steve Powell wrote:
> Greetings.

Thanks for the quick response. That is always appreciated.
Some networks don't even take that decency to respond, and for the
record, those are the ones that the previous mail is targeted at, in
the hope that they at least maybe acknowledge that there is a problem
instead of letting everything go into /dev/null. Acknowledging a
problem is a first step, fixing it is of course the next and better one.

> I do not believe 6bone space has anything to do with it.

As I wrote in my message, it definitely has. 6bone space is correctly
dropped by various AS's and routers, as it is not supposed to be used
for almost a *YEAR*. As the ICMP "Packet Too Big" packets from routers
who change MTU also get dropped by that when the router is sending
this message from 6bone space, this definitely has effect.

Solution: Do not use 6bone space as you are supposed to.

> 3ffe:80a::/64 is still being used by  PAIX in Palo Alto.

It's an IX, that is L2, who cares what L3 IP's are used over it?
I would depeer those folks, as clearly they don't care about the state
of the network anyway. If they do care they will fix it up really soon
after you did that.

In a week (6/6/7) it was a year ago that you where supposed to stop
using it. If in that time you really could not arrange for a
renumbering of a transit session I seriously wonder what is wrong in
that scenario.

> In general, I had no problems reaching www.ietf.org from
> pretty much anywhere in our network. 

This is because you most likely have a lot of paths which are nicely
MTU 1500 all the way, or have something setting it to eg 1280 quite
quickly on both sides of the path.

> However, I have seen stranger stuff with IPv6.  If you could
> send me a traceroute and show me where its dieing, I can
> do some more poking around.

As traceroute uses relatively small ICMPv6 or UDP packets these come
through perfectly fine. The problem occur when you want to access as
website, eg http://www.ietf.org and the packets are larger than
actually fit through the link, thus causing pMTU discovery etc.
Even the TCP session setup works fine, but nothing else.

When traceroute fails it is 'easy' to pinpoint the problem when you
can traceroute from both sides of the pond.

If you want traceroutes from an array of networks, please see
http://www.sixxs.net/tools/traceroute/ which provides that
functionality from several ASNs.

As an additional side note, you could of course always offer the IETF
(nee Neustar) a transit service, even if it is only for your own
customers. This way you avoid the dependency on 2 other networks, the
one you connect with and use as a transit for your own network, is
notoriously known to not fix problems or even reply. But of course
their routing is "immeasurably superior"*. Note the point that you
can't measure it :)

Greets,
 Jeroen

* = http://www.he.net/colo_ipv6.html



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

6bone space used still in the free (www.ietf.org over IPv6 broken) (Was: why same names, was Re: NANOG 40 agenda posted)

[Jeroen Massar]

[let me whine again about this one more time... *sigh*]
[guilty parties in cc + public ml's so that every body sees again that
this is being sent to you so that you can't deny it... *sigh again*]

Iljitsch van Beijnum wrote:
> 
> On 30-mei-2007, at 13:23, Nathan Ward wrote:
> 
>>> I can't seem to reach www.ietf.org over IPv6 these days and I have to
>>> wait 10 seconds before I fall back to IPv4.
[..]

> I think what's going on is that packets from www.ietf.org don't make it
> back to my ISP. A ping6 or traceroute6 doesn't show any ICMP errors and
> TCP sessions don't connect so it's not a PMTUD problem. So it's an
> actual timeout.

I also just started noticing this, that is, that it does not work. And
there is a very simple explanation for this: 6bone space.

As a lot of people might recall, the 6bone was shutdown on 6/6/6.
Still there are folks who are definitely not running anything
operational or who care at all about the state of their network, if
they did they would not be using it now would they?

As this is what I found on the way from $US -> $IE

 7  2001:470:0:1f::2  112.131 ms  108.949 ms  108.316 ms
 8  2001:470:0:9::2  109.864 ms  112.767 ms  111.586 ms
 9  3ffe:80a::c  111.118 ms  86.010 ms  86.648 ms
10  2001:450:2001:1000:0:670:1708:1225  193.914 ms  194.640 ms  194.976 ms

And what do we see: 6bone space and still in use.

As a lot of places correctly filter it out, the PMTU's get dropped, as
they are supposed to be dropped.

The whois.6bone.net registry is fun of course:

inet6num: 3FFE:800::/24
netname:  ISI-LAP
descr:Harry Try IPv6
country:  CA

Fortunately it still also has:

ipv6-site:ISI-LAP
origin:   AS4554
descr:LAP-EXCHANGE
  Los Angeles
country:  US

Which matches what GRH has on list for it: Bill.

Now I have a very very very simple question:

Can you folks finally, a year after the 6bone was supposed to be
completely gone, renumber from out that 6bone address space that you
are not supposed to use anymore?

That most likely will resolve the issues that a lot of people are
seeing. Or should there be another 6/6/7 date which states that
de-peering networks which are still announcing/forwarding 6bone space
should become into effect?

Of course, Neustar, who are hosting www.ietf.org, might also want to
look for a couple of extra transit providers who can provide them with
real connectivity to the rest of the world.

Thank you, I sincerely hope that this matter will finally be resolved.

Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Putting IPR on IPFIX while the target of IPFIX is to in effect open NetFlow (Was: [IPFIX] Implementation Guidelines // SCTP)

[Jeroen Massar]

[..]
Benoit Claise <[EMAIL PROTECTED]> wrote:
>  What you're proposing is something that Cisco has been thinking about for 
> more than 6 months now.
>  Actually we filled in a patent on that one. Because you proposed the idea, 
> we worked on the creation of a new draft
>  
> http://www.ietf.org/internet-drafts/draft-claise-ipfix-export-per-sctp-stream-00.txt:
>  
> 
>  fully explaining the idea
>  We also posted an IPR: see https://datatracker.ietf.org/public/ipr_list.cgi: 
>  . 
>  The title of the IPR disclosure is "Cisco's Statement about IPR claimed in 
> draft-claise-ipfix-export-per-sctp-stream-00.txt."
>  Alternatively, directly look up 
> http://www1.ietf.org/ietf/IPR/cisco-ipr-draft-claise-ipfix-export-per-sctp-stream-00.txt:
>  
> 
>  

(The above long formatted lines are not mine, 72 is a nice limit FYI)

Sorry to be blunt, but what exactly is the point again of 'opening up
NetFlow' if there is going to be IPR stuff being smacked upon IPFIX and
thus encumbering it?

And no the "we don't sue when you don't sue" sillyness is not 'open'.

If there is IPR on this part of IPFIX then it MUST never become part of
the standard of IPFIX that is to be the IETF version of NetFlow.

The "Disclosure"
http://www1.ietf.org/ietf/IPR/cisco-ipr-draft-claise-ipfix-export-per-sctp-stream-00.txt
doesn't contain *ANY* details on what exactly is IPR'd and what not. So
do we just have to assume that everything in that draft is encumbered?

I also have to note that the existing IPFIX capable collectors actually
can't care so much about what exactly gets delivered and how and in
which stream exactly the IPFIX packets are being sent, I am very sure
that the collectors that already exist are automatically prior art to
what is described in the draft document, therefor nullifying at least
half of the draft.


I am sincerely wondering _why_ Cisco is first going the long route of
trying to get an IETF, and thus widely open accepted, standard form of
NetFlow, thus making all kinds of vendors, who are still reluctant to
use NetFlow because of IPR nonsense, happy and then suddenly, after a
long time of getting people to accept it as a standard means, still yet
again go the IPR route to go back to square zero: no vendor will accept
IPFIX, and there will be various different kinds of "NetFlow" for doing
traffic, and other kinds of, metering.

Please, please, please, come up with something which actually is
original, get a patent for that and make your lawyers happy sueing each
other over those things. Don't go back to encumber something that is
actually starting to get adopted by a lot of vendors.


Greets,
 Jeroen

 (before anybody screams murder, of course like anything IETFish
  should be, this is my private & personal opinion bla bla...)




signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: www.ietf.org over IPv6

[Jeroen Massar]

Christian Huitema wrote:
> I tested ping, trace route and browsing over Teredo... and it work!

But that is more luck than anything else as the upstream 'transit' for
Neustar is missing 78 prefixes.

See http://www.sixxs.net/tools/grh/dfp/all/?missing=30071 for more
details of folks who can't reach the IETF website because of that.

Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Mail delivery problems

[Jeroen Massar]

Markku Savela wrote:
> I recently got notice from IETF mailing lists that my mail has been
> bouncing. The notice didn't have any examples of the bounces

Those bounces are delivery problems, see below why.

> so I couldn't get any clue what is wrong. However, now I got a bounce
> notice from bugtrag.. and it had this note
[..]

> Apparently "networksolutions" for some reason occasionally resolves
> "burp.tkv.asdf.org" into "resalehost.networksolutions.com".

Ever though about the place where bugtraq is hosted?
Also note that the IETF has nothing to do with that.


> Isn't this behaviour totally antisocial from networksolutions and how
> can it be stopped?

Antisocial is accusing organizations. Do a dig and find out:

org.172800  IN  NS  TLD3.ULTRADNS.org.
org.172800  IN  NS  TLD4.ULTRADNS.org.
org.172800  IN  NS  TLD5.ULTRADNS.INFO.
org.172800  IN  NS  TLD6.ULTRADNS.CO.UK.
org.172800  IN  NS  TLD1.ULTRADNS.NET.
org.172800  IN  NS  TLD2.ULTRADNS.NET.
;; Received 349 bytes from 192.112.36.4#53(g.root-servers.net) in 126 ms

asdf.org.   86400   IN  NS  gw1.solid.fi.
asdf.org.   86400   IN  NS  gw.solid.fi.
;; Received 78 bytes from 199.7.66.1#53(TLD3.ULTRADNS.org) in 102 ms

tkv.asdf.org.   1800IN  NS  ns.tkv.asdf.org.
;; Received 68 bytes from 193.65.201.11#53(gw1.solid.fi) in 50 ms

Now ask gw1.solid.fi where the NS is, eek a NS -> CNAME, that violates
some RFC's:

$ dig @gw1.solid.fi ns.tkv.asdf.org.

;; ANSWER SECTION:
ns.tkv.asdf.org.86400   IN  CNAME   tkvnic.tkv.asdf.org.
tkvnic.tkv.asdf.org.48291   IN  A   212.16.100.33

And that host is not alive. So the MX can't be resolved, nor the A
record of "tkv.asdf.org" and as such mail will bounce.

Conclusion: Fix your mail setup.

Instead of accusing other people of things they don't do.

Greets,
 Jeroen




signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Network update

[Jeroen Massar]

Morgan Sackett wrote:
> All,
> 
> Some of you have noticed trouble connecting to certain sites.  This was
> an issue caused this morning by an attempt to improve reachability to
> R&E networks that are not multi-homed with a commodity link.  Our
> attempts at implementing the improvements didn't work.  Routing policies
> have been rolled back to the previous configuration and connectivity to
> all commodity Internet sites have been restored.
> 
> We would have done this earlier in the weekend, but due to cultural
> differences we needed for upstream network staff to become available. 
> Network operations will continue to find a solution throughout the day
> in a way that will not impact the network.  If we feel that we have a
> workable solution we will attempt to implement in the early hours before
> the meeting tomorrow morning.

Silly question maybe, but exactly WHICH network are you exactly talking
about?

Assuming that it is IETF related, is it the network(s) where the various
servers (www1,2,3) are hosted (which are run by NeuStar) or is it the
Meeting network, or is it some other network?

Note, that you send a message with only 'network update' to the generic
world-wide ietf@ietf.org list. Some people are not where you are.

Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Game theory and IPv4 to IPv6

[Jeroen Massar]

Hallam-Baker, Phillip wrote:
> The problem is that until IPv6 has critical mass it is much better to be on 
> IPv4 than IPv6. 

Yes, because of latency, No because of NAT's.

> If there are any grad students reading the list take a look at the game 
> theory literature
> and apply it to the transition. Assume that it's a rat-choice world
and that each actor
> follows their best interest.

[ postgrad hat on ;) ]

There is a reason why companies like Demonware
(http://www.demonware.net/) exit, they exist solely to provide for a
cleanup of the IPv4 mess with NAT's by providing a stable stack that
allows them to get around most NAT issues by using mechanisms like STUN.

Note that MS has given a very lucrative way of solving this problem by
providing Teredo support; games and other programs simply use IPv6, all
the NAT issues get solved automagically by Teredo.

> There are certain costs associated with the various transitions.

Latency being the number one problem. Every millisecond extra causes
annoyance to users. Unfortunately due to the state of deployment of
Teredo relays and other similar techniques these are not usable (yet).

The quake approach: client<->server works though. P2P is out of the
question in many of those cases though.

> The benefit of being in the IPv4 or IPv6 network is proportional
> to the size of the networks.
> 
> I don't have time to run full simulation runs but my preliminary
> trials suggest that IPv6 is not relevant to the IPv4 exhaustion issue.

IPv4 will run out either way. IPv6 won't slow it down for a even a day.
Most, if not all, people using IPv6 also have IPv4 connectivity. IPv6
connectivity in general is non-NATted, while IPv4 is behind a NAT. Want
to connect to that box behind the NAT? Just use IPv6 and problem solved.
Some people tend to just throw around VPN's to those places though.

> The reason is that the participants are all going to cluster into
> IPv4/IPv6 or IPv4-NAT/IPv6, there is no incentive I can see to transition
> to the pure IPv6 state and release the IPv4 addresses.

The whole idea of transition is dual-stack. Some people will be on IPv4,
others on IPv6. Servers and gateways (SMTP style) will connect them.

For instance if you have a IPv6 enabled Quake server (thanks Viagenie)
then IPv4 players can also connect to it.

> Unless you assume that there is a very considerable value to IPv4 over
> IPv4-NAT all that happens during address exhaustion is that larger and
> larger proportions of the net disappear behind NATs. In effect you end
> up with the two speed Internet we want to avoid.

No, there is no considerable value of IPv4 over IPv6. There is a
considerable value of IPv4 over IPv4 NAT though due this the simple
concept called End-To-End, which with IPv6 gets restored so that hosts
at least get their own IP address again, avoiding all the rattraps
introduced by NAT's. Then again, firewalls can block those people off
also again, but that is then the network policy, not because they can't
at all do it. (Don't play games at work folks ;)

> Rather than fight the dynamics of a market with a billion participants
> I believe that we should embrace them and remember that taking IPv4 to
> end of life is not exactly an unacceptable outcome. The key is to channel
> people into IPv4-NAT/IPv6 rather than IPv4-NAT.

It also depends on game companies. They should make their games IPv6
compliant so that they at least support it. I am explicitly not saying
that they should do IPv6 per default as that will hurt performance in
all the cases where quality IPv6 connectivity is unavailable. A toggle
to enable it though would be a great step forward. Servers supporting it
on the public Internet will then be a second step.

> The way that I would go about this is to introduce a gold standard for
> next generation gateways that provide other features that the consumer
> is likely to consider desirable. Like being maintenance free, working
> without the complaints and setup time that current devices require.

Greets,
 Jeroen
 (hoping that Enemy Territory - Quake Wars supports IPv6...)



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: www.ietf.org unresponsive over IPv6?

[Jeroen Massar]

Tim Chown wrote:

On Fri, Sep 01, 2006 at 01:25:19PM +0200, Jeroen Massar wrote:

Tim Chown wrote:

[..]


[EMAIL PROTECTED]:~$ tracepath6 www.ietf.org
 1?: [LOCALHOST]  pmtu 1480


This 1480 is actually from the pmtu cache, when it expires, or I flush 
it manually, it gives:


 1?: [LOCALHOST]  pmtu 1500
 1:  2001:7b8:5:10:74::1   33.631ms
 2:  i49.ge-0-1-0.jun1.kelvin.ipv6.network.bit.nl asymm  3  35.484ms
 3:  jun1.telecity.ipv6.network.bit.nlasymm  4  34.532ms
 4:  zpr2.amt.cw.net  asymm  5  36.527ms
 5:  so-5-2-0-dcr1.amd.cw.net asymm  6  36.572ms
 6:  as0-dcr2.amd.cw.net  asymm  7  36.553ms
 7:  so-4-0-0-dcr1.tsd.cw.net asymm  8  42.392ms
 8:  so-1-0-0-zcr1.lnt.cw.net asymm  9  44.520ms
 9:  2001:7f8:4::31f9:1   asymm  8 137.479ms
10:  2001:7f8:4::31f9:1   asymm  8 137.774ms pmtu 1480
10:  v3323-mpd.cr1.ewr1.us.occaid.net asymm  7 142.540ms
11:  ge-0-1-0.cr1.iad1.us.occaid.net  asymm  7 147.413ms
12:  unknown.occaid.net   asymm  8 148.820ms

Long live native IPv6 over DSL :)

Hop 9/10 are a bit weird though, most likely a TTL bug.


And then no responses, thus most likely filtered for this kind of trace.


So I'm on RedHat, have tracepath6 installed (not used before, thanks for
the pointer :) and I see in comparison:


Yes, tracepath6 is a *very* useful tool, but as I demonstrated myself 
above, it doesn't flush the cache, thus be careful there.
Tracepath6 uses some Linux specific tricks for getting certain 
information, which is why (afaik) it is not available on eg BSD's.



$ /usr/sbin/tracepath6 www.ietf.org
 1?: [LOCALHOST]  pmtu 1500
 1:  2001:630:d0:f102::21.191ms 
 2:  zaphod.6core.ecs.soton.ac.uk   1. 93ms 
 3:  ford.6core.ecs.soton.ac.uk 1.915ms 
 4:  2001:630:c1:100::1 2. 66ms 
 5:  2001:630:c1:10::1  2.353ms 
 6:  no reply

 7:  no reply
 8:  no reply
 9:  po9-0.cosh-scr.ja.net  8.440ms 


How sure are you these have a MTU of 1500? Best way to test is to do 
ping6's in the form of "ping6 -M do -s 1500 " and decrementing 
per 10 or 20 till it doesn't respond anymore and then increasing again.



19:  52.ge0-0.cr2.lhr1.uk.occaid.net  asymm 18  16. 63ms pmtu 1480


Though from this hop you should have 1480 which is at least the correct 
value for the rest of the route. 1280 should always work of course, but 
then the link has to indicate this too. The problem with debugging this 
is that you can't do a traceroute6 from both sides, there might be an 
async route back to your network which might be causing this issue.
Assuming that http://www.sixxs.net/tools/traceroute/ indicates that the 
three SixXS PoPs inside the OCCAID network, over which the IETF seems to 
get connectivity at least pick Verio->NTT as an outbound route towards 
your network.


Maybe a traceroute6 interface on http://noc.ietf.org/ could help debug 
these issues easier? I'll send the secretariat a separate message about 
that, also that they might want to ask Neustar join up with GRH 
(http://www.sixxs.net/tools/grh/) to make debugging easier as then we at 
least have ASpaths also which might help here.


[..]

Hmm, 1500 vs 1480.


Check your neighbor cache after the traceroute/path or even a full TCP 
connect has completed, you should have an entry similar to:


[EMAIL PROTECTED]:~$ ip -6 ro sho cache
2001:503:c779:b::d1ad:35b4 via 2001:7b8:5:10:74::1 dev eth1  metric 0
cache  expires 429sec mtu 1480 advmss 1440 hoplimit 4294967295

The 1480 is noted here, check that that is the case.


$ /usr/sbin/traceroute6 www.ietf.org
traceroute to www.ietf.org (2001:503:c779:b::d1ad:35b4) from 
2001:630:d0:f102:230:48ff:fe23:58df, 30 hops max, 16 byte packets
 1  2001:630:d0:f102::2 (2001:630:d0:f102::2)  1.883 ms  2.719 ms  4.513 ms
 2  zaphod.6core.ecs.soton.ac.uk (2001:630:d0:f001::1)  4.462 ms  2.485 ms  
2.886 ms
 3  ford.6core.ecs.soton.ac.uk (2001:630:d0:f000::1)  3.444 ms  0.648 ms  0.64 
ms
 4  2001:630:c1:100::1 (2001:630:c1:100::1)  1.235 ms  1.104 ms  0.962 ms
 5  2001:630:c1:10::1 (2001:630:c1:10::1)  1.21 ms  1.138 ms  1.186 ms
 6  * * *
 7  2001:630:c1::1 (2001:630:c1::1)  4.982 ms  2.891 ms  2.138 ms
 8  2001:630:c1::1 (2001:630:c1::1)  2.562 ms  2.189 ms  2.662 ms


These hops are weird IMHO, 7 & 8 should not be duplicate, prolly a Cisco 
IOS located there as there are some releases which didn't decrement the 
TTL when going from Ethernet->ATM or some other weird interface changeover.


[EMAIL PROTECTED]:~$ tracepath6 2001:630:d0:f102::2
 1?: [LOCALHOST]  pmtu 1500
 1:  2001:7b8:5:10:74::1   33.450ms
 2:  i49.ge-0-1-0.jun1.kelvin.ip

Re: www.ietf.org unresponsive over IPv6?

[Jeroen Massar]

Tim Chown wrote:

Hi,

While I can establish a fast telnet session to port 80:

$ telnet www.ietf.org 80
Trying 2001:503:c779:b::d1ad:35b4...
Connected to www.ietf.org.
Escape character is '^]'.

Attempting to browse via MSIE leads to timeouts.

Connecting explictly to http://209.173.53.180 to assure IPv4 works fine.


"telnet -4 www.ietf.org" should do that trick too, but notez bien:

www.ietf.orgA   209.173.53.180
www.ietf.orgA   209.173.57.180
www.ietf.org2001:503:C779:B:0:0:D1AD:35B4

We don't know if those are 3 different boxes, or simply 1 box with 
multiple links/addresses. As IPv4 traceroutes die off one can't tell 
what really is happening behind AT&T (at least from my perspective).
Looking at routeviews it seems that both IPv4 /24's have somewhat 
different ASPaths, going over different upstreams.



Perhaps some Apache issue or PMTU issue?


Most likely PMTU.


Anyone else experiencing this?


Works from boxes behind my home DSL line (purgatory.unfix.org) and from 
my work box, which is behind SWITCH (2001:620::/32). Tested with telnet, 
 MSIE and firefox. See below for traces from the DSL.


Can you try tracepath6, which is available afaik only on Linux boxes 
though, to show the MTU path? (iputils-tracepath is the deb package)


Greets,
 Jeroen

--
[EMAIL PROTECTED]:~$ tracepath6 www.ietf.org
 1?: [LOCALHOST]  pmtu 1480
 1:  2001:7b8:5:10:74::1   32.572ms
 2:  i49.ge-0-1-0.jun1.kelvin.ipv6.network.bit.nl asymm  3  33.623ms
 3:  jun1.telecity.ipv6.network.bit.nlasymm  4  34.609ms
 4:  zpr2.amt.cw.net  asymm  5  35.522ms
 5:  so-5-2-0-dcr1.amd.cw.net asymm  6  34.597ms
 6:  as0-dcr2.amd.cw.net  asymm  7  35.611ms
 7:  so-4-0-0-dcr1.tsd.cw.net asymm  8  41.612ms
 8:  so-1-0-0-zcr1.lnt.cw.net asymm  9  41.507ms
 9:  2001:7f8:4::31f9:1   asymm  8 137.537ms
10:  v3323-mpd.cr1.ewr1.us.occaid.net asymm  7 141.670ms
11:  ge-0-1-0.cr1.iad1.us.occaid.net  asymm  7 146.538ms
12:  unknown.occaid.net   asymm  8 152.466ms

And then no responses, thus most likely filtered for this kind of trace.

But traceroute6 works fully:

traceroute to www.ietf.org (2001:503:c779:b::d1ad:35b4) from 
2001:7b8:20d:0:290:27ff:fe24:c19f, 30 hops max, 24 byte packets
 1  2001:7b8:5:10:74::1 (2001:7b8:5:10:74::1)  13.874 ms  9.645 ms 
10.963 ms
 2  i49.ge-0-1-0.jun1.kelvin.ipv6.network.bit.nl 
(2001:7b8:3:31:290:6900:31c6:d81f)  9.943 ms  15.581 ms  14.958 ms
 3  jun1.telecity.ipv6.network.bit.nl (2001:7b8::290:6900:1c6:7c1f) 
16.953 ms *  10.6 ms
 4  zpr2.amt.cw.net (2001:7f8:1::a500:1273:1)  10.972 ms  11.501 ms 
10.99 ms
 5  so-5-2-0-dcr1.amd.cw.net (2001:5000:0:12::1)  11.987 ms  11.614 ms 
 11.986 ms
 6  as0-dcr2.amd.cw.net (2001:5000:0:11::2)  11.989 ms  11.569 ms 
10.989 ms
 7  so-4-0-0-dcr1.tsd.cw.net (2001:5000:0:20::2)  17.988 ms  17.589 ms 
 17.989 ms
 8  so-1-0-0-zcr1.lnt.cw.net (2001:5000:0:61::2)  21.988 ms  17.505 ms 
 17.988 ms
 9  2001:7f8:4::31f9:1 (2001:7f8:4::31f9:1)  112.99 ms  112.727 ms 
113.984 ms
10  v3323-mpd.cr1.ewr1.us.occaid.net (2001:4830:fe:1010::2)  111.988 ms 
 112.501 ms  112.991 ms
11  ge-0-1-0.cr1.iad1.us.occaid.net (2001:4830:ff:f150::2)  117.969 ms 
118.47 ms  118.997 ms
12  unknown.occaid.net (2001:4830:e6:d::2)  121.972 ms  122.48 ms 
121.978 ms
13  stsc350a-eth3c0.va.neustar.com (2610:a0:c779::fe)  124.004 ms 
124.44 ms  124.975 ms
14  2001:503:c779:b::d1ad:35b4 (2001:503:c779:b::d1ad:35b4)  123.992 ms 
 122.722 ms  124.007 ms


Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF lists as RSS?

[Jeroen Massar]

On Thu, 2006-04-27 at 09:05 +0200, Stephane Bortzmeyer wrote:
> On Wed, Apr 26, 2006 at 05:01:50PM -0700,
>  David W. Hankins <[EMAIL PROTECTED]> wrote 
>  a message of 56 lines which said:
> 
> > It would certainly be strange, at the IETF, for anyone to suggest
> > using a technology that is known to be pervasively deployed and
> > functional.
> 
> Atom (RFC 4287) and the various RSS (which one to use, by the way?)
> are deployed and are functional.

For RSS the one that Feed Validator likes, for draft/RFC annnounces,
check: http://community.unfix.org/feeds/

No per-user-subscribe yet though, as I unfortunatly broke my right
shoulder and that will take some time to mend and typing with one hand
is not very speedy ;(

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]

[Jeroen Massar]

[very nice cross posting going on here ;) ]

On Sun, 2006-04-16 at 12:10 -0400, Patrick W. Gilmore wrote:
[...
large snip about trying to bash shim6 which is not finalized
yet, thus how can you bash it ?
Note: extra sarcasm included in this post. Eat the eggs with salt.
...]

> Oh, and one thing I should have said last time: Technical arguments  
> are important, but they are only part of the decision process.

In other words: "You are right with your arguments, but I just threw
your args away as they are futile based on the comparison of money
earned this way or the other."...

> People (like me) have explained that the Internet is a business, and  
> in addition to being .. technically unsavory to many people, shim6 is  
> simply not viable in a business setting.

And as you will only care for your business for the coming 10 or maybe
20 years you really can't care what happens to the internet afterward.

The idea of IPv6 is (still not was) to have it around for quite some
time longer than the lifespan of IPv4. Fortunately, the PI thing is far
from the end of the world and will only help catch on, see below.

Of course any vendor will love the idea of having to do another IP
version of course, bring in the cash ;)

> Neither backbone operators  
> (vendors) nor end users (customers) are warming to the idea.  Just  
> the opposite.  (At least in general, the one-in-a-million end user  
> with DSL and cable who likes the idea 'cause he can't figure out how  
> to spell "B-G-P" or doesn't want to pay for it is irrelevant.)

Irrelevant for you as they don't give you money. Indeed, you only look
at your own business interrest (and who can blame you for that ;)
(Once though the internet was there for the masses and not only for the
ones with cash)

> So how do you get a technology widely accepted when the majority of  
> people involved do not think it is the best technical solution?  When  
> the majority of vendors supposed to implement it will not do so for  
> technical -and- business reasons.

There is for you indeed a business reason to not like it: the end-site
won't have any reason to stick to the upstream. Which is indeed a bad
business for many of the 'vendors' you mean.

As Eliot Lear also said very clearly: Thanks for lining the vendors and
all the stockholders pockets ;)

That is in the long run, most likely in the coming 10-20 years the IPv6
routing tables will not have 'exploded' yet, but the folks selling
equipment and having stocks of those venders after that most likely will
have a nice retirement fund. Thanks to you!


Nevertheless, the PI thing is really *not* a bad thing, as it can be
used as an identifier for shim6, which is actually perfect. It just
saves on having to do a complete policy process for getting address
space for this type of usage. But thanks to this, this won't be needed
and thus in the end anybody who can get PI can use a shim6-alike
solution and won't have any problem with the upstream that actually
wanted to lock them in by letting them pay loads for an entry in the BGP
tables.

Thus people voting for PI, thanks for helping shim6 or another solution
in that space, progress a lot :)


And finally on a much brighter note, especially for the shim6 folks:
I know of quite a number of endsites that don't want to use BGP, the
don't care about an entry in the routing tables, but do want to be
multihomed in an easy way and also want to have 1 unique address space
on their local network, but do want to use different upstreams. Shim6
will be perfect for this and thanks to the PI space their is the perfect
identifier.

Greets,
 Jeroen

  (being sarcastic, I guess the amounts of chocolate did it, but hey,
   I have a great excuse being only 7 mins away from the Lindt&Sprungli
   factory outlet, happy easter! ;)



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]

[Jeroen Massar]

On Sat, 2006-04-15 at 19:49 +0200, Iljitsch van Beijnum wrote:
> On 15-apr-2006, at 18:54, Christian Huitema wrote:
[..]
> It's really too bad, because we almost have what we need to pull this  
> whole scalability thing off in IPv6: stateless autoconfig, DHCPv6  
> prefix delegation, dynamic DNS updates, MIPv6, shim6. The only thing  
> missing is some finishing touches (ok, more than "some" for shim6,  
> but it is moving along) and for firewall vendors to jump on the  
> bandwagon and move away from hardcoded IP address based filters.

Iljitsch, please stop seeing the 'bad' side about this. If people really
are going to stick millions of routes into BGP they will hang themselves
anyway as they will be the ones having to buy the fat new shiny routers
for lots of cash, which can then be provided by all those nice
consultants and vendors who thrive on things like that. The funniest
thing is that due to the open process we can always point fingers *evil
grin*.

But I don't see a problem at all as I mentioned before.

The bright point is that the PI space provides something really good: 
 - Folks will have their Globally Unique address space.
On which they can rely that it will be theirs for a long time.
Which means that it can be used as a perfect identifier for setups like
shim6.

The "PI space" will then reside in their own network, while when the
packet goes over the internet, at the moment it crossed their border,
the packet gets translated to the address space of the upstream
provider, when arriving at the other side it gets translated back into
the "PI space".

This will make them happy and keep the routing table very small. Just
like the original idea of doing IPv6 PA was :)

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]

[Jeroen Massar]

On Fri, 2006-04-14 at 14:17 -0400, Noel Chiappa wrote:
> > From: Kevin Loch <[EMAIL PROTECTED]>
> 
> > Nobody in that room would have supported a policy they actually
> > believed would blow up the Internet.
> 
> Who was in the room, BTW? How many of those 60 were from ISP's?
> 
> Also, does that group have any commitments from ISP's (particularly the
> large global backbones) to carry these PI addresses? (I assume the group is
> expecting that PI addresses will be supported by the routing, not by some
> as-yet-undefined other mechanism.)

I guess actually that the larger ISP's are not too happy about "PI
space" in general, as with the Aggregate system they can nicely lock-in
customers.

As for "global backbones", check GRH (http://www.sixxs.net/tools/grh/)
and look at the amount of /48's and up seen in the routing tables and
which transits are providing these in BGP today. Most, if not all, do
this thus this will pose no problem whatsoever.

Let's see how it all will take of, when GRH shows a large increase in
new allocations we'll notice quickly if this is a success or not.

We'll max out the 16-bit ASN space first anyhow ;)


In the very very very long run, your undefined mech, we might end up
using these PI /48's for 'identifiers', using the upstream's /48 as the
locator space. No renumbering will thus be required, only some border
changes, and the tricky bit: a signaling protocol for notifying the
other end who we are so they can map it back to the PI /48. IHMO that
will become a real solution for many problems. Announcing multiple
prefixes and using source-address selection for instance is far from
pretty.

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Copyright status of early RFCs

[Jeroen Massar]

On Mon, 2006-04-10 at 07:28 -0700, Harald Alvestrand wrote:
> [EMAIL PROTECTED] wrote:
> >  not being the RFC editor, the IAB (or member thereof), or even the
> >  (as yet undefinable) IETF, I am not sure I am qualified to render
> >  a value judgement here.  That said, I am in posession of two bound
> >  volumes of the collected RFC series as of the date of publication of
> >  said volumes (modulo delays from the time the collection(s) were assembled
> >  and the time they were published).  One is circa 1995 and the other is
> >  circa 1997  ...  and I know of at least one CD containing the RFC archives
> >  that has been sold.
> >  The rules by which the IAB/IESG manage the IETF process have changed 
> >  dramatically in the past four years... so what was once possible/encouraged
> >  seems now to be treated as suspect or illegal beahviour.  Who knows 
> >  if the ISOC/IAB/IESG folks are attempting to claim copywrite on old RFCs 
> > (which
> >  used to claim "Distribution Unlimited")...
> I think it's much more a question of "we won't pay your lawyer's bills 
> if someone sues you over this" than a desire to exert any form of control.
> 
> I think all the IAB, IESG, IETF trust etcetera WISH for all RFCs to be 
> freely copyable in their entirety.

The 'entirety' is the key word here, as the cd's and prints Bill mention
contain the unmodified complete RFC's. That is, the versions I read
where contained complete unmodified RFC's and I expect them to be that
way too.

I have to note that I have a good number of books, specifically IPv6
ones, which contain excerpts of varous RFC's, even the newest ones.

It's indeed a 'who is going to pay for the lawyer riddle' in most of
these IPR/Copyright things ;(

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Stupid NAT tricks and how to stop them.

[Jeroen Massar]

On Tue, 2006-03-28 at 08:00 -0800, Hallam-Baker, Phillip wrote:
> > From: Kurt Erik Lindqvist [mailto:[EMAIL PROTECTED] 
> 
> > > NAT is a dead end.  If the Internet does not develop a way 
> > to obsolete 
> > > NAT, the Internet will die.  It will gradually be replaced 
> > by networks 
> > > that are more-or-less IP based but which only run a small number of 
> > > applications, poorly, and expensively.
> > 
> > 
> > ...or you will see an overlay network build on top of 
> > NAT+IPv4 that abstracts the shortcomings away - aka what the 
> > peer to peer networks are doing. End-to-end addressing...
> 
> Precisely. Just what is this fetish about keeping the IP address the same as
> the packet travels?

It certainly doesn't have to be. As long as there is one global
identifier which is the same on the other side. A double NAT (thus
making sure the packet is 100% identical on the sending and receiving
side) with a signalling protocol in between is the solution for this.
And there is something already being worked on which does that: shim6.

> If there is a way for the host to determine that it is behind a NAT and to
> request external registration of necessary ports the whole process can be
> made completely transparent to the hosts at each end.

You are thinking of UPNP (See http://www.upnp.org or read for instance
http://www.microsoft.com/windowsxp/using/setup/expert/crawford_02july22.mspx). 
Which is already support by Windows for some time and many "NAT boxes" (ohno I 
should say 'router' or 'firewall' according to them) vendors also nicely 
implement it. But it is a kludge and a heavy one as all the applications using 
it also have to support it and it is not always available and there are not too 
many applications supporting it, let alone protocols. Next to that, when the 
well known port on the outside IP is taken it won't work. Just like when there 
are multiple levels of NAT, or there are no rights to control the UPNP process 
at all.

IPv6 thus gives the advantage over UPNP that:
 - it is clear and simple to all the applications who they are
   talking to based on the source/destination IPv6 address
 - same ideas as IPv4 and no kludges
 - firewalling can remain the normal firewalling
 - multiple tools can use the wellknown ports as there are multiple IP's
 - etc...

Other thing you might want to look at is Teredo (RFC4380), which
basically implements an p2p overlay network on top of IPv4, but using
IPv6 for addressing. (Funny eh that both Teredo and UPNP come out of the
MS stables, guess what these guys wanted to solve...)

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Stupid NAT tricks and how to stop them.

[Jeroen Massar]

[cc trimmed]

On Tue, 2006-03-28 at 01:54 -0800, Michel Py wrote:

> > People will still want to do NAT on IPv6.
> 
> Yes, and since site-locals have been deprecated they will also hijack an
> unallocated block of addresses to use as private, same what happened
> prior to RFC 1597 for the very same reasons (difficult/pricey to get
> PI).

I guess you missed out on:
http://www.iana.org/assignments/ipv6-address-space

FC00::/7  Unique Local Unicast[RFC4193]

You can use that to generate your local prefix and it is much better
than site-locals as the chance of collisions is fairly low. And as you
know you simply don't want to do a NAT from 10/8 to 10/8 at one point in
time when two big companies merge ;)

> >> Michel Py wrote:
> >> A protocol that would be only v4 with more bits in the first place, 
> >> with routers / NAT boxes that would pad/unpad extra zeroes (also 
> >> including extra TBD fields). As this would be 100% compatible with v4
> 
> >> this could be deployed without too many headaches.
(I almost got lost in the attribution level here)

Then why is IPv6 causing so many headaches? As one can see 6to4 is
mostly making up your IPv4+ address from the IPv4 one by doing:
 2002 +  + padding bytes ;)

Ah, of course, one actually need to upgrade most of the internal stuff
and upgrade all the applications, convince managers, get money to do it,
do training etc...

Also for the rest of the thread, overlaying IPv6 over IPv4: RFC4380
Which is more or less a p2p overlay network using IPv6 as the addressing
part and thus leveraging a lot of applications already.

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: "too many notes" -- a modest proposal & Re: Proposal for keeping "free speech" but limitting the nuisance to the working group (Was: John Cowan supports 3683 PR-action against Jefsey Morfin)

[Jeroen Massar]

[aggregated message, the from's are in the cc, Rob see first reply]

Top-PS: Did folks see and read the following:
http://www.ietf.org/internet-drafts/draft-hartman-mailinglist-experiment-00.txt


Michael Thomas wrote:
[..]
> Perhaps we should take a lesson from TCP and set a receive window
> on IETF mailing lists in the face of conjestion. The sender is thus
> obligated to keep the transmission within the window, and as a side
> effect to consider the quality of the, um, quantity. Just this simple
> step would greatly limit (purposeful) DOS attacks and other death
> spirals. It also mitigates the "free speech" attacks by not throttling
> based on content (which is inherently contentious), but based on
> wg mailing list "bandwidth".

A couple of mailinglists already have a form of this, eg for the ipv6
working group mailinglist, see:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg06123.html

This started somewhere around 18 Aug 2003 on request of the chairs.
ftp://playground.sun.com/pub/ipng/ipng-mail-archive/ipng.200308
Note that the list was then still hosted at SUN.

Afaik, since this was introduced, people did start posting with higher
content quality and lower quantity. Maybe Rob Austein can provide the
numbers in a nice graph or some other details?

Steve Silverman wrote:
> It seems to me that limiting users to 3 messages / day (perhaps with a
> maximum number of bytes) would be a
> minimal impact on free speech but would limit the damage done by
> overly productive transmitters. This could be limited to users  who
> are nominated to a "limit" list by many users.

Limiting to less than 3 per day would be the same as suspending for X
hours. Next to that it might also inhibit one from fixing a statement,
though of course one should re-read their post before posting.

> How difficult this
> would be to implement on the message exploders is another question.

Mailman is python and it should not be to difficult to add per-poster
counters, but this would also require that the secretariat applies those
patches and then hope that these changes are really working perfectly
well. A lot of testing would be required. Many people depend on the list
software, breaking it is not something that will be taken lightly ;)
Also avoiding such counters can be done easily by using multiple
subscriptions, but indeed that would be obvious.

Doug Royer wrote:
> 
> Are you going to write mailing list software an provide it
> free of charge to implement all of this?

That already exists, it is called Mailman, which is what at least
@ietf.org uses and several of the lists not hosted here also.
Note the "X-Mailman-Version: 2.1.5" header in every post.

The existing lists are already there, just add an extra 'full' list,
subscribe the mainlist to the full list, which is quite normal with
umbrella lists, and presto. Now when somebody gets suspended from the
mainlist, the WG Chair can then ask the listadmin to move the
subscription of the to be suspended person from the mainlist to the
alternate list. Thus add on full, remove from main.

The technical part is the very easy part here. It is politics and maybe
more over ethnics and some other factors which are the hard parts.


Harald Tveit Alvestrand wrote:
[..full/main list..]
> In fact this has been implemented at least once that I know of - on
> the DNSO GA mailing list. The "full" version had relatively few
> subscribers.

Only suspended folks or "suspended-lovers" (AmaViS style) would indeed
be interested in following it. To avoid this we could, at first setup
the full list to contain all the members of

The DNSO list also has a long 'rules of order' file:
http://www.dnso.org/dnso/notes/2000.GA-ga-rules-v0.4.html

> Another variant is the ietf-censored version of the IETF list that I
> ran for a while, but left to others when becoming IETF chair - google
> claims that
> 
> is a current page for it.

I guess the main problem with this list is that the WG Chair doesn't
have (much) influence on it. It is neither an official list. Also it is
not clear who has been censored or not, which indeed means censoring,
while IMHO we still want to allow people to voice their opinions and not
simply discard them. The naming 'censored' is thus quite correct for
this list but I that is also something that the IETF should steer clear
from with a wide angle.

Darryl (Dassa) Lynch wrote:
> 
>
> I was a subscriber to both of the DNSO GA mailing lists and I do think
> the experiment worked for the most part.

As the list isn't active any more it might be useful to get input from
the members of the list that where then participating. Of course from
both the "I want to be on the main" and "on the full" lists. Off-list
replies for 'counting' are welcome.

> I've seen this a few times [..] Anything that can be done to improve
> participation is a good thing.

Exactly my opinion.

> PS...I've known Jefsey online since those early DNSO an

Proposal for keeping "free speech" but limitting the nuisance to the working group (Was: John Cowan supports 3683 PR-action against Jefsey Morfin)

[Jeroen Massar]

Anthony G. Atkielski wrote:
> Pekka Savola writes:
> 
>> Why must each and every WG member be required to filter a person's
>> postings?  Much more convenient to do so in one place.
> 
> Because each and every WG member is an individual, with his own ideas
> of what he does or doesn't want to read, and imposing the same rules
> upon everyone prevents members from making their own decisions.  It
> also imposes the decisions of a small minority upon the majority.

Here goes for a try... flame me off list if required.

As it is indeed quite controversial to 'block' people, maybe there can
be a solution that, though it will have overhead for listadmins, it will
help the process that the workinggroup is actually for in the first place.

In the several messages there have been brought up a number of solutions
 to the problem where one or multiple entities are (deliberately)
flooding/overloading the mailinglists of workinggroups and other places
with off-topic messages.

There seem to be a couple of solutions, amongst which:
 - Filtering based on source address at the receiver
 - Filtering based on keywords, which has really bad side-effects.
 - Blocking the sender at the mailinglist level.
 - 3683 PR for complete full blockage of posting rights.

The first is reasonably fine, as you don't see the message of the entity
that one finds not useful, but you might see responses of others thus
this is still intrusive and you still get those messages which you
wanted to filter out. The second option might filter out messages which
you did want to read. Both still will get these messages in the
mailinglist archive, even though there was a consensus that those
messages are unwanted.

The third and fourth option are pretty definitive, no more messages from
that entity, but this might be seen as silencing this persons freedom of
speech.

My proposal to solve this issue but keeping everybody happy:

Two mailinglists: @ietf.org + full.@ietf.org

full.@ is completely open, anybody can post anything they want
though hopefully on topic on the subject of the workinggroup and of
course based on the source address having a subscription *1
full.@ is subscribed to @ thus full.wg gets everything
preserving, at least parts, of the freedom of speech that is wanted and
for the people who want to read a lot of mail everyday.

Initially everybody who signs up to the @ list can post to it.
When the consensus on the list is that a member is not participating
correctly, ignoring warnings etc, like currently this member can be
banned from the list for a temporary amount of time. The member can
still voice his opinions on the @ list. This thus allows him to
voice his concerns to the members that do want to read them. Like the
current 3683 PR the ban can become effectively indefinitely for the main
list, while the poster is still and always allowed on full.@.


The big concern here is of course that one could say that if you get
booted out of the group that your voice won't be heard as they are not
reading the other list. This is of course true, but one can raise their
concerns on the full list, for instance Google won't differentiate
between them and there will always be folks who will listen to it and
forward these concerns when they have valid argumentation. By posting
'good' messages to the full.@ list a member can also demonstrate
that he is really willing to contribute instead of disrupt. One of the
nicest controversies is of course what to determine good and bad,
starwars as an example, how bad are the jedi and how good are the sith,
it completely depends on the side you are on, nothing else. That all
boils down to trust and other factors, any mailinglist admin could abuse
his position to set the sender of an address to silently discard, SMTP
can have a CC: in the header and mailman will not forward the message to
that person and various other nice tricks.

I hope the above might give a better point to discuss all this over
instead of seeing replies like "that is not good" "see above" and other
comments without effective constructive arguments.

Greets,
 Jeroen

*1 = to avoid the large amount of spam flowing to the various lists
which nicely get blocked because of subscription regulation.




signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: List archives and copyright [WAS Re: John Cowan supports 3683 PR-action against Jefsey Morfin]

[Jeroen Massar]

Michael Froomkin - U.Miami School of Law wrote:
> 
> 
> If you post to a list with a publicly announced public archive -- and
> even more so if you are informed about the archive at the time you join
> the list (hint: you usually are) -- then I think it's pretty clear under
> US law [..]

IANAL but one really doesn't have to bother with US law, that really
doesn't apply to many folks (fortunately :) There is a much better thing
than US law, it's called IETF, and the fact that there is:
http://www.ietf.org/maillist-new.html which contains:
8<--
All IETF Contributions are subject to the rules of RFC 3978 and RFC 3979.
-->8
Mailinglist traffic also are subject to that.
One gets a copy of this when signing up for the various lists.

On Mon, 23 Jan 2006, Anthony G. Atkielski wrote:

> Since public archives are usually a violation of copyright, anyway,
> the entities that maintain them are poorly placed to complain.

According to you Google and every other website indexing service is a
violation of copyright, better get sue'ing then, you might get rich.

> And archives can be purged after the fact, without impairing the flow
> of messages to the list in real time.

Archives are meant to store things, which is what they are doing, if you
don't want to contribute then simply don't.

Greets,
 Jeroen

(Who wonders that now I've quoted mr Atkielski if I am in violation of
his copyright...)




signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: John Cowan supports 3683 PR-action against Jefsey Morfin

[Jeroen Massar]

Anthony G. Atkielski wrote:
> John Cowan writes:
> 
>> Filtering him out individually, as I do, is insufficient: one still must
>> read the polite or exasperated responses of others.  I am almost at the
>> point where I will filter any posting that so much as *mentions* him.
> 
> Why don't you do that, then, so that he need not be banned just for
> your convenience?

And then suddenly somebody makes a seriously good contribution and your
filter accidentally filters out that message which does have a lot of
value and thus importance for the working group. The signal to noise
ratio has risen way too much by all this talk about one person and
simply takes away a lot of time from a lot of people who can do a lot
more technically interesting work when that ratio is brought back to
signal instead of just being noise. Being able to completely shutdown a
person after having repeatedly warned that person about his behavior is
the only real solution here.

Another aspect is that the mailing lists also contains those
non-technical,non-wg-relevant discussions which effectively are on the
level of Usenet-alike flame war going back and forth in the mailing list
archives. Anybody wanting to join the wg will only find those messages,
possibly missing out on the things that really matter. That doesn't help
in progressing the task of the working group at all. Discussions should
be based on technical aspects relevant to that working group, not to a
myriad of other arguments which are far from the topic of the WG's task.

Yes, it is excluding somebody from giving his viewpoints, but it is not
without arguments that this will be done and the person who this is
bestowed upon has had many chances of bettering his way of posting and
drifting off topic all the time.

Note also that the PR only allows the complete banishment from the list
if that WG decides that that is deemed necessary. Other WG's which do
not have a problem with the postings of a PR'd person can freely choose
to accept them, but of course then have a choice to ban the person too.

[..]
> But you still mention irrelevant matters external to this mailing list
> in your post. Any personal problem you may have with someone outside
> the list (or vice versa) is completely unrelated to IETF work or
> mailing lists, and the inconvenience you suffer from having to press
> the delete key is also only very tenuously linked to this list.

Thus in your opinion you tolerate the behavior where people contact your
boss for actions you take personally (IETF is on personal basis not on
business basis, at least in theory) on a public forum!?

Another way to look at your point of view is to say that mailinglists
should accept spam. As the enduser who receives the list should simply
filter them out.

If somebody has a problem with you in the way you are behaving in such a
forum one contacts the list administrator or working group chair. It's a
list issue when it originates on the list, not a business issue, thus
your boss has absolutely no relevance in this area. It more sounds like
such a method can only be meant as a backstabbing 'teach a lesson'
method to a person than anything else. What good does that bring?
Or do you also call up the wife of the WG chair when you don't like his
decision to complain to him that she should give him food that evening
as you don't have any arguments left any more and simply start doing ad
hominem attacks?

> Maybe your employer's advice wasn't so bad.

That is is true of course, looking at the situation, taking a bit of a
stand-off point of view, reiterating things before doing etc are a good
thing, but sometimes the SnR ratio simply becomes way to high...

Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: I-D file formats and internationalization

[Jeroen Massar]

Hallam-Baker, Phillip wrote:

> It might seem odd to people whose names do fit in ASCII but there are a
> lot of people who care about this type of issue.

You can of course publish drafts and RFC's as XML which supports any
character set you want.


> The IETF has had the attitude 'this is
> the way we do things here, nobody asked you to like it'.

It would be better to state: "if you don't like it, participate".
Because if you didn't participate, then don't complain that it isn't
like you wanted it to be. Yes that requires significant effort, time and
thus cash, but that is mostly unavoidable.

> So far 700 translations of W3C specifications have been made by


One can always start translating RFC's: 4267 RFC's and a long list of
drafts to go, though there is a lot of material already translated by
book authors. Note that many languages don't have translations for many
English words. German is one of the good examples where they have a lot
of German versions of English words, but they don't have one for 'Hyper
Text Transfer Protocol' unless you babelfish it to "Hyper
Text-Übergangsprotokoll"*, which is far from a useful translation. There
is also the thing that sentence construction might cause
misinterpretation from what the original working group meant. SHOULD and
MUST both translate to Muß in German, which is thus not correct either.
This can cause many issues.
And German is somewhat in the same line as English, I am not even
thinking in the area of Asian languages, which I unfortunately am far
from familiar with except that they resemble small pictures of what they
mean.

I don't think it is a task for the IETF itself to translate documents.
But it would indeed be nice to have a place for them, with a big note
that they have not been verified and may include odd translations. Maybe
there could be a separate 'translated documents' section?

Greets,
 Jeroen


* contains a U-umlaut (Ü) and Ringel-S (ß)



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Spam in the IETF's name?

[Jeroen Massar]

On Thu, 2005-10-20 at 08:40 -0700, RL 'Bob' Morgan wrote:
> On Thu, 20 Oct 2005, Harald Tveit Alvestrand wrote:
> 
> > That's what got me upset over that aspect; if it had started out "I and 
> > a few other friends have this great idea that we're pushing in the IETF, 
> > and we want to meet to talk about it", I'd only have been upset about 
> > the method, not the content.
> 
> It seems to me the actual IETF involvement here (and I got the invitation 
> too, more than once) is that the list is hosted @ietf.org.  I wasn't aware 
> that IETF hosted lists for discussion of things that might become WGs.  I 
> see from https://datatracker.ietf.org/public/nwg_list.cgi that in fact 
> there are quite a few, including this one.  But I also see that such 
> things require AD approval.  So presumably the [EMAIL PROTECTED] initiators 
> submitted something to the apps-area ADs to support this list creation. 

Another point that would be good to do is that there is an announcement
on the ietf-announce list when a new list is created, stating it's
purpose so that people who are interrested in this area now that it is
happening and not behind people's backs. At the moment one could check
on the mailman/listinfo/ page all the time but that isn't really
helpful.

Thus: please announce new lists when they are created.

Greets,
 Jeroen

PS: I like the idea of Digital Identity coming into the IETF arena, thus
I signed up, as for the BCC's I prolly didn't see it as SA-marked spams
go into /dev/null; enotime for checking them...



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: George Green takes over internet Re: 5W Intelligence Service Report

[Jeroen Massar]

Just a little clarification for the archives as this is of course again
mis-propaganda etc

On Wed, 2005-10-12 at 15:58 -0400, Joe Baptista wrote:
> Yes - both patents attempt to take control of the adding of tlds to a root
> zone file.  The second patent recorded on 6 July 2005 is an attempt to
> further recognize the proceedure as being commercial.  Will need some
> native speakers to make out the exact wording on the original patents.


> > http://nl.ecodoc.mineco.fgov.be/BASIS/BREV/web/brevwebdut11/DDW?W%3DTI+PH+IS+%27TECHNOLOGIE+EN+BUSINESSMODEL+INZAKE%27%26M%3D2%26K%3D004/0623%26R%3DY%26U%3D1
> >
> > http://nl.ecodoc.mineco.fgov.be/BASIS/BREV/web/brevwebdut11/DDW?W%3DTI+PH+IS+%27TECHNOLOGIE+EN+BUSINESSMODEL+INZAKE%27%26M%3D1%26K%3D005/0340%26R%3DY%26U%3D1

For Non Dutch Speaking people, these two URL's both contain a very
important part:

8<
Beperkingen:  4. GEWEIGERD / AFGEWEZEN 20050404
>8

Which translates to:

8<
Limitations:  4. REJECTED 20050404
>8

In other words, nobody is getting any patent.
There would be a lot of prior art anyway ;)

Now back to your normal IETF schedule

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: a new DNS root for the world?

[Jeroen Massar]

{sort-of IETF off-topic but we have RFC3675}

On Mon, 2005-10-03 at 09:59 -0700, Paul Hoffman wrote:
> At 11:58 AM -0400 10/3/05, Marshall Eubanks wrote:
> >Wouldn't it at least make  sense to require that the .gprs
> >"pseudo-TLD" be reserved by IANA under Section 4 of RFC 2860 
> >("technical work items" and
> >"assignments of domain names for technical uses"), with the proviso that
> >this TLD must not be resolved, except locally ?
> 
> Absolutely not. There are already literally dozens (if not hundreds) 
> of such local tlds, some of which have the same names for different 
> purposes.

You don't want .sms, .wap, .wap2, .gprs2, .turbogprs ??? :)
There is already a .mobi coming up too, another useless domain.
http://www.icann.org/tlds/stld-apps-19mar04/mobi.htm
Will we also get .computer for computer manufacturers, .toy, for toys?
I don't see any reason why they could not have sticked their .mobi
under, something odd; like say: mobi.corp.com, aren't they doing the
mobile stuff in the first place? But the reasoning for this domain is
really great: stakeholders -> money.

http://www.domainbank.net/mobi/index.cfm also lists an excellent things:
"As many companies were beaten in the rush to acquire desired .com
domain names, the .mobi sTLD is a new channel to differentiate your
business from the sea of .coms and .nets and to protect your brand
name."

and I really wonder who is going to deliver the news for all the mobile
users:
"Further attributes of the .mobi sTLD include personal names (e.g.
User_name.name.mobi) and location-based services (e.g.
NewYork.news.mobi) utilizing the .mobi sTLD."


IMHO there should have been only:
 - cc-tld which each contain:
   - gov.cc - for goverment organisations (including military)
   - .cc : for companies and others, first come, first serve
 no products, no movies, only organisations/lastnames.
 - int for global organisations/companies

Indeed way less than what everybody else seem to want.
But unfortunately we got the mil/gov/net/com stuff as legacy, which sort
of breaks the hierarchy. New domains though are uncalled for IMHO.

DNS is there for name esolution, not for finding a company or a product.
hamburger.int is useless imho, as it is sold by company X, if they want
that in the dns then do it hierarchically: hamburger.foodcorp.int,
unless the shop is only there in one country: foodcorp.cc
If you want to find this hamburger, you will use a search engine, they
nicely index it for you, dns doesn't index anything in that way.

But apparently that is not how all the domain-selling cash cows are
thinking, they just see $$$

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard

[Jeroen Massar]

On Mon, 2005-09-05 at 15:02 +0300, Markku Savela wrote:
> LLMNR does create extra queries to root servers. Lets say I have named
> my local devices in LLMNR as
> 
>  "fridge"
>  "tv"
>  "vcr"
>  "myserver"

Which would be easily "solved" for both mDNS (when not restricting
to .local) by first asking the local network using mDNS/LLMNR and then
asking DNS. Which takes away the worry of flooding (root) dns servers.
(Misconfigured machines are a bigger problem there)

This has a *huge* security issue of course when some one starts replying
to all those queries with false data (www.paypal.com anyone?, or
responding for www.ietf.org and putting all kind of naughty words in the
drafts ;)

Then again, hosts on the local network can already easily respond to
normal DNS queries too by flooding the switch with MAC addresses,
putting it into broadcast mode and then simply responding to queries. Of
course one will then get some dupes back from the original one which
will make things a bit confusing, but most resolvers don't care about
those and simply ignore them anyway (afaik). I guess we want DNSSec
here, but that was the whole point -> zeroconf...

That said, it would be really good if both mDNS/LLMNR had a 'off'
switch. When a real DNS server responds then we have a working DNS
server, with mDNS/LLMNR being targetted at zero-conf networks,
apparently, as we have DNS, these networks are configured, they have a
working DNS server, thus mDNS/LLMNR is not required. Folks can then use
DDNS and other methods for registering names.

Another thing one could do then is have a real DNS server respond
directly to these mDNS/LLMNR queries, which avoids one to even configure
a DNS server.

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)

[Jeroen Massar]

On Thu, 2005-09-01 at 20:08 +0200, Harald Tveit Alvestrand wrote:

> The difference between LLMNR and mDNS here seems to be that mDNS *requires* 
> me to use two different names in the two different cases; LLMNR, while it 
> certainly *permits* me to do so, does not *require* it.

Can I read this as "LLMNR SHOULD be used with domains in the .local
domain" ? Which puts it really in the same baliwick as mDNS (that is the
version that existed before that draft was written with the name mdns ;)

One can of course easily remove the check for the .local from the real
mDNS and use it for anything else too. Just change the MUST into a
SHOULD in the draft and everybody is happy.

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Jeroen Massar]

On Thu, 2005-09-01 at 09:38 +0200, Frank Ellermann wrote:
> Jeroen Massar wrote:
>  
> > [for as112 project: maybe add .local into the list of domains??]
> 
> (?)  Better add ".local" to a hypothetical 2606bis.  Bye, Frank

Full ack.

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Jeroen Massar]

[for as112 project: maybe add .local into the list of domains??]

On Wed, 2005-08-31 at 14:24 -0700, Christian Huitema wrote:
> > >Windows 98, Windows 2000 and Windows XP do not enable LLMNR by
> default.
> > 
> > Christian, could you please tell us, for each OS mentioned, how to
> enable
> > LLMNR? That would enable everyone participating in this discussion to
> > witness for themselves exactly how it works and what it does.
> 
> You would have to get an experimental implementation of LLMNR from some
> developer site.

This is not 'simply enabling it' :) And then I also wonder if there
actually is an implementation for Win98/Win2k those two being pretty old
and quite unsupported by now I guess... but this besides the point.

> To the best of my knowledge, Microsoft is not shipping
> this code. In these systems, ad hoc names are resolved through NETBIOS.
> The ".local" queries observed in Peter's root servers is most certainly
> not caused by an LLMNR implementation. 

They are most likely done by these nice DSL "router" (NAT :) setups.
Most of these devices have a .local zone configured too. I would not be
surprised if these leaked their queries to the root servers.

That said, if people want to limit the effect of these 'bogus' queries
onto the root servers I suggest that ISP's join into the AS112 project.
Also it would maybe be an idea for AS112 to add .local there?

Greets,
 Jeroen

PS: Who ever named the LLMNR draft 'mdns' isn't that completely
confusing for people looking up the mDNS draft, that is the protocol
that Stuart made? :)



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Jeroen Massar]

On Wed, 2005-08-31 at 13:14 +0200, Brian E Carpenter wrote:
> Peter,
> 
> Peter Dambier wrote:
> > Russ Allbery wrote:
> > 
> >> Margaret Wasserman <[EMAIL PROTECTED]> writes:
> >>
> >>
> >>> Other than a few minor issues that are being dealt with in a -43 update,
> >>> I don't think that anyone has raised a blocking technical issue with the
> >>> LLMNR specification during this IETF LC.  If you (or anyone else) has
> >>> intended to raise a blocking technical issue, either with LLMNR itself
> >>> or with its ability to coexist with mDNS, please make that clearer to
> >>> me.
> >>
> >>
> > 
> > Sorry I overlooked this:
> > 
> > I dont count 25% of the root server traffic a minor issue.
> 
> Can you point to publicly available data about the rate of .local
> queries to *all* the root servers (including the anycast servers)?

Check for only "K": http://k.root-servers.org/index.html#stats
Interresting one here is NXDOMAIN responses:
http://k.root-servers.org/stats/linx/xstats_SNXD-all.html
(note, that is only the LINX node)
It is a large part of the traffic and annoying, 0.763 k out of 2116 k
queries/sec. Interrestingly that since about June it started to decline
which could be because these real root-servers
(http://www.root-servers.org/) also have a project called AS112
(http://www.as112.net), which takes care of at least the reverse trees
for RFC1918 space.

For instance, the Italian node (http://frejus.itgate.net/as112/), run by
ITGate is seeing about 100 queries per second for their point of view.
The RIPE one (http://www.ripe.net/as112/) in Amsterdam does about 300
queries/s so it really depends on ones point of view.

For real details I suggest one to ask either Olaf Kolkman or Daniel
Karrenberg (both cc'd so they will not skip this message ;) or other
root-server operators who can shed way more light on this subject.

In short: having something query for known bogus domains is bad and
hurts the root-servers. It can be limited a bit, but not much.

Additional note: Making zones 'up' and making an 'alternate root' causes
that sometimes these zones leak into the real root, where they don't
exist. Eg this happens in misconfiguration cases or people publishing
the alternate root DNS names, which don't exist for the rest of the
world. That said having an alterante root is more disruptive than having
LLMNR.

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: regarding IETF lists using mailman: nodupes considered harmful

[Jeroen Massar]

On Fri, 2005-08-26 at 03:56 -0400, Ken Raeburn wrote:

> On Aug 26, 2005, at 03:14, Jeroen Massar wrote:
> > Indeed when some 'malicious' person would add Cc's/To's and would
> > instruct his SMTP to not forward to the additional addresses in the
> > Cc/To the users will effectively not receive the message.
> 
> > But how exactly does this cause a problem?
> 
> Isn't that enough?  Tricking the list software into excluding certain  
> people from part of a discussion, even if it's only the part sent by  
> one certain submitter?  It gives a false impression to the other list  
> members that certain list members are part of the discussion when  
> they have quietly been left out.

Yes, which is why it might be good if the IETF Secretariat would:

 * Disable the nodupes feature
   That is, that per default it is disabled and folks get 'dupes'.

 * Notify, once, the users who have nodupes active, that it might
   affect the amount of mail they are getting, referencing or
   including Keiths original message.

Does this a) sound like a good idea, then b) can this be requested?

Rest of this discussion follows but can be skipped by most folks...

> If that's not bad enough, what if the message in question were forged  
> as being from someone who was also excluded from receiving it through  
> this mechanism? 

> (Of course, if the person is offline for a  
> vacation or something, the same might happen.  And habitually signing  
> one's messages may help call attention to the forgery, but we've got  
> a ways to go to make that commonplace.)

This part can be indeed only be solved by that simple step, which you
and I are already using: PGP sign the message.

Though privacy-folks then say 'but then I can't repudiate my message' to
which my silly answer is: either say something or don't.

I would actually be in favor of a mechanism where only PGP signed
messages get forwarded onto the list, others bounced back to the origin
stating that the sender can't be verified and that this might be because
it is not the original sender + how to setup and use PGP. This also
avoids having to check if a message from 'the iesg' actually comes from
the iesg by checking the headers. SPF will only help partially in this
case.

> Malicious intent aside, it's also useful to know sometimes if the  
> mailing list software is somehow munging your messages in a way you  
> didn't intend.  Stripping out attachments, converting encodings,  
> changing HTML to plain text, etc.  (And I've seen mailman  
> occasionally botch some such processing, leaving empty messages, but  
> I don't recall the specifics at the moment, or if it's been fixed.)

They have fixed quite a number of issues in that department
fortunately ;)

I personally like the 'nodupes' feature very much as messages that I get
cc'd on, thus most likely a reply to something doesn't get caught by the
List-Id header and then sorted in the correct folder, thus ending up in
my direct-message folder on this subject so I know that it is a reply
and I need to pay attention to it.

Something semi-related, nobody complains about the fact that one can Bcc
people which thus leads to other people than indicated in the To/Cc to
read the message, not that one knows the membership of most mailinglists
but still...

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [Re: regarding IETF lists using mailman: nodupes considered harmful]

[Jeroen Massar]

On Fri, 2005-08-26 at 10:33 +0200, Peter Dambier wrote:
> Hi Jeroen,
> 
> I forwared your message - not replying to show your headder:
> 
> From: Jeroen Massar <[EMAIL PROTECTED]>
> To: Keith Moore 
> Cc: ietf@ietf.org



Which causes my mailer to forward to purgatory.unfix.org, which I use as
my outbound mail box and instructs it to send it to:

Aug 26 09:15:07 purgatory postfix/smtp[27087]: 7A73D7FAD:
to=, relay=smtp.cs.utk.edu[160.36.56.220], delay=8,
status=sent (250 Ok: queued as 7FC99273B5)
Aug 26 09:15:39 purgatory postfix/smtp[27088]: 7A73D7FAD:
to=, relay=ietf-mx.ietf.org[132.151.6.1], delay=40,
status=sent (250 OK id=1E8YRo-0002xE-QX)

Thus the list gets it, and thus everybody who is subscribed.
Keith might get it *twice*:
- The first directly from my SMTP box to his
- The second from mailman, unless he activated the nodupes option.

But as the lists have nodupes enabled per default, he most likely gets
it ones, only from me.

Thus if I was very mean and I hated Keith (is that possible? :), I could
have simply nullrouted his SMTP, or instructed my mailer to ignore the
cc's, indeed, Keith would not have received the message from me, and
when he would have turned off the nodupes option, which is enabled per
default, would not have received it from the list either. But as I like
arguments I refuse to do something silly like that, there might be
people who do though for whatever reason.

Reading material: RFC2821 + RFC2822 and most likely quite some others.



> So you had sent to [EMAIL PROTECTED]
> ietf@ietf.org received only a copy. Some people might have got
> nothing.

Which people? The only person who might not have received anything is
Keith, and only if I would sabotage it forcefully, see above, or some
disaster occured somewhere.

> That is what we all need to do now if I got it correctly.

Correctly understanding the workings of SMTP or something else?

Greets,
 Jeroen

PS: Before you ask, you get this message:

if (mailman->nodupes==active && jeroen->isevil()) amount=0;
else if (mailman->nodupes==active && !jeroen->isevil()) amount=1;
else if (mailman->nodupes==disabled && jeroen->isevil()) amount=1;
else if (mailman->nodupes==disabled && !jeroen->isevil()) amount=2;

Where jeroen->isevil, could mean that a SMTP box between me and you
filters the message out, maybe even a spamfilter could cause that.
But the same could happen between the ietf mailservers and you...
One simply can't be sure that a message gets delivered.



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: regarding IETF lists using mailman: nodupes considered harmful

[Jeroen Massar]

On Thu, 2005-08-25 at 18:20 -0400, Keith Moore wrote:


> Specifics:  Mailman has a per-recipient setting called "nodupes".  The
> effect of this setting is that any recipient address that has the
> nodupes flag set, and which appears in a To or CC field of a message
> sent to the list, will not receive a copy of the message from the
> list.

But they _should_ be getting the message directly already, because of
the CC: or To:. Or is there something which causes the person not to get
it?

Indeed when some 'malicious' person would add Cc's/To's and would
instruct his SMTP to not forward to the additional addresses in the
Cc/To the users will effectively not receive the message.

Or when the recipient doesn't accept messages to [EMAIL PROTECTED] +
himself, and expects everything to come from the list directly.

But how exactly does this cause a problem?

Greets,
 Jeroen




signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why have we gotten away from running code?

[Jeroen Massar]

On Wed, 2005-08-10 at 15:25 -0400, Henning Schulzrinne wrote:
> The next SIPit event is in about a month; see http://www.sipit.net/
> 
> There was a GIMPS (now GIST) + NSIS NSLP interop event just before the 
> IETF meeting (pre-RFC).
>
> I wish there were more, but there are some.

The NSIS interop was co-located with IPFIX/NetFlow9 & NetConf, as can be
found at: http://www.ist-mome.org/events/interop/

The IPFIX interop resulted in a 30 min presentation/discussion during
the wg meeting and also solved quite a number of ambigues issues and
uncovered some things that many people might do wrong while making the
implementation. IPFIX is not in last call yet either, but having this
interop for sure improved the quality of the document a lot.

IMHO "Running Code" is a good thing, doing an interop before going to
last-call is even better. Thus, as mailed before, 2 seperate
interoperating implementations would be a good thing to have, not only
to take care of all the ambiguities, it also makes sure that the
document will actually be used and is not yet-another-paper...

Greets,
 Jeroen
 (who likes to actually implement things, not write about it ;)



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why have we gotten away from running code?

[Jeroen Massar]

On Sat, 2005-08-06 at 19:07 -0400, Brian Rosen wrote:
> I notice that we have stopped being interested in running code.

Not everywhere. For the IPFIX protocol, which is currently still in
draft status, there where 6 different implementations, both of collector
and meters, showing up at the Interop meeting, which took place just
before the IETF63. This helped a lot in finding a number of ambigueties,
which caused the document editors to revise/reword some parts of the
document and will also provide a lot of input, eg common
mistakes/misassumptions to the implementation guidelines.

Maybe there should be requirement that before having going to Last Call
there should at least be 2 separate implementations when a document is
created by a working group?

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: "IETF servers aren't for testing"

[Jeroen Massar]

Iljitsch van Beijnum wrote:

> Limiting myself to the www.ietf.org webservers (yes, this address 
> points to two different hosts) it appears this site runs on:
> 
> Server: Apache/2.0.46 (Red Hat)
> Server: Apache/2.0.40 (Red Hat Linux) DAV/2 mod_ssl/2.0.40 OpenSSL/ 0.9.7a

www1.ietf.org @ cnri/reston.va.us/cogent + www2.ietf.org @ foretec/uunet

This is done for failover/bombproof etc reasons, not the perfect thing
to do but that will change one day with HIP/shim6/sctp/lot of other hard
work that many people are doing.

> Even though these Apache versions are 2 - 3 years old (with many 
> vulnerabilities found and fixed in the mean time), they're fully 
> capable of supporting IPv6, as are Red Hat Linux versions of around  the
> same age.

The problem here seems to be more the fact that, in the US, getting IPv6
connectivity can be quite tiresome. Cogent, the current IPv4 upstream,
doesn't do IPv6 (they have 2001:500:2::/48) for instance. UUnet could
maybe do IPv6. Maybe the secretariat would wants to try out some tunnels?

In any case http://www.ietf.org.sixxs.org also works, though it might
indeed be nice if this trick was automatic without appending the domain.

Greets,
 Jeroen

PS: I assume RedHat backports fixes so that 2.0.40 actually is a 2.0.53
but with a different version number...


signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF63 Network and IPv6

[Jeroen Massar]

Brian Haberman wrote:
> IETF'ers,
>  I would like to raise an issue with everyone in Paris using the
> IPv6 support provided by France Telecom and the volunteer NOC
> squad.  There are a few rogue client nodes advertising themselves
> as IPv6 routers.  Here is a list of the guilty parties:

>   - 2001:0688::24::/64

This prefix is actually the one you are supposed to be using, but indeed
this one comes from the wrong MAC which is far from nice. Sort of looks
like a redirection/mtm attempt.

6to4 prefixes will only 'hurt' when connecting to non-native.

Checking my traceroutes from here to eg unfix.org or noc.sixxs.net, I
guess I can conclude that FT/OpenTransit might want to start doing a
little more peering, eg by going to AMS-IX and setting that up.

And this is the bad part of it all there is not usually an easy way
to disable accepting of the RA's from a certain device. OS's should have
  a toggle for this. Of course the ipfw/iptables toggle works here.

> Regards,
> Brian
> Just a poor IPv6 WG co-chair trying to use IPv6 to phone home

My connectivity over IPv6 has been reasonable to good, but the flakyness
was more the wlan which got saturated on some moments.

And hail to SEND that would be a welcome addition indeed.

Greets,
 Jeroen


signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: SRV continued

[Jeroen Massar]

On Tue, 2005-07-19 at 19:39 -0700, Hallam-Baker, Phillip wrote:
> While we are on the subject of SRV, port numbers etc:
> 
> Why not define SRV prefixes for POP3, IMAP4 and SUBMIT so that email
> applications can auto-configure from the email address alone.

Actually.. there is, at least in draft form:
http://www.ietf.org/internet-drafts/draft-massar-dnsop-service-00.txt

8<---
   This document defines a new domain, _service., which can be used for
   automatic service configuration and discovery.  The associated
   anycast prefixes can be used to configure a default DNS server, which
   provides lookups for a local _service. domain but also acts as a
   (caching) recursive DNS server, thus allowing DNS clients to use this
   well-known address as their default DNS server as well as to use it
   to find various well known services, thus avoiding manual
   configuration.
--->8

Applied to automatically setting up IPv6 tunnels:
http://www.ietf.org/internet-drafts/draft-massar-v6ops-tunneldiscovery-00.txt

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)

[Jeroen Massar]

On Tue, 2005-07-19 at 09:23 -0500, John Kristoff wrote:
> On Fri, 15 Jul 2005 11:48:28 -0700
> "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> wrote:
> 
> > There are certain limitations to the SRV prefix scheme but these are
> > entirely fixable. All we actually need is one new RR to allow one
> > level of indirection to be introduced. With that in place it is
> > possible to use prefixed SRV records in place of port assignments and
> > prefixed TXT records as a means of expressing protocol configuration
> > information.
> 
> I'm concerned this may usher in DNS SRV message filtering in addition
> to protocol port filtering.

Filtering can always be done, that is the right of the network
administrator doing the filtering. That some users won't like it is
indeed an issue, but that is political and not technical.

> One way of addressing that potential
> effect is to make the port assignments be negotiated between two
> communicating end hosts.  This could be used with or without DNS.  It
> might also provide some remote attack protection, since only a simple
> passive listener is used to perform the local/remote address/port
> selection for any active client before the real communication switches
> to agreed upon (and bound only to) the two process end points.

As previously mentioned, RFC1078 - TCPMUX:
 http://www.ietf.org/rfc/rfc1078.txt

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)

[Jeroen Massar]

On Thu, 2005-07-14 at 15:54 +0100, David Hopwood wrote:
> Brian E Carpenter wrote:
> > 3. Thus I come to the key question - how high should the bar be for
> > assignments in clearly constrained namespaces? This month's poster
> > child is IPv6 option numbers, but at an even more basic level, we
> > should probably be more worried about port numbers, where we seem
> > pretty close to running out of well-known numbers, and moving along
> > nicely through the registered port numbers.
> 
> I was surprised that TCP-over-IPv6 and UDP-over-IPv6 didn't increase
> the port number space. I know it's off-topic here, but anyone know why
> they didn't? It surely must have been considered.

It would not make much sense, between 2 hosts you can already have
65536*65536 possible connections*, which should be more than
enough(tm) ;) I wonder if there are any hosts actually using more than
65536 connections at the same time.

Greets,
 Jeroen

* = Listening sockets of course limit this quite a bit, but even with
2 listening sockets, 40k*60k is still a lot.



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Where to find drafts + state etc (Was: Re: IETF Newsletter: What's cooking?)

[Jeroen Massar]

On Wed, 2005-06-01 at 01:57 +0200, JFC (Jefsey) Morfin wrote:

> For example I am unable to understand when last calls are called, what are 
> the current last calls, what is the URL of the Draft people discuss and 
> never give the URL, etc.

URL's are volatile, draft versions are too.

Check: http://datatracker.ietf.org
type in what you are looking for and presto.

For tools: http://tools.ietf.org/

As for older versions of drafts:
http://www.watersprings.org/pub/id/index-all.html

And you might want to snoop around on http://www.IETF.org, it's all
there, especially if you do a google( site:ietf.org)

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: HTTP/1.1 Protocol: Help Needed

[Jeroen Massar]

On Mon, 2005-05-09 at 13:32 +0530, Gaurav Vaish wrote:
> Hi,
> 
>   I have a situation where the clients do not have cookies enabled and
> I have to authenticate through forms.

"Authentication through forms" is not the way that HTTP authentication
works. If you would be doing HTTP authentication*
You do need cookies then or you can use a special 'session id' option in
the tag.

You might want to read eg http://ch2.php.net/session as an example.
PHP uses PHPSESSID= in every url, which is the big disadvantage,
unless you have something to include it when you output to the user
again.

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Voting Idea? (Was: Last Call: 'Requirements for IETF Draft Submission Toolset' to Informational RFC)

[Jeroen Massar]

On Thu, 2005-04-07 at 07:18 -0400, Thomas Narten wrote:
> Jeroen Massar <[EMAIL PROTECTED]> writes:
> 
> 
> > Just like the above, except that the chairs can see the email addresses
> > that people gave when they voted. They could then check this list
> > against the list that has actually been signed up on the wg's
> > mailinglist and filter out discrepancies, might these exist.
> 
> Maybe this is pointing out the obvious, but discounting input because
> it comes from someone not subscribed to the list is Poor
> Practice. Often, the most critical (but also the best) reviews come
> from folk outside of the WG, who are not following the work closely,
> and are reading a draft entirely on its own merits, and from a broader
> perspective than the WG might have.

This was not obvious, at least did not directly jump into my mind to me
when I wrote the above part, but indeed is very logical.

On Thu, 2005-04-07 at 10:26 -0400, Bruce Lilly wrote:

> In short, quality of argument trumps (if the chair is chairing)
> quantity.  Voting (incl. as "straw polls") only measures quantity, not
> quality.

And I fully agree with that statement too.

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Voting Idea? (Was: Last Call: 'Requirements for IETF DraftSubmission Toolset' to Informational RFC)

[Jeroen Massar]

On Thu, 2005-04-07 at 08:05 -0400, Margaret Wasserman wrote:

> In the IETF, we use straw polls to get a sense of how many people in 
> the room have an opinion on a particular topic,

This room factor is also one of the reasons why I mentioned e-mail in my
message. Each WG has a set of active participants and a number of people
who don't visibly work, might lurk or do a lot of work behind the scenes
on the topic of the WG, at least these people are reading, hopefully,
the messages on this list. What if one of the hard working persons has a
lot to do, or due to sickness or whatever reason, maybe business
somewhere, raising his/her kids, or what about the very normal reason:
no time and money, to not attend an IETF meeting. Then this person will
not be in the room and thus can't participate in a vote, for which
he/she worked very hard to get around. This thus basically means that if
he/she can't be there all his work could be just hummed away by some
proponent sending in a lot of people, who never did anything at all, and
might not even know anything on the subject and let them hum their tone.

In short. if you don't have a lot of financial backing one is not
getting anywhere in an organization that is supposed to based on
individuals, whom are supposed to be doing work on free open internet
standards, but are unable to do so over that internet they are making
those standards for...

Just my two cents ;)

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Voting Idea? (Was: Last Call: 'Requirements for IETF Draft Submission Toolset' to Informational RFC)

[Jeroen Massar]

On Wed, 2005-04-06 at 11:52 +0200, Brian E Carpenter wrote:
> Well, I thought I'd try something daring. We have people
> arguing about xml versus nroff (again). If you write Internet
> Drafts, try this toy (and only vote once, please...).
> If the toy doesn't work, don't blame me... I just found the
> site with Google.
> 
> http://www.internationalvoting.com/int3/ask.cgi?pid=22-143

As this is the tools discussion after all, might it maybe be a good tool
to have a voting tool for the IETF?

Just like the above, except that the chairs can see the email addresses
that people gave when they voted. They could then check this list
against the list that has actually been signed up on the wg's
mailinglist and filter out discrepancies, might these exist.

Thus a following process could be made:

- WG Chair adds a vote (topic,description,options,enddate)
- Tool posts this new vote to the WG's list.
- WG members (*1) read this message and go to the URL
  that is given in the message
- WG member votes
- Tool sends a confirmation, to verify that this user
  is really that user that just voted.
- WG member confirms his/her/it's/* vote.
- Tool closes the vote
- Tool sends results to the list

The pro of this procedure is that votes can always be reviewed, checked,
they are easily accounted for etc. And best of all, it doesn't require
one to be present at eg a meeting, so if for instance there would be a
vote during a meeting, even remote participants can be in the vote. Only
requirement then would be that people are able to read their email
where-ever they are, but that should not be a problem for technical
folks would it ? :)

Single side-effect I quickly can come up with though would be that
people who are reading the WG maillist using an exploder address will
come out in the votes as 'bogus' as they are not signed up.
These folks could of course be asked under which address they are signed
up or some other procedure. There are not likely many, though one never
knows for sure of course. This "you are not on the mailinglist" can of
course be handled by the tool. Other side-effects, raise your voice.

*1) If you are not on the list, how else will you know what they are
talking about, thus why should you vote? ;)

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: UPDATE - mp3 audio streaming...

[Jeroen Massar]

On Wed, 2005-03-09 at 12:23 -0500, Tony Hansen wrote:
>Kudos for the mp3 streams!
>
>So far, the mp3 streams have been quite a success. From the feedback 
>I've heard, the audio quality has been mostly excellent. When combined 
>with the xmpp/jabber rooms, we have a two way communication path, and 
>several meetings I've been in have used this combination quite effectively.

The quality indeed was quit good and following the conversation was very
doable, having a backpath eg over jabber to the room would be great and
would indeed allow almost complete participation. It would be good to
have the slides of the speakers then too of course so one can also see
the slides. Add a couple of webcams and full internet conferencing ;)

It would be nice btw for the few people who have multicast available to
also make these streams available over multicast, even if it was just to
make the point that it works.

Maybe a silly idea, but what about having a meeting completely online?
Presenters pass url's to their slides, discuss in the jabber group.
Would need a +voice method, like on irc, to be able to let one person to
talk at the same time, otherwise it could turn into quite a mess ;)

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: MP3 audio streaming for IETF 62

[Jeroen Massar]

On Sun, 2005-03-06 at 19:43 -0800, Joel Jaeggli wrote:

>I look forward to more opportunities for multicast evangelism in the 
>future. I think I can speak for Hans, Lucy, myself and the rest of the 
>crew at the UO when I say we still believe that multicast holds out the 
>promise of an empowering, subversive technology for data delivery whose 
>time will come.

"Bringing the power to the people(tm)" is really the way to go.

When people can use it then they might start using it and demanding it
from their ISP's. When they don't know it exists or cannot use it
because there is nobody providing it at all, they will never figure out
how much fun it is and the possibilities it can give them.

m6bone is doing a good job at this, getting more people connected though
is the next step. I sincerely hope that ISP's would start offering
multicast connectivity. They could do it in one go together with IPv6
connectivity. There are a few ISP's doing this as a trial/experimental
service. This allows their tech folks to play with it while not
demanding too much time from them when it breaks...

just my two rapfen... ;)

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: 6BONE Help

[Jeroen Massar]

On Sat, 2004-12-18 at 20:28 -0800, Heidi Khan wrote:
> i. What is the current 6BONE setup and the way it handles IPv6 traffic
> on existing Internet architecture?
>
> ii. Over time, as confidence builds to allow production routers to
> carry native IPv6 packets, it is expected that the 6BONE would
> disappear by agreement of all parties. Is this statement true or
> false? Can u please explain?

6bone has mostly seized to exist already with many ISP's moving to RIR
space. It will be permanently and completely 

> iii. Do you see any potential in 6BONE that can attract business
> community?

This is not a technical question but one of hope and luck ;)

BTW, [EMAIL PROTECTED] is a mailinglist about the 6bone...

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Unsubscription How-To (Was: unsubscribe)

[Jeroen Massar]

On Mon, 2004-12-06 at 21:43 +1100, Vema Venkata wrote:
> Kindlyme from the list 
> would be appreicated

Before there is a long list of "I want to unsubscribe", these folks
should check the headers of the mailinglist, or better upgrade their
mailclients so that they can do it with a clickety click:

List-Id: IETF-Discussion 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,


In other words, surf to:

https://www1.ietf.org/mailman/listinfo/ietf

At the bottom you can fill in your mail address with which you
subscribed through this same interface.

As this is the IETF, the relevant RFC's:
 RFC 2919 - List-Id: A Structured Field and Namespace for
the Identification of Mailing Lists
 RFC 2369 - The Use of URLs as Meta-Syntax for Core Mail List
Commands and their Transport through Message Header Fields

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why people by NATs

[Jeroen Massar]

On Mon, 2004-11-29 at 01:38 -0500, Eric S. Raymond wrote:
> Kai Henningsen <[EMAIL PROTECTED]>:
> > Oh, sorry. Not *exactly*. It's the DHCP *server* which does the DNS  
> > update.
> 
> My DHCP server is firmware in my Linksys :-).

Which is a Linux box, which can be upgraded ;)

http://www.openwrt.org/
http://www.seattlewireless.net/index.cgi/LinksysWrt54g
etc...

8<--
dhcp client / server
  * caching dns server (with hooks to dhcp to lookup dhcp client
hostnames
-->8

Linksys WRTG's are probably one of the nicest NAT boxes, you can even
let them _route_ IPv6, including firewalling ;)
(Which reminds me to simply get one so I have a very cheap spare linux
box to fool around with, almost cheaper as buying vmware ;)

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: The gaps that NAT is filling

[Jeroen Massar]

On Fri, 2004-11-26 at 21:47 +, Greg Skinner wrote:
> On Tue, 23 Nov 2004 14:11:19 +0100, Jeroen Massar wrote:
> > On Tue, 2004-11-23 at 07:03 -0500, Margaret Wasserman wrote:
> >> Without solutions to these four problems on the horizon, I can't
> >> voice any enthusiasm that the larger address space in IPv6 will
> >> eliminate NAT in home or enterprise networks.
> 
> > This really isn't a problem of the IETF. The problems is at the ISP's   
> > who should charge for bandwidth usage and not for IP's.   
> 
> > It is all a financial problem, people earn money this way, and there is
> > not an easy way you can let them not make money. 
> > Actually, can you blame them? I can't unfortunately... 
> 
> Arguably, if the ISPs handed out a (static) IP to every customer,
> soon they'd be out of IPs, and thus unable to grow their businesses
> from that perspective.

That is such a odd argument. When an ISP runs out of IP space, they go
to their RIR and say "Hey! You! I am running out of IP space gimme a new
chunk!"

And then they get one, usually even 3 months in advance of running out.
As long as an ISP can show demand for address space they can get it.
You do need to have your network documentation in order of course and
fit some other rules, but you will get the space.

There is *no* address shortage in IPv4 (nor IPv6), see the various very
nice presentations by Geoff Huston which he gave at the RIR meetings and
other places.

On Sat, 2004-11-27 at 11:48 +0100, Leif Johansson wrote: 
> Jeroen Massar wrote:
> > On Fri, 2004-11-26 at 10:11 +0100, Leif Johansson wrote:
> > 
> >>>For somebody administering a network of 100 machines, the hassle cost of
> >>>IP renumbering would be twenty times larger.  Given this, how could
> >>>anyone wonder why NAT is popular?
> >>
> >>Wrong. If you administer 100's or 1000s of machines you build or buy
> >>a system for doing address management. Renumbering is only difficult
> >>if your system is called vi :-)
> > 
> > 
> > Wrong ;) Well at least, up to 1000 is probably doable.
> > But what if you are talking about 100s or 1000s of organizations with
> > each a 100 or 1000 machines.
> 
> My site is 10k+ addresses. Seems easy enough to manage to me :-)

And how many organizational bits and how many countries are covered
using in that address space?

I guess, that for most organizations, especially that started early,
one is plain lucky when you can even find the administrator of a certain
box, let alone the admin or carekeeper of a certain prefix when the organization
goes above around that number.

If you _can_ manage it, then you did a very good job ;)

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why people by NATs

[Jeroen Massar]

On Fri, 2004-11-26 at 10:11 +0100, Leif Johansson wrote:
> > For somebody administering a network of 100 machines, the hassle cost of
> > IP renumbering would be twenty times larger.  Given this, how could
> > anyone wonder why NAT is popular?
> 
> Wrong. If you administer 100's or 1000s of machines you build or buy
> a system for doing address management. Renumbering is only difficult
> if your system is called vi :-)

Wrong ;) Well at least, up to 1000 is probably doable.
But what if you are talking about 100s or 1000s of organizations with
each a 100 or 1000 machines.

Organization/Management and actually finding out who is doing what in
such a big environment is the problem. (Of course the people who where
'managing' this network should have seen it coming sooner or later, but
they already left of course).

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

RE: Why people by NATs

[Jeroen Massar]

On Thu, 2004-11-25 at 14:53 -0800, Michel Py wrote:
> > Jeroen Massar wrote:
> > What if you want to do VoIP from _multiple_
> > computers or even real VoIP phones.
> 
> This has never been an issue in the enterprise.

Indeed not if they are keeping the traffic local or using a proxy.
Then you don't have to circumvent NAT anyhow.



> > Or something nice as setting up a gameserver behind your NAT.
> 
> Newer game protocols work fine over NAT.

Please tell me how to setup a eg Doom III, Halflife2 server behind a NAT
and let other people on the internet connect to it.
Thus to draw a picture for you:

+-+ +-+ .--,--,--.   +-+
| Game Server |-| NAT Box |{ Internet }--| Game Client |
+-+ +-+ `-,---,--'   +-+

This maybe works if you have an uPnP compatible NAT and when above two
support uPnP, but afaik both don't support that. And please don't say
you have to do manual port forwarding on the NAT box.

End to end is not possible in the above, or an even more common
situation, because of course ISP's have "to few IPv4 addresses" and
"IPv4 addresses are expensive" thus they charge you for it, thus most
people only get 1 IP address, because there simply isn't an alternative
in most cases (ISP's should charge for traffic not IP's):

+-+  +---+   .--,--,--.   +---+  +-+
| Game Server |--| NAT_A |--{ Internet }--| NAT_B |--| Game Client |
+-+  +---+   `-,---,--'   +---+  +-+

How will this work? Open 'known ports' on each NAT box? What if you have
two brothers behind NAT_B who want to play a competition to the two
sisters running the Game Server behind NAT_A? Won't work now will it.
Or are you depending on a public server on the internet?
Guess why there are hosting companies selling "Game Server" packages and
they earn a lot of centavos with that, apparently for them it is not so
hard to get enough IP's, may they be IPv4 or IPv6.

> This where NAT sucks: game developers have to write NAT-compatible
> code. But they do: contrary to IPv6 which is optional, NAT support has
> become mandatory. No NAT support no sales. No IPv6 support nobody
> gives a rip.

Chicken and egg, you know the problem quite well.
They could easily support it, but for some reason they don't.
I actually wonder why, because it is not hard at all to do it.

For the coder folks:
http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html

> Tell me: which game would you be playing?
> 1. The game that works over IPv4 NAT.
> 2. The game that works only over IPv4 no-NAT.
> 3. The game that works only over IPv6.

Nobody demands an IPv6-only anything. Dual-stack is the keyword
everywhere in all the transition documents I have seen.

> Answer: 1. Because 2 does not exist (save for the hacked Quake done by our 
> Viagenie friends) 
> and 3 does not sell because NAT is the standard setup these days. Have
> a good frag with yourself with IPv6.

You mix up 2&3 here, but absolutely correct, when there is no chicken,
there will be no egg. Someone has to start doing it and then it will
come by itself.

> > Nevertheless, most homes currently only consist of
> > maybe 3 Ethernet segments 
> 
> Where does this come from? 99.9% of home/SOHO setups consist of _one_ 
> Ethernet segment.

Read the "maybe" part, I should have inserted a 'max' here though.

> I'm not defending NAT, but the course of action that says people will have to 
> use IPv6 because NAT is not working is flawed.

Quoting yourself from above:
> This where NAT sucks: game developers have to write NAT-compatible
> code.

I rest my case ;)

> What if I wanted to use IPv6 in Mexico while on vacation? I actually could: I 
> would have to tunnel it over IPv4 over double NAT.
> 
> - What would it buy me? Nothing. 
> - What would it cost me? Configuration time. Not too bad, but do you realize
>   know how hard it is to configure a network with the laptop on your lap,
>   a hand holding the pinacolada glass (harder than Noel's) and your eyes
>   looking at the chiquitas on the beach?

Freenet6 has had this nice automatic tunneling tool for quite some time
already. Oh and due to the many people behind NAT's it also crosses
that. And I know another effort who can do this. Not even mentioning
VPN's (IPv4 and IPv6 over NAT :) which seem to be your solution of
choice.

> - What would it buy the cybercafà owner to have IPv6?
> Nothing. First, if I needed IPv6 while traveling I would not rely on
> availability so I have my own. Second, his tunneling might be worse
> than my own (the cybercafà does not run BGP; I do).

You run BGP where? On your laptop, tunneling IPv4/IPv6 over the 

Re: Why people by NATs

[Jeroen Massar]

On Tue, 2004-11-23 at 19:02 -0500, Daniel Senie wrote:
> At 06:00 PM 11/22/2004, Fred Baker wrote:
> >At 12:10 PM 11/22/04 -0800, Chris Palmer wrote:
> >>There's another feature of NAT that is desirable that has not yet been
> >>mentioned, and which at least some customers may be cognizant of: the
> >>fact that NAT is a pretty restrictive firewall.
> >
> >would that it were true. In fact, it is pretty easy to breech. All one has 
> >to do is ddos with a the right port prefix, observe a response of any 
> >kind, and you can ddos right through it.
> 
> I take it Cisco NAT implementations are not very well implemented then.

Well, in this case I can't blame Cisco, because NAT's are simply made to
be implemented well.

> >An actual stateful firewall is a good thing. NAT mostly has the effect of 
> >deluding the person behind it into thinking they have a security solution.
> 
> Stop there. Fred, I am sure you've read or written the code to implement:
> 
> a) a stateful inspection firewall
> 
> b) a NAPT implementation (what most folks think of when they talk about NAT).
> 
> The code is NEARLY identical. In fact, the lookup tables used just need an 
> extra column to track some additional information.

That two tools both use bubblesort doesn't mean they fulfill the same
function. The same with a lookup table function.

> Please stop with the argument that NAT and stateful inspection firewalls 
> are different beasts.

They are very different. A tiger and a little pussy cat, which one do
you pet and take into your lap? Two different beast, though they look
the same...

>  The software to implement them is basically 
> identical. If you dislike NATs, say so, but this old argument about NAT 
> boxes not providing security provided by stateful inspection firewalls is 
> just not an honest one.

A NAT does not provide security as a NAT doesn't have any rules.

Also note that there is usually a _seperate_ firewall component in
common NAT boxes (and please don't call them routers as they are not)
this is the thing that gives the machine it's little bit of 'security',
not that anyone tinkers with the rules, thus keeping the box wide open.

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: The gaps that NAT is filling

[Jeroen Massar]

On Tue, 2004-11-23 at 07:03 -0500, Margaret Wasserman wrote:
> Hi All,
> 
> It will probably come as no surprise to many of you that I have spent 
> quite a bit of time over the last few years trying to understand why 
> people use NATs and how they could be replaced with more 
> architecturally harmonious mechanisms.  I have been completely 
> convinced for several years that IPv6 will not eliminate the (real or 
> perceived) need for NATs, at least not without significant follow-on 
> work from the IETF.

Did you ever think of the fact that many participants in the IETF earned
a lot of money selling:
 - NAT "solutions"
 - VPN "solutions" to overcome the NAT problem
 - Consulting in many ways
 - Services to 'merge multiple enterprise networks'
 - ...

Maybe some people do not want to solve the problem...
Remember that people still need to have food on the plate the next day.

> We won't be able to eliminate or substantially reduce the use of NAT 
> in the Internet architecture unless we come up with better ways to 
> address the problems that NAT is being used to solve, where better is 
> defined from the user's perspective not from an architectural 
> perspective.

For IPv4 you can totally forget the removal/elimination of NAT. For IPv6
there is still a chance that people are educated properly to not even
think about it.

> The average Internet user (home user or enterprise administrator) 
> does not care about the end-to-end principle or the architectural 
> purity of the Internet.

Never heard that gamer complaining that his friends could not join that
game server she setup on her computer behind that NAT box? Also any P2P
application loves end-2-end because then you don't have to use a 3rd
party host to relay the traffic. They care but they don't realize what
the problem is especially with the plethora of hacks that allow a NAT to
somewhat work like a real end to end address. The problem though is that
you have to hack around the NAT every single time. Which IMHO is more
costly than getting some extra IP's.

> These users care about ease of deployment, 
> cost and avoiding unscheduled outages (whether due to security issues 
> or ISP changes).

They only want three things:
 - that it works without problems
 - with low latency so they can aim correctly in that 3d shoot-em-up.
 - with high download speeds to get their newest movies and other warez.

>   Home users primarily care about client access to 
> the Web, and enterprise administrators primarily care about keeping 
> internal network connectivity as stable as possible.

Web? That is only a _fraction_ of the traffic they are generating. Also
web is due to the simplicity of the protocol one of the few generally
used protocols that doesn't have any problems with NAT's.
Peer-2-Peer (read: end-to-end) is what they are using it for.
MSN (and many other similar setups) for instance has this cam addon so
that you can view the others person face and chat with the other person.
Doesn't work when behind a NAT when you want to broadcast, unless you
use the many tricks (eg uPNP) to avoid the NAT.

> IMO, Internet users are primarily using NATs to solve four problems 
> that the IETF has not reasonably addressed:
>   (1) free IP address space for use on VPNs or other private networks,

The world relies on money, nothing is free. RFC1918 came nicely with the
problems that we see today with it's usage in combination with NAT's.
RFC1918 isn't bad actually, but the thing called NAT is.

For IPv6 ULA's should solve this spot quite well.

>   (2) stable provider-independent IP addressing

For global or local connectivity? Local see ULA/RFC1918. For Global this
cannot be done unless you want 128bit ASN's and 2^128 routing entries.
See HIP for instance for one of the solutions to this problem.

IP is a routing protocol, not an addressing protocol (DNS is the current
addressing protocol in that respect).

>   (3) one-way connectivity to provide protection for
>   "client-only" nodes

You mean firewalls?

Could somebody at Cisco wake up and _release_ a working version of Cisco
PIX's that support IPv6 please!? They said they had one 3 years ago by
now, currently it is 'next release'...

>   (4) zero-configuration home and small office networking.

I guess you forgot DHCP for both IPv4 and IPv6 and Router Advertisement
for IPv6.

Did you read the excellent NAP draft?
(Currently draft-vandevelde-v6ops-nap-00 soon, I understood a -01)

> Let me consider each of these problems separately:
> 
> (1) Current ISP business models are tied to IP address allocation, 
> and that will need to change to remove the economic/business 
> incentives for enterprises to limit their use of IP addresses.  There 
> might be similar changes needed to registry policies and business 
> models.  Given that there are some rather large political and 
> financial forces involved, I don't have any idea how/if these changes 
> will come about.  In the meantime, the only alternative for the IETF 
> 

Re: Why people by NATs

[Jeroen Massar]

On Tue, 2004-11-23 at 12:17 +, Tim Chown wrote:
> On Mon, Nov 22, 2004 at 05:11:26PM +0100, Jeroen Massar wrote:
> 
> > Depends on the type of home user ;)
> > Nevertheless, most homes currently only consist of maybe 3 ethernet
> > segments (wired, wireless, office or something) and maybe a max of 20
> > hosts. Changing the IP's of those hosts should not be a problem even if
> > you had to do it manually. Most of these NAT boxes come with built-in
> > DHCP support, hopefully the will come with IPv6 and RA and maybe DHCPv6
> > support too in the near future (Yamaha has them already :)
> 
> Or you just modify a Linksys router :)

Ack, nicely turn that NAT box into a real router by flashing it with a 
This is unfortunately not something that most people dare to do. Then
again, I know that quite a lot of people 'upgraded' their SpeedTouch
Home's to Pro's for somewhat the same purpose. And for that matter a lot
of people upgrade their Xboxes, PS2's etc. There is always somebody who
can do this around.

I understood there where Seasoft firmwares for above linksys's that even
have aiccu preloaded on it, so that the box can very easily build an
IPv6 tunnel in cases there is no native connectivity ;)

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why people by NATs

[Jeroen Massar]

On Mon, 2004-11-22 at 14:49 -0500, Eric S. Raymond wrote:
> Fred Baker <[EMAIL PROTECTED]>:
> > I submit that if your environment is at all like mine, you don't actually 
> > configure 192.168.whatever addresses on the equipment in your house. You 
> > run DHCP within the home and it assigns such. That being the case, you 
> > actually don't know or care what the addresses are on your equipment. You 
> > care that your SIP Proxy and etc know the relationships, and they derive 
> > them directly without your intervention.
> 
> Actually, I do set up static addresses.  I'd use DHCP, but if I did that
> I would not be able to refer to the machines on my local net by name.

I do hope that you know you can assign 'static' addresses based on MAC
address and a number of other properties that the dhcp client provides.
The dhcp server will then just assign the configured prefix. This is
actually what most ISP's use, but they will only give people one IP.

> Until my DHCP client can update my DNS tables with name information
> on the fly, I'll keep doing doing it this way.  Apple's zeroconf 
> technology solves this problem, albeit in a slightly different way,
> but Linux doesn't deploy it yet.

Even Windows can do that ;)

But so can any UNIX or basically anything where you can compile bind
utils on:

http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html

or the exact same thing but for Windows:
http://unfix.org/~jeroen/archive/Windows_DynamicDNS_Update.zip

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why people by NATs

[Jeroen Massar]

On Mon, 2004-11-22 at 15:52 +, Tim Chown wrote:
> On Mon, Nov 22, 2004 at 09:44:18AM -0500, Eric S. Raymond wrote:
> > 
> > To sum up, NAT gives me two features:
> > 
> > 1. Multiple machines on the single-address allocation the ISP gives me.
> > 2. Decoupling of mt local network addresses from the ISP assignment.
> > 
> > I hear a lot of muttering about NATs being evil.  I really don't have an
> > opinion on the subject -- I understand some of the theoretical problems,
> > but they've never bitten me.  So, asking as a network administrator,
> > how would the implied problems be solved in an IPv6 world?

The internet does not only consist of HTTP pages.

What if you want to do VoIP from _multiple_ computers or even real VoIP
phones. Or something nice as setting up a gameserver behind your NAT.
Won't work.

That many applications have a lot of tricks to circumvent NAT's, mostly
by using some external un-nat-ted server, that is sheer luck, it still
is not end to end.

> For #1, you use IPv6 globals on link for the global connections.
> 
> For #2, you could (if you wanted) use IPv6 ULAs for intra-site connectivity,
> if you didn't want to contemplate using globals and renumbering on changing 
> ISP (which is a rare events for a home user?)

Depends on the type of home user ;)
Nevertheless, most homes currently only consist of maybe 3 ethernet
segments (wired, wireless, office or something) and maybe a max of 20
hosts. Changing the IP's of those hosts should not be a problem even if
you had to do it manually. Most of these NAT boxes come with built-in
DHCP support, hopefully the will come with IPv6 and RA and maybe DHCPv6
support too in the near future (Yamaha has them already :)

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: How the IPnG effort was started

[Jeroen Massar]

On Wed, 2004-11-17 at 06:55 -0500, Noel Chiappa wrote:
> > From: Brian E Carpenter <[EMAIL PROTECTED]>
> 
> > You might explain that to the people who say they need IPv6.
> 
> OK, I'll bite.

Grawl back ;)

> Let's assume what many people now seem to concede, which is that a large part
> of the Internet is going to continue to be IPv4-only. So, what's the
> functional difference between:
> 
> - A host which has an IPv6 only address, which it cannot use (without
> "borrowing" a global IPv4 address) to comunicate directly with IPv4-only
> hosts out on the global Internet.
> 
> - A host which has an IPv4 local-only address, which it cannot use (without
> "borrowing" a global IPv4 address) to comunicate directly with other IPv4
> hosts out on the global Internet.

Difference is that the IPv6 host can actually communicate end-2-end
globally and not only in it's local network.

It is all about *global* communication, not about local communication,
you can avoid IANA completely in those cases, simply use 1.2.3.4 as an
IP at your convenience, you will have enough 32-bit space then, but you
cannot talk to your sister on vacation on japan using VoIP who you
really do not want to explain what a NAT box is and how she can get
through it with a VoIP tunnel tool or other VPN tricks.

Before you argue "but there is no IPv6 global connectivity yet", then
please check your local Abilene site, with that nice government funded
Internet2 and you will find quite a lot of activity there. Asian and
European regions are much further in deployment. Not to the doorstep of
most houses yet in Europe as they do in Korea and Japan, but with the
aid of TunnelBroker systems one can get a long way already and these are
also available on your side of the pond of course ;)

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: [IETF61] no IPv6?

[Jeroen Massar]

[off-ietf-topic]

On Mon, 2004-11-08 at 09:11 -0500, JORDI PALET MARTINEZ wrote:
> I saw this:
> 
> Ordenador-de-Jordi-Palet:~ jordi$ traceroute6 www.6power.org
> traceroute6 to www.6power.org (2001:800:40:2a03::3) from
> 2001:468:c12:128:20d:93ff:feeb:73, 30 hops max, 12 byte packets
>  1  2001:468:c12:128::4  5.709 ms  9.239 ms  7.733 ms
>  2  2001:468:c12:1::1  25.958 ms  7.548 ms  8.666 ms
>  3  2001:468:ff:185c::1  9.291 ms  6.951 ms  5.917 ms
>  4  atlang-washng.abilene.abilene.ucaid.edu  24.813 ms  30.656 ms  22.389 ms
>  5  hstnng-atlang.abilene.ucaid.edu  52.273 ms  44.055 ms *
>  6  losang-hstnng.abilene.ucaid.edu  84.828 ms  90.56 ms  74.04 ms
>  7  3ffe:8140:101:1::2  177.911 ms  187.557 ms  177.877 ms
>  8  hitachi1.otemachi.wide.ad.jp  177.499 ms  178.498 ms  179.06 ms
>  9  pc6.otemachi.wide.ad.jp  188.272 ms  188.571 ms  196.552 ms
> 10  3ffe:1800::3:2d0:b7ff:fe9a:6233  186.833 ms  187.182 ms  198.085 ms
> 11  3ffe:1800::3:230:48ff:fe41:4e95  194.045 ms  186.767 ms  186.333 ms
> 12  2001:468:ff:16c1::5  186.615 ms  194.852 ms  187.882 ms
> 13  v6-tunnel62-uk6x.ipv6.btexact.com  462.663 ms  458.041 ms  459.95 ms
> 14  2001:800:40:2e02::1  517.889 ms  512.469 ms  515.928 ms
> 15  2001:800:40:2f02::2  520.688 ms  528.601 ms  513.428 ms
> 16  ns1.euro6ix.com  532.845 ms  519.352 ms  524.852 ms

That has more to do I assume with the connectivity of the last hop,
BTExact doesn't really peer nicely with most folks and with the ones
whom they do peer it is not good... Why don't you connect this 'euro6ix'
site over a real IX? 

traceroute to ns1.euro6ix.com (2001:800:40:2a03::3) from
2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets

 1  ge-1-3-0.breda.ipv6.concepts-ict.net (2001:838:1:1::1)  0.381 ms
0.371 ms  0.352 ms
 2  at-0-0-1.schiphol-rijk.ipv6.concepts-ict.net (2001:838:0:12::1)
3.587 ms  3.626 ms  3.565 ms
 3  ge-1-0-0.nikhef.ipv6.concepts-ict.net (2001:838:0:11::1)  4.189 ms
4.142 ms  5.37 ms
 4  ge0-1-0.rtr1.ams-tc2.io.nl (2001:7f8:1::a502:4587:1)  4.424 ms  4.3
ms  4.354 ms
 5  ipv6.amsix.m20-tc2.trueserver.nl (2001:7f8:1::a501:5703:1)  4.427 ms
5.112 ms  4.298 ms
 6  2001:7f8:5::6334:2 (2001:7f8:5::6334:2)  23.915 ms  12.244 ms  12.48
ms
 7  fa-0-0.712-IPv6-omnipotent.sov.kewlio.net.uk (3ffe:4005:fefe::)
12.671 ms  13.072 ms  15.301 ms
 8  uk6x.ipv6.btexact.com (2001:7f8:2:1::1)  36.091 ms  40.891 ms  44.18
ms

 9  2001:800:40:2e02::1  87.285 ms  87.96 ms  96.02 ms
10  2001:800:40:2f02::2  97.395 ms  98.563 ms  95.548 ms
11  2001:800:40:2a03::3  89.392 ms  92.025 ms  92.528 ms

Notice the 60ms which suddenly appar between hop 8 and 9?

$ dig +trace
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.e.2.0.4.0.0.0.0.8.0.1.0.0.2.ip6.arpa

8<
0.0.8.0.1.0.0.2.ip6.arpa. 7200  IN  NS  minerva.ttd.net.
0.0.8.0.1.0.0.2.ip6.arpa. 7200  IN  NS  artemis.ttd.net.
;; Received 141 bytes from 2001:610:240:0:53::4#53(NS-SEC.RIPE.NET) in
20 ms

0.4.0.0.0.0.8.0.1.0.0.2.ip6.arpa. 172800 IN NS  dns1.portalv6.com.
;; Received 149 bytes from 213.0.184.68#53(minerva.ttd.net) in 40 ms
-->8

ns1/ns2.rcdt.net amongst others should have data for portalv6.com but it
doesn't have any, thus the resolving fails there.

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: xml2rfc and new RFC3667 requirements

[Jeroen Massar]

On Wed, 2004-07-07 at 14:34, Tim Chown wrote:
> I guess many people will use these tools already, but I thought I'd
> just post that the excellent xml2rfc tool now supports the RFC3667
> requirements as per ftp://ftp.ietf.org/ietf/1id-guidelines.txt
> 
> See http://xml.resource.org/, v1.24.
> 
> You just need to select the full3667 ipr option, e.g.
> 
>  
> In other words, you must upgrade your xml2rfc before the I-D cutoff rush
> next week :)

They are already complaining about that since monday with a 'read that
url about the new guidelines', while they might just mention that you
could turn the ipr option on to the new RFC. You can actually just set
the ipr option to 99 and xml2rfc will be compliant for ever as it
just checks if it is lower than a certain version when including some
text.

Quite odd actually, one can't send internet-drafts@ pgp-signed email
because their pegasus mua's can't read it but they do dare to complain
about some legal crap in a technical document. Submitting .xml's is not
an option either apparently, which I would think would be much easier
for them to be checked "ah they have ipr= wrong". xml2rfc could/should
warn about this btw, but then again how many times does this change.

Greets,
 Jeroen

PS: For debian users, it is not in there (yet)



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf