Re: 3G/4G Mobilt bredbånd - fremtidige forhold for IPv4 infrastrukturen ?

[Jakob Bohm]

On 3/16/2012 1:43 PM, pf wrote:
>
>
> Er der nogen her, der har kendskab til TDC's (/ Telias) aktuel og/eller
> fremadrettet IP-infrastruktur på 3G/4G nettet ?
>
>
> Jeg har inden for den seneste uge observeret, at et modem eller
> Smartphone koblet på TDC's mobile 3G/4G net aktuelt dynamisk får tildelt
> en RFC 1918 IP-adresse (IP-adresser i private address space, aktuelt
> udstukket inden for et 10/8 scope), hvor det for blot få dage siden
> dynamisk fik tildelt et public IP (offentlig IP).
>
> Det ser ud til, at der i TDC's 3G/4G net står nogle centralt placeret
> NAT devices og router trafikken ud på det globale Internet - dvs. der er
> givet en hel pøbel, der deles om det samme offentlige IP, NAT entries
> der laver timeout, blokering for extern initiering ind imod kunden osv.
>
>
> 3.dk har et par APN's, der tildeler public IP + der er åben for *extern*
> initiering af trafik ind på det tildelte public IP (APN: bredband.tre.dk
> + APN:static.tre.dk sidstnævnte giver efter en tilkøbsaftale mulighed
> for at få sig et statisk IP).
>
> Er det sådan at TDC og Telia (der også pucher et IP ud til kunden fra et
> RFC1918 scope), har andre APN's, der giver lidt mere IP-fleksibilitet
> til kunder, der på forskellig vis måske har andre behov end pøblen ?
>
> Eller skal vi til at indstille os på, at TDC og Telia fremadrettet fuldt
> satser på at lange crippled IPv4 pøbel-produkter over disken til brug på
> deres 3G/4G net ?
>
>

Godt spørgsmål!

IPv4 adresser er jo blevet en decideret mangelvare, så det er sådan set
på tide at også danske udbydere bruger løsninger der sparer på dem.

De åbne spørgsmål er så bare:

1. Får man så et offentligt IPv6 prefix samtidig, eller har de stadig
ikke taget sig sammen til at levere dette ud til slutkunden?

2. Kan man mod ekstrabetaling få en hel IPv4?

Jeg bemærkede for en måned siden at 3.dk tilsyneladende ikke kendte
noget til det tilkøbsprodukt som giver adgang til static.tre.dk,
hvilken var ret besværligt da jeg i en uge måtte bruge en 3
forbindelse som backup for en ADSL der ikke var forbundet rigtigt.

På bredband.tre.dk får man kun sin IP i 24 timer, så skifter den og
man skal omkonfigurere sit udstyr til den nye IP. Det må være for
at pushe salget af det tilkøbsprodukt de havde glemt at sætte på
prislisten.

En anden sjov krølle er at det gamle Cybercity også tilbød en
central NAT-løsning. Det var et tilkøbsprodukt og hed hacker-
smacker, men blev nedlagt af Telenor da de ikke kunne finde ud
af at holde udstyret i luften.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Jakob Bohm]

On 3/16/2012 5:03 PM, pf wrote:

>
> On 2012-03-16 16:11, Jakob Bohm wrote:
>
>> IPv4 adresser er jo blevet en decideret mangelvare, så det er sådan set
>> på tide at også danske udbydere bruger løsninger der sparer på dem.
>

> IPv4 manglen er et faktum.
>
> Det med at der skal spares på de public IPv4, det giver så nogle afledte
> problemstillinger i visse sammenhænge både for provideren og kunden -
> det sidste herunder specielt, når kunden ikke gives lov til at få hands
> on på NAT-udstyret.

>
>
>> De åbne spørgsmål er så bare:
>>
>> 1. Får man så et offentligt IPv6 prefix samtidig, eller har de stadig
>> ikke taget sig sammen til at levere dette ud til slutkunden?
>

> Ikke det jeg har set ...
>

Hmm, 3 har snakket noget meget løst om IPv4, og stort set alle
SmartPhone OS-er understøtter det (Ja, også gamle Symbian, Nokia var
meget aktiv i IPv6 arbejdet i IETF).

>
>> 2. Kan man mod ekstrabetaling få en hel IPv4?
>

> I relation til 3G/4G har jeg kun set 3.dk "mumle" noget om static public
> IP + extern initiering af trafik ind imod det tildelte - indtil videre
> nul om kundedefineret rDNS.
>
> Har ikke set det i praksis - da jeg aktuelt ikke har haft hands on på et
> 3-produkt ... men af samme ovennævnte grund overvejer at lægge billet
> ind på noget 3-net.
>
På mellem-adgangspunktet (bredband.tre.xx) virkede indgående forbindelse
fint bortset fra at port 25 var blokkeret ind/ud.

> Alternaivt er der afarter af DSL hos TDC Erhverv ... der i øvrigt har en
> fin service på både den ene og anden led.

TDC Fullrate Erhverv har heller ingen problemer med at åbne for det
hele, jeg er dog endnu ikke sikker på rDNS, det var i "Beta" sidst jeg
spurgte, så jeg besluttede at vente til det var en gennemprøvet service.

>
> Prisen er selvfølgelig så også en anden ... ;-)
>
> Men hvis Telia Erhverv (eller et andet foretagende) ville lave en
> bundlet tilkøbspakke til deres 4G projekt med Public IPv4 +
> kundedefineret rDNS + fri extern initiering ind imod det tildelte IPv4,
> så var det helt klart noget jeg ville prøve at undersøge anvendeligheden af.

>
>
>> Jeg bemærkede for en måned siden at 3.dk tilsyneladende ikke kendte
>> noget til det tilkøbsprodukt som giver adgang til static.tre.dk,
>

> =8-( )
>
> ... men hvis du siger/skriver, at 3.dk ikke engang kender deres eget
> produkt med static IP, hvordan tilkøber man det så ? ;-/
>
> Har du haft held med at tilkøbe static public IP hos 3.dk ?
>
Behovet varede kun lidt over en uge, så jeg nåede aldrig så langt som
til at kontakte dem, dengang nåede jeg kun at konstatere at jeg ikke
kunne finde det på hjemmesiden.

>
>> hvilken var ret besværligt da jeg i en uge måtte bruge en 3
>> forbindelse som backup for en ADSL der ikke var forbundet rigtigt.
>

> Jah, den sang kendes der lidt til ... omvendt bør en snu ræv jo også
> have mere end 1 ind-/udgang ;-)
>
Det her var så den anden udgang. Jeg havde også ekstra modemer (ADSL OG
3G), ekstra Sim-kort etc. klar. Et 3 Simkort og et Telenor USB 3G modem
var det mest stabile jeg lige kunne flikke sammen.

> Men når fx Telia lægger ud med "op til" 80 / 5 mbps down/up for 308,75
> danske kroner incl. et sjowt betalingsgebyr mv. og masten sidder mindre
> end 50 meter herfra ... så er det kun udelukkelse fra tilvalg af static
> public IPv4 og fri extern portinitiering + kundedefineret rDNS, der
> stækker lysten til at skrotte en gigtsvag ADSL til fordel for noget 4G
> haljø ...

4G er decideret delt båndbredde, ligesom 3G og IP over kabeltv. Jo
flere der kommer på jo langsommere bliver det nok.

>
>
> BTW: Jeg skrev til Telia Privat for nogle dage siden ang. spørgsmålet
> ... men har selvfølgelig intet hørt.
>
> Jeg prøver hos Telia Erhverv på et tidspunkt ... men der er vel ejheller
> næppe megen håb at komme efter.

>
>
>> På bredband.tre.dk får man kun sin IP i 24 timer, så skifter den og
>> man skal omkonfigurere sit udstyr til den nye IP. Det må være for
>> at pushe salget af det tilkøbsprodukt de havde glemt at sætte på
>> prislisten.
>

> Til pøbelbrug er en 24 timer lease vel også godt nok ... men til lidt
> mere seriøst brug kan der være andre behov eller i det mindste noget af
> en udfordring.

>
>
>> En anden sjov krølle er at det gamle Cybercity også tilbød en
>> central NAT-løsning. Det var et tilkøbsprodukt og hed hacker-
>> smacker, men blev nedlagt af Telenor da de ikke kunne finde ud
>> af at holde udstyret i luften.
>

> Det er vel rene pøbelprodukter man som IAP går efter at udbyde ... og så
> længe Moster Maren i Kæret ikke efterspørger andet end at kunne gå på
> Netbank en fredag eftermiddag, så er det givet fint nok med noget
> NAT-sjow af RFC 1918 adresser - og det bliver vel næppe anderledes fremover.
>
Hacker-Smacker var et tilkøbsprodukt for Maren i Kæret, hvor man fik
en adresse bag en virus-tjekkende proxy, en mailserver med virus-tjek,
masser af lukkede porte o.s.v. Det var Cybercity's OS-uafhængige
alternativ til at bundle en halvdårlig windows-sikkerhedspakke til Maren
i Kæret. Det eneste der skulle gøres hos kunden var at skifte
et par felter i logindialogerne.

Problemet var at de i det sidste årstid hvor det "kørte" havde
deciderede oppetidsproblemer på det centrale udstyr.

>
> Måske man skulle til at overveje noget VPN imod en tunnel router et
> eller andet sted ... :-/ men det vil selvf. øge både bøvlet, round trip
> og ustabiliteten en kende.

[Sonny T. Larsen]

On Fri, 16 Mar 2012 13:43:24 +0100, pf wrote:

> Er der nogen her, der har kendskab til TDC's (/ Telias) aktuel og/eller
> fremadrettet IP-infrastruktur på 3G/4G nettet ?

Ah, mon ikke der er.

> Jeg har inden for den seneste uge observeret, at et modem eller
> Smartphone koblet på TDC's mobile 3G/4G net aktuelt dynamisk får tildelt
> en RFC 1918 IP-adresse (IP-adresser i private address space, aktuelt
> udstukket inden for et 10/8 scope), hvor det for blot få dage siden
> dynamisk fik tildelt et public IP (offentlig IP).

Der er skiftet til RFC1918-IP og NAT på internet-APN'et, ja.

> Det ser ud til, at der i TDC's 3G/4G net står nogle centralt placeret
> NAT devices og router trafikken ud på det globale Internet - dvs. der er
> givet en hel pøbel, der deles om det samme offentlige IP, NAT entries
> der laver timeout, blokering for extern initiering ind imod kunden osv.

Der står er par firewalls og laver NAT.

> Er det sådan at TDC og Telia (der også pucher et IP ud til kunden fra et
> RFC1918 scope), har andre APN's, der giver lidt mere IP-fleksibilitet
> til kunder, der på forskellig vis måske har andre behov end pøblen ?

Der kan købes adgang til eget APN, mener produktet kaldes secure mobil.

--
/Sonny - #include <std.disclaimer.h>

"I don't have an attitude problem, you have a perception problem."

[Sonny T. Larsen]

On Fri, 16 Mar 2012 20:44:52 +0100, pf wrote:

> Så er vores observationer jo bekræftet :-)

Ja.

> Det gamle setup med public IP ned til clienten synes også at være hægtet
> på en firewall idet extern initiering ind imod clienten ikke var mulig.

En anden firewall, ja - der var dog et "whitelist"-produkt, der tillod
trafik initieret udefra.

> Men med det nye setup er der ikke mere at komme efter der ...

Jeg kender ikke fremtiden for whitelist-produktet; formoder den umiddelbare
afløser er secure mobil.

> Det er så ikke lige det der efterspørges - men blot fuld public access
> med mulighed for rDNS som vi kender det fra xDLS (erhvervs) produkterne :-)

Jeg tror ganske ærligt ikke, at efterspørgslen er ret stor.

[Sonny T. Larsen]

On Sat, 17 Mar 2012 00:33:24 +0100, pf wrote:

> Kan du sige noget om hvilke 10-subnets, man anvender @ TDC ?

Det meste af 10/8 ser på rundhåndet vis ud til at være i brug :-)


Der er et hul omkring 10.64.0.0/11, der ikke bruges - men det kan jo ændres
uden videre.

> Det kræver selvfølgelig også, at man ved hvad man efterspørger ... men
> ærgeligt er det da.

Korrekt - whitelist-produktet lever sådan set stadig, men hvor længe aner
jeg ikke.

Kan være, det har relevans for din brug af mobil bredbånd.

[Christian Laursen]

On 03/17/12 01:44, Sonny T. Larsen wrote:
> On Sat, 17 Mar 2012 00:33:24 +0100, pf wrote:
>
>> Kan du sige noget om hvilke 10-subnets, man anvender @ TDC ?
>
> Det meste af 10/8 ser på rundhåndet vis ud til at være i brug :-)
>
>
> Der er et hul omkring 10.64.0.0/11, der ikke bruges - men det kan jo ændres
> uden videre.

Bliver det ikke muligt at anvende 100.64.0.0/10 på ISP-siden ganske snart?

> http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/

--
Christian Laursen

[Jakob Bohm]

On 3/16/2012 8:32 PM, pf wrote:

>
> On 2012-03-16 18:27, Jakob Bohm wrote:
>
>> På mellem-adgangspunktet (bredband.tre.xx) virkede indgående forbindelse
>> fint bortset fra at port 25 var blokkeret ind/ud.
>

> Det er vel nærmest klassisk, at IAP'en er port 25/TCP paranoid, fordi
> der har siddet et hav af klovne og leget open relay eller dyrket
> PC-virus på dåsen, der har kunnet det samme - det er vel så OK med lidt
> paranoia her, når vi taler om dynamic uddelt IP's til pøblen (IMHO).
>
Enig, det var blot en konstatering. Det blev klaret med en alternativ
MX/SmartHost.

>
>>> Alternaivt er der afarter af DSL hos TDC Erhverv ... der i øvrigt har en
>>> fin service på både den ene og anden led.
>>
>> TDC Fullrate Erhverv har heller ingen problemer med at åbne for det
>> hele, jeg er dog endnu ikke sikker på rDNS, det var i "Beta" sidst jeg
>> spurgte, så jeg besluttede at vente til det var en gennemprøvet service.
>

> Hos TDC mailer man bare ind til Hostmaster og så er det på plads, næsten
> hurtigere end man kan nå at lave et lookup ...
>
Det ville være ligeså hurtigt at få hos Fullrate, men der var bare et
beta-forbehold da jeg spurgte tilbage i 2010.

> Men vi så jo gerne, at der kom noget lysleder ud til slutbrugeren frem
> for det xDSL sjow på gamle irrede kabler med både lyn og vand i, der jo
> har deres hastighedsbegrænsninger (mit modem m. router i bridge mode har
> lyst kraftig violet op et gange med tilhørende smæld, ligesom jordkablet
> har måtte repareres pga. lynnedslag i nearby metalvejskilte / elmaster
> med overslag i kablet til følge).

Tjah, vi er ret tæt på en anden fiber her, forhandler p.t. med
leverandør om betingelser m.m.

>
> Waoooooooooooooooooooooo har lige nu et tilbud på 40/40 til 199 kroner
> pr. måned - men de har skam ikke tænkt sig at komme forbi matriklen,
> endsige gidet trække tomrør, når der har været mulighed for at samgrave
> (har haft fat i dem, da vejen og fortov var næsten totalt opgravet ifm
> noget kloakering ... SofaNet kunne i øvrigt fint lægge både lysleder
> (til internt brug) og coax ned, når nu fortovet var pløjet op) :-(
>

Nu er det ikke Waoo der lægger kabler ned, de lejer dem hos Dongs
fiberudlejningsselskab som graver ned efter en masterplan som synkront
følger udskiftningen af alle luftledninger med nedgravede kabler. De
har muligvis ingen aktuelle planer om fiber der hvor strømmen allerede
var nedgravet før December-orkanen.

Oprindelig var det meningen at det var de almindelige ISP-er (bl.a.
Cybercity) der skulle leje sig ind på fibernettet, så DONG m.fl. slet
ikke skulle beskæftige sig med ISP-drift, bare grave kablerne ned og
installere nogle switche (100Mbit switche hos slutbrugerne, kaldet
"fiberboks" og uspecificerede fiber til fiber switche i lokale samleskabe).

Waoo blev oprettet som en nødløsning da ISPerne faldt fra.

>
>> Det her var så den anden udgang. Jeg havde også ekstra modemer (ADSL OG
>> 3G), ekstra Sim-kort etc. klar. Et 3 Simkort og et Telenor USB 3G modem
>> var det mest stabile jeg lige kunne flikke sammen.
>

> Til pøbelbrug er det også ganske udmærket - faktisk er hastigheden og
> stabiliteten ikke så ringe endda.
>
>
> Jeg sidder for tiden og fedter med et par Dovado Tiny routers og lidt
> spredt fægtning med diverse modems.
>
> http://www.dovado.com/tiny/
>
> Det spiller glimragende efter forholdene på 3G og 4G.
>
> En lille demo af dåsen: http://www.youtube.com/watch?v=gNRFBfPOl4w
>

Sød lille dåse. Men er single-channel 802.11n ikke lidt svageligt til
at videreformidle 70Mbit? Når man trækker typisk afstandssvækkelse af
WiFi fra kan de 150Mbit nominelt let blive flaskehalsen selv hvis der
ikke er lokal trafik mellem LAN og WLAN. Til den slags ville jeg
foretrække dual-channel 802.11n (ikke draft) på 5GHz båndet.

>
>> 4G er decideret delt båndbredde, ligesom 3G og IP over kabeltv. Jo
>> flere der kommer på jo langsommere bliver det nok.
>

> Det er rigtig - omvendt spiller 3G slet ikke så ringe hastighedsmæssig
> ift. min gigtsvage ADSL ... så der skal nok meget bruger trafik til at
> gøre det ret meget ringere.
>

Kommer an på dækning. Her fik vi 1-2 Mbit på 3G mod ca. 5 Mbit på xDSL.
Muligvis grundet dårlige radioforhold i server-rummet.

> Tilgengæld har 3G/4G produkterne en max data limit, hvor xDSL typiske er
> flatrate.
>
>

Det kan man heldigvis betale sig fra hvis behovet opstår igen.

[Michael Kjærsgård]

> Er der nogen her, der har kendskab til TDC's (/ Telias) aktuel og/eller
> fremadrettet IP-infrastruktur på 3G/4G nettet ?

Ikke lige disse 2, men som du kan læse på
http://www.telenor.dk/privat/kundeservice/kundeservice/mobil/daekning/bedre-daekning/index.aspx
kan du fra "sommeren 2012" også få 4G på Telenors net.

Som udgangspunkt tildeles du som mobilt bredbånds kunde hos Telenor en
offentlig IP ala den model du beskrev TDC hidtil har kørt efter (bag en
firewall der kun tillader trafik initieret fra klienten).

Mod en merbetaling på 5 kr./mnd. kan du slippe for denne firewall og få en
IP der kan tilgåes udefra.

--
Michael Kjærsgård
//Gratis billedhosting: http://imageshack.dk
//Gratis webhosting: http://gratishotel.dk

[Michael Kjærsgård]

> Under forudsætning af at kunden kan tilkøbe *static* public IPv4 med
> tilhørende brugerdefineret rDNS og der er fri extern initiering ind imod
> den tildelte IP, så er det måske hos TeleNor, vi skal overveje at lægge
> vores indkøb af 4G opkoblinger ...

Det er ikke statiske IP-adresser, desværre, og dermed heller ikke mulighed
for reverse DNS. Er dette behovet er vi ude i noget specialkonfigureret
erhvervsløsning, og så kan merprisen ikke holdes på en 5'er/mnd. ;-)

[Leif Neland]

Jeg har 3, browser jeg til ip6.me, ser jeg at jeg har adressen
94.191.185.31, og ingen ipv6-adresse.

Men sshdroid på android giver telefonen adressen 10.198.183.xxx

Dog er jeg i tvivl om 3 giver ipv6-adgang, for heller ikke via mit lan,
der har ægte ipv6-adresser, ser jeg en ipv6-adresse i mobilens browser.

Men ellers, så er der vel ikke andet end at punke udbyderne om at få ipv6.

En programleverandør sagde til mig at de ventede med ipv6 til det var
"mature".

Hvortil jeg svarede: Well, it's 18 years old, in my country that's old
enough to vote, so how old should it be?

:-)

Leif

[Jakob Bohm]

On 3/20/2012 12:17 AM, pf wrote:

>
>
> On 2012-03-19 22:22, Michael Kjærsgård wrote:
>
>>> Under forudsætning af at kunden kan tilkøbe *static* public IPv4 med
>>> tilhørende brugerdefineret rDNS og der er fri extern initiering ind imod
>>> den tildelte IP, så er det måske hos TeleNor, vi skal overveje at lægge
>>> vores indkøb af 4G opkoblinger ...
>>
>> Det er ikke statiske IP-adresser, desværre, og dermed heller ikke mulighed
>> for reverse DNS. Er dette behovet er vi ude i noget specialkonfigureret
>> erhvervsløsning, og så kan merprisen ikke holdes på en 5'er/mnd. ;-)
>

> Nu er det ikke raketvidenskab at tildele et - lad os så bare i relation
> til alm. praksis blive i DHCP verdenen - static lease og at indsætte et
> bruger defineret FQDN ind i en PTR RR kontekst og lade DNS serveren lave
> auto reload af data fx hver 24 time.
>
>
> Hvis man kan tage imod en bestilling på IP access fra kunden, kan man
> principielt også lige se efter at feltet for ønsket rDNS ikke er helt
> hen i vejret, inden man banker kundens data ind i kunde-databasen ...
>

Den bedste og billigste test i et sådant system er at lave en forward
lookup på det ansøgte rDNS navn og kun acceptere hvis det eneste svar
for adressetypen (A for IPv4 rDNS, AAAA for IPv6 rDNS) giver den
pågældende IP adresse. En gang i døgnet ophæves rDNS som ikke længere
opfylder testen. Det hele kan køre fuldautomatisk med en simpel form
til angivelse af ønsket rDNS plus kundepassword (sidstnævnte for at
forhindre at viruser sætter rDNS op for et spam-botnet).

> Problemet ligger muligvis nærmere i, at interessen for at udbyde
> "pakken" ikke er der (da det givet ikke er et mainstream behov) og at
> administrations-systemerne måske derfor ikke grundlæggende er designet,
> så det er ligetil at gøre det.
>
> Omvendt *kan* kunden som nødløsning anvende en service, der får et
> givent FQDN til at pege på et tildelt dynamic IP.
>
>
> For rigtig mange år siden, da mange af os sad og fedtede med dial up
> over analog og senere ISDN, fik vi efterhånden, som det fænomen blev
> mere udbredt, typisk smidt et dynamic IP i nakken under connect.
>
> Sammen med en portugiser og en tysker designede vi sammen derfor et godt
> hack, der lavede det stunt at knytte et FQDN og et dynamic IP sammen ...
> servicen lever indnu - også som Debian-pakke :-)
>
> Men, men, men ... til seriøs brug gider man formodentlig ikke sidde og
> fedte ret meget med sådan noget i dag ... og det løser heller ikke rDNS
> udfordringen.
>

Findes stadig hos mange DNS udbydere. Bl.a. danske gratisdns.dk
tilbyder at man (gratis) kan sætte denne opførsel på et eller flere
navne under ens eget domæne.


> Dovado Tiny'en har noget tilsvarende indbygget med DynDNS.com og
> tilsvarende venner ... så ja, meget kan lade sig hacke til i en hurtig
> vending, men specielt kønt er det IMHO ikke ... ;-)
>
>

De fleste low-cost routere har i dag funktionen, man skal stort set
bare angive sin DNS-udbyder og password til samme. Alternativt kan
man bare køre klientscriptet på en tilfældig maskine bag ens NAT-boks,
så finder det selv ud af public IP. Men hvis man kører bag en ISP NAT
så får man pludselig peget DNS-navnet på ISP-ens public IP.

[Klaus Ellegaard]

pf <p...@fabel.dk.RE.MOVE.INVALID> writes:

>For jeg ser jævnlig fx små håndværkerfirmaer, der har købet en erhvervs
>IP-access og formodentlig lader mesters søn eller fætter opsætte en MTA
>til virksomhedens brug på linien.

Mon ikke de er bedre tjent med GMail?

Mvh.
Klaus.

[Jakob Bohm]

On 3/21/2012 1:38 PM, pf wrote:

>
> On 2012-03-20 08:51, Leif Neland wrote:
>
>> Jeg har 3, browser jeg til ip6.me, ser jeg at jeg har adressen
>> 94.191.185.31, og ingen ipv6-adresse.
>>
>> Men sshdroid på android giver telefonen adressen 10.198.183.xxx
>

> Hum, den public IP kommer fra en: 3 Customer dynamic address pool.
>
> Så når du ser et RFC1918 IP på din Android, så /kunne/ det tyde på, at
> der kunne være noget 1-1 NAT i spil.
>
> BTW: Har du fx Quick System Info (prof. udgaven er AD supported, eller
> du skal til muldvarpeskindet) på Android dimsen, så kan den give dig
> mange gode informationer :-)
>
> ConnectBot kan også bruges til SSH på droid dimsen.

>
>
>> Dog er jeg i tvivl om 3 giver ipv6-adgang, for heller ikke via mit lan,
>> der har ægte ipv6-adresser, ser jeg en ipv6-adresse i mobilens browser.
>>
>> Men ellers, så er der vel ikke andet end at punke udbyderne om at få ipv6.
>

> @ TDC Erhverv kan man AFAIK få IPv6 :-)
>
> Alternativt kan man evt. tage et net ind fra en tunnel broker.
>
>
> BTW: Når IPv6 så skal tunneles igennem en NAT gateway, så opstår der vel
> nye udfordringer.
>
>
> Er der nogen der ved noget om hvilken TIMEOUT der er i TDC's MOBILE-NAT
> dåser ?
>
> Der skal givet noget keep alive til at holde fx en tunnel oppe på samme
> vis som med andre piercinger med 2-vejs trafik initiering ...

SIXXS (www.sixxs.net) tunneller af type AIYIA kan bryde igennem det
meste. De laver hyppige keep-alive pakker og kører fint igennem normale
nat-bokse (bortset fra dem med ZyXEL ZyNOS, hvor NAT tabellen løber fuld
og kun kan reddes med en reboot).

>
> Alternativt må man forsøge sig lidt frem :-/

>
>
>> En programleverandør sagde til mig at de ventede med ipv6 til det var
>> "mature".
>>
>> Hvortil jeg svarede: Well, it's 18 years old, in my country that's old
>> enough to vote, so how old should it be?
>

> Det kan man selvfølgelig spørge om ... :-)
>
>

Tjah, vi har da lagt IPv6 i vores produkter for flere år siden, og jeg
har lige forbedret den del af koden yderligere, med flere forbedringer
planlagt.

[Jakob Bohm]

On 3/21/2012 1:06 PM, pf wrote:

>
> On 2012-03-20 15:20, Jakob Bohm wrote:
>
>>> Hvis man kan tage imod en bestilling på IP access fra kunden, kan man
>>> principielt også lige se efter at feltet for ønsket rDNS ikke er helt
>>> hen i vejret, inden man banker kundens data ind i kunde-databasen ...
>>>
>>
>> Den bedste og billigste test i et sådant system er at lave en forward
>> lookup på det ansøgte rDNS navn og kun acceptere hvis det eneste svar
>> for adressetypen (A for IPv4 rDNS, AAAA for IPv6 rDNS) giver den
>> pågældende IP adresse. En gang i døgnet ophæves rDNS som ikke længere
>> opfylder testen. Det hele kan køre fuldautomatisk med en simpel form
>> til angivelse af ønsket rDNS plus kundepassword (sidstnævnte for at
>> forhindre at viruser sætter rDNS op for et spam-botnet).
>

> Det kunne være en måde ...
>
> Omvendt kommer tiltaget næppe til mainstream produkter til Hr.& Fru
> Danmark.
>
> På erhvervs produkter kunne man måske godt hos IAP'en se et behov og
> derfor træffe en beslutning - omvendt er efterspørgselen fra det
> kundesegment måske heller ikke markant nok ?

>
> For jeg ser jævnlig fx små håndværkerfirmaer, der har købet en erhvervs
> IP-access og formodentlig lader mesters søn eller fætter opsætte en MTA
> til virksomhedens brug på linien.
>

> Det scenario kommer der typisk meget sjowt ud af, herunder ofte et
> generic rDNS ala.:
>
> 0x50c49dd4.cpe.ge-0-1-0-1105.locateX.customer.udbyder.TLD
>
> Og en MTA der præsenteres sig typisk som: MegetFintFirma.local ligesom
> PostM...@MegetFintFirma.TLD heller ikke virker = bounce med fx: No
> Mailbox by that Name ... :-)
>
> Så kan man jo evt. overveje, hvorvidt firmaets kernekompetence befinder
> sig på samme niveau - for det er forhåbentlig ikke en hyret professionel
> konsulent, der har efterladt sådan et scenario.
>

Tjah, som prof har jeg *næsten* lavet den opsætning, dog er HELO name
sat til udbyderens rDNS streng og PostMaster er selvfølgelig en rigtig
mailboks, ligesom de fleste af de andre standard-navne fra den relevante
RFC.

Men mailsystemernes DNS-krav er faktisk efterhånden så kringlede at selv
højkvalitets DNS-tests ikke tjekker alle reglerne.

Selv glemte jeg på et tidspunkt at ændre SPF for rDNS for en af de
servere der var opremset i min primære SPF.

>
> BTW: Jeg synes egentlig bestilling af et kundedefineret rDNS, virker
> meget godt hos fx TDC - man mailer blot til HostMaster og så er rDNS'et
> på plads, hvorefter man ikke behøver at pille mere ved den side af
> sagen, selvfølgelig medmindre der opstår nye behov som tiden går ...
>

Jep, ditto hos Telia. Men jeg har set tilfælde hos mere end en udbyder
hvor en custom RDNS ikke blev slettet igen i tide, derfor mit forslag om
en simpel automatisk test, som både sikrer korrekt opsætning OG checker
om der bestilles et DNS-navn kunden ikke har ret til.

>
>>> Men, men, men ... til seriøs brug gider man formodentlig ikke sidde og
>>> fedte ret meget med sådan noget i dag ... og det løser heller ikke rDNS
>>> udfordringen.
>>>
>>
>> Findes stadig hos mange DNS udbydere. Bl.a. danske gratisdns.dk
>> tilbyder at man (gratis) kan sætte denne opførsel på et eller flere
>> navne under ens eget domæne.
>

> OK - GratisDNS er vist i øvrigt et meget godt projekt.
>
> Én af de gode ting jeg lige kan se, det er at deres service er designet
> meget robust imod udfald af en enkelt eller flere DNS'er, sikret ved
> mere end 2 servers og at de i øvrigt er netværksmæssigt og fysisk godt
> fordelt.
>

Tjah, de hævder at være den største eller næststørste danske udbyder, og
de undskyldte pænt da deres kontrolpanel og DynDNS update-url (men ikke
den redundante DNS) blev slået ud af InterXion brænden får nogle år
siden.

>
>> De fleste low-cost routere har i dag funktionen, man skal stort set
>> bare angive sin DNS-udbyder og password til samme. Alternativt kan
>> man bare køre klientscriptet på en tilfældig maskine bag ens NAT-boks,
>> så finder det selv ud af public IP. Men hvis man kører bag en ISP NAT
>> så får man pludselig peget DNS-navnet på ISP-ens public IP.
>

> Og det sidste er næppe det mest morsomme ... 8-(
>
>
> Det ser ud til at fx TDC anvender
>
> inetnum: 80.62.116.0 - 80.62.117.255
> netname: TDCMOBILE-NAT
>
> ... og en /23 giver 510 mulige NAT hosts skulle behovet opstå.
>
> Så mon ikke det strækker til det meste NAT haløj fra de kanter ?
>

Eller også er det for at få porte nok. Simpel NAT (det Cisco kalder
PAT) Fordeler jo poolen af portnumre fra 1024 til 65535 til de faktiske
forbindelser fra kunderne, så med tusindvis af kunder er der brug for
mere end 1 IPv4 for at få porte nok.

> Eller kan vi mon umiddelbart frmover forvente at se andre IP adresser
> anvendt til TDCMOBILE-NAT ?
>
>

Kommer vel an på den faktiske belastning.

[Jakob Bohm]

On 3/21/2012 4:33 PM, pf wrote:

>
> On 2012-03-21 14:58, Jakob Bohm wrote:
>
>>> For jeg ser jævnlig fx små håndværkerfirmaer, der har købet en erhvervs
>>> IP-access og formodentlig lader mesters søn eller fætter opsætte en MTA
>>> til virksomhedens brug på linien.
>>>
>>> Det scenario kommer der typisk meget sjowt ud af, herunder ofte et
>>> generic rDNS ala.:
>>>
>>> 0x50c49dd4.cpe.ge-0-1-0-1105.locateX.customer.udbyder.TLD
>>>
>>> Og en MTA der præsenteres sig typisk som: MegetFintFirma.local ligesom
>>> PostM...@MegetFintFirma.TLD heller ikke virker = bounce med fx: No
>>> Mailbox by that Name ... :-)
>>>
>>> Så kan man jo evt. overveje, hvorvidt firmaets kernekompetence befinder
>>> sig på samme niveau - for det er forhåbentlig ikke en hyret professionel
>>> konsulent, der har efterladt sådan et scenario.
>>>
>>
>> Tjah, som prof har jeg *næsten* lavet den opsætning, dog er HELO name
>> sat til udbyderens rDNS streng og PostMaster er selvfølgelig en rigtig
>> mailboks, ligesom de fleste af de andre standard-navne fra den relevante
>> RFC.
>

> Det er så også en tilsnigelse at skrive: næsten, når du nu nu ved hvad
> en RFC er for en sjower, frem for bare at lukke øjnene, daske lidt til
> dåsen og håbe det bedste ;-)
>
Næsten betyder tilsnigelse...
>
> RFC 5321 har et lille afsnit 2.3.5. om Domain Names ... det er da et
> udgangspunkt.
>

Jah, det er jo den nye udgave

> Ligesom samme RFC i slutningen af samme afsnit 2.3.5. siger noget om den
> der sjowe "PostMaster" mailbox :-)
>

Jep

>
>> Men mailsystemernes DNS-krav er faktisk efterhånden så kringlede at selv
>> højkvalitets DNS-tests ikke tjekker alle reglerne.
>

> Meget snavs kan jo holdes ude, hvis rDNS resolver til det MTA'en mener
> den hedder, når den snakker HELO/EHLO og at det ikke er noget generic
> customer rDNS ala fx:
>
> 1-2-3-4-dynamic-ip.example.com | 1-2-3-4-static-ip.example.com
>
>
> Mener MTA'en den hedder: MegetFintFirma.TLD vil det nok være en idé at
> sætte rDNS til det samme ... og leveres IP igennem en CPE NAT-dåse vil
> det stadig være fornuftig at have et fornuftig rDNS på den public IP.
>

Og hvis ISP-ens rDNS ikke er helt pålidelig (den var som sagt officielt
i Beta dengang) så er det oplagte alternativ at fortælle MTA-en at den
i relevante situationer hedder 1-2-3-4-static-ip.example.net

>
>> Selv glemte jeg på et tidspunkt at ændre SPF for rDNS for en af de
>> servere der var opremset i min primære SPF.
>

> SPF og mail FORWARD er ikke de bedste venner ... så nogen kan komme til
> at mangle en legitim email eller to på den konto ;-/
>
Normal mail forward udført på MUA-niveau eller af mailinglister har
intet problem med SPF, da envelope From her ændres. Det er kun
mail-hosting-as-forwarding-engine opsætninger som kopierer envelope
from, og vi har p.t. kun en af disse i indgående modus, så den har
vi simpelthen whitelistet med hensyn til indadgående SPF-checks.

Hvis en postmodtager laver sådan en opsætning og alligevel checker
SPF på messages fra sin egen forward-udbyder, så er det ris til egen
...

Den obskure regel som ikke blev checket af zone-checkerne er at HELO
navnet både skal være eneste rDNS for udgående MTA (udbredt paranoia-
check) OG at at rDNS navnet skal have en SPF record som tillader at
MTA-en sender mail FRA postm...@rDNS.example, selvom den er sat op
til aldrig at gøre sidstnævnte. Derfor skal alle IP adresser tilladt
i en SPF-record have gyldig rDNS som opfylder denne regel.

>
>
>>> BTW: Jeg synes egentlig bestilling af et kundedefineret rDNS, virker
>>> meget godt hos fx TDC - man mailer blot til HostMaster og så er rDNS'et
>>> på plads, hvorefter man ikke behøver at pille mere ved den side af
>>> sagen, selvfølgelig medmindre der opstår nye behov som tiden går ...
>>>
>>
>> Jep, ditto hos Telia. Men jeg har set tilfælde hos mere end en udbyder
>> hvor en custom RDNS ikke blev slettet igen i tide, derfor mit forslag om
>> en simpel automatisk test, som både sikrer korrekt opsætning OG checker
>> om der bestilles et DNS-navn kunden ikke har ret til.
>

> Det er selvfølgelig ikke hensigtsmæssig, at der ikke bliver ryddet op og
> i den kontekst er dit oplæg selvfølgelig interessant.

>
>
>>> Én af de gode ting jeg lige kan se, det er at deres service er designet
>>> meget robust imod udfald af en enkelt eller flere DNS'er, sikret ved
>>> mere end 2 servers og at de i øvrigt er netværksmæssigt og fysisk godt
>>> fordelt.
>>>
>>
>> Tjah, de hævder at være den største eller næststørste danske udbyder, og
>> de undskyldte pænt da deres kontrolpanel og DynDNS update-url (men ikke
>> den redundante DNS) blev slået ud af InterXion brænden får nogle år
>> siden.
>

> NS1 er masteren i et GratisDNS scenario - såfremt brugeren ikke selv
> kører master - og futter et hostingcenter af vil der selvfølgelig lige
> være lidt ventetid, hvor ændringer via web-kontrolpanelet må stå lidt på
> hold.
>
> Zone transfer / AXFR fra evt. egen master foregår fra AXFR.GratisDNS.dk
> ... så himler AXFR dåsen samtidig med NS1 hænger opdateringer på masteren.
>
Jeg er lidt usikker på om det i virkeligheden er ns1 eller en skjult
maskine som er master. Men da både ændringer af gdns-som-master og
skift til brug af axfr.gratisdns.dk styres via det samme kontrolpanel
ryger begge muligheder for gdns-som-master kunder hvis kontrolpanelet
går ned.

> Men udfald af NS1 + AXFR + kontrolpanel har så kun konsekvens for de der
> under udfaldet ønsker at foretage - evt. vitale - opdateringer i
> venteperioden.
>
> Men måske har Gratis Peter& Co lavet noget quick fall-over efter den
> oplevelse ...
>
Tjah, de specificerer da stadig kun en enkelt IP-blok som man skal
tillade som AXFR-klient, så failover af axfr vil have svært ved at
gå til et andet datacenter.

[Leif Neland]

Den 21-03-2012 16:44, pf skrev:

> SixXS tilbyder 3 tunnel typer:
>
> static tunnels
> heartbeat tunnels
> AYIYA tunnels
>

Jeps; jeg har en static på arb, selvom det er en tdcerhverv, har jeg
ikke lige fået det sat op til native.
Og en ayiya gennem en nat hjemme.

Leif

[Christian Laursen]

On 03/23/12 23:04, pf wrote:

> BTW: Jeg kan se, at der er mindst én stor danske udbyder, der har to
> NS'er til at stå og lege rDNS'er for nogle af deres IP's ... og de to
> NS'er ligger IP-mæssig *meget* tæt på hinanden (på samme subnet).
>
> Så ryger forbindelsen af den ene eller anden grund til det net, så er
> der ingen opslag, der returnerer noget fornuftig ...

Der er ingen regler om at IP-adresser der ligger helt op ad hinanden
nødvendigvis befinder sig samme sted. Man kan snildt route fx. 2 på
hinanden følgende /32'ere til hver sin ende af landet fx.

--
Christian Laursen

[Sonny T. Larsen]

On Sat, 24 Mar 2012 17:29:21 +0100, pf wrote:

> Konklusivt kan man umiddelbart sige (IMHO), at der skal nogle specielle
> ønsker og krumspring til for at route en /32 IPv4 - frem for blot at
> tildele en secondary NS en IPv4 i en helt anden netblock ...

Njaeh, det kunne jo også være, at den /32 blot er en adresse, der hører
hjemme på f.eks en loadbalancer (som VIP-adresse).

I så fald vil det give god mening, og den aggregerede route er måske en
/13 eller lignende, så der er ikke mere single point of failure i det,
end der vil være, hvis jeg havde valgt en anden IP.

Vi router masser af /32 i AS3292, f.eks adresser brugt på loopbackinterfaces.

At adresserne for f.eks ns3.tele.dk og ns3.inet.tele.dk ikke er /32'ere, er
rent historisk.

Jeg tror Christians pointe var, at du ikke kan konkludere noget ud fra
adresserne, men blot gætte.

[Jakob Bohm]

On 3/25/2012 9:34 PM, pf wrote:

>
> On 2012-03-25 01:31, Sonny T. Larsen wrote:
>
>> Njaeh, det kunne jo også være, at den /32 blot er en adresse, der hører
>> hjemme på f.eks en loadbalancer (som VIP-adresse).
>

> Jow-jow selvfølgelig.

>
>
>> I så fald vil det give god mening, og den aggregerede route er måske en
>> /13 eller lignende, så der er ikke mere single point of failure i det,
>> end der vil være, hvis jeg havde valgt en anden IP.
>

> ... i egen IP pulje.

>
>
>> Jeg tror Christians pointe var, at du ikke kan konkludere noget ud fra
>> adresserne, men blot gætte.
>

> Ja, jeg gætter ... ;-) da jeg ikke har aktuel kendskab - her til TDC's -
> interne netsetup ... det var nu heller ikke TDC jeg havde i kikkerten,
> uden at det gør det principielle i diskussionen anderledes ...
>
>
> Omvendt var min pointe blot, at fejler tilgangen - hvad så end årsagen
> er - til to internt placerede NS'er, der som de eneste kører en given
> zone, så er det ikke ret nemt at slå noget op i zonen ...
>
> Og ja, en /13 er en hel pæn slat adresser at route på, selv om jeg
> tænker i har flere. Men selv om man har samlet mange adresser under sin
> hat, tænker jeg, at man principielt godt kan smide én eller flere ekstra
> NS'er på en IP helt uden for eget IP scope, for at gøre redundansen bedre.
>
>
> Ift. Jacobs oprindelige konstatering af at rDNS opslag hos en udbyder
> ustabilt ikke viste det kunden havde ønsket indsat, er det mest
> indlysende enten fejl i record'en eller tilgangen til den rette
> information ... hvad end årsagen i begge tilfælde måtte være.
>
> Men er det administrationssystemet der inducerer fejl, hjælper det
> naturligvis ikke med god DNS-redundans.
>
> Hvis man omvendt over tid får varierende svar som enten 1) kundeønsket
> eller 2) et generic rDNS kunne årsagen måske skyldes, at NS'erne ikke
> kører den samme zone version ... igen: hvad end årsagen hertil måtte være.
>
>

Lige for at opklare misforståelsen: Jeg sagde ikke at rDNS var ustabil,
men at den service at man kunne bestille en custom PTR record var i
Beta og derfor risikerede at gå tabt i administrationssystemet undervejs
i beta-perioden. Denne udbyder advarede direkte om dette og jeg
valgte at vente med at bestille egen PTR record indtil beta-perioden
var veloverstået.

Et andet sted i tråden nævnte jeg en oplevelse med en helt anden
udbyder, hvor en tildelt IP havde en custom rDNS fra en anden bruger som
altså må have haft den pågældende IP på et tidspunkt.